COEPD – Center of Excellence for Professional Development Happy Learning
A System Requirements Specification (SRS) is a document that describes the features and behavior of a system or software application. It includes a variety of elements which define the functionality required by the stakeholders and customer to satisfy the end users. SRS provides a high-level idea of the system and its behavior.
Depending on the methodology applied (agile vs waterfall) the level of formality and detail in the SRS will vary, but in general an SRS should include a description of the functional requirements, constraints, assumptions and acceptance criteria.
Following are the Elements of SRS:
1.Purpose and Project Scope:
What are the benefits, objectives, and goals we intend to have for this product? why this Product is necessary, its purpose is and what value it will provide to customer is described and explained. It also includes a description of development cost and time required. This also involves definitions, abbreviations, and the acronyms used.
- Functional Requirement:
Functional requirements define a function that a system must perform and must be documented in different forms. The functional requirements describe the behavior of the system. Functional requirements should be written in a simple language, so that it is easily understandable
- Non-Functional Requirement:
Non-functional requirements specify the software’s quality attribute, it helps to understand the system performance. The impact of the non-functional requirements is not on the functionality of the system, but they impact how it will perform. These requirements are specified by the software developers, architects, and technical persons.
4.Assumption
Assumption will help us to understand when our product will fail or not operate perfectly. Here we have to consider the conditions that need to be present so that the product or software will perform properly. Assumptions are those things that we believe to be true based on our knowledge, experience, and/or information provided by our team members or other stakeholders.
5.Constraints:
Constraints are limitations placed upon the project that the project manager and team must work within. Constraints like the limitation of cost, schedule, resources, scope,
6.Acceptance criteria:
This section will describe the criteria by which the customer will “sign-off” on the final system. Depending on the methodology, this may happen at the end of the testing and quality assurance phase, or in an agile methodology, at the end of each iteration.
