System Requirement Specification(SRS)
- SRS contains a complete information description, a detailed functional description, a representation of system behaviour, an indication of performance requirements and design constraints, appropriate validation criteria, and other information pertinent to requirements.
- Software requirement specification (SRS) is a document that completely describes what the proposed software should do without describing how software will do it
- The basic goal of the requirement phase is to produce the SRS, Which describes the complete behaviour of the proposed software.
- SRS is also helping the clients to understand their own needs.
Characteristics of an SRS
Software requirements specification should be accurate, complete, efficient, and of high quality, so that it does not affect the entire project plan. An SRS is said to be of high quality when the developer and user easily understand the prepared document. Other characteristics of SRS are explained below.
Unambiguous
- SRS is unambiguous when every stated requirement has only one interpretaion
- This implies that each requirement is uniquely interpreted
- In case there is a term used with multiple meanings, the requirements document should specify the meanings in the SRS so that it is clear and easy to understand
Complete
- SRS is complete when the requirements clearly define what the software is required to do
- This includes all the requirements related to performance, design and functionality
Correct
- SRS is correct when all user requirements are stated in the requirements document
- The stated requirements should be according to the desired system
- This implies that each requirement is examined to ensure that it (SRS) represents user requirements
- Note that there is no specified tool or procedure to assure the correctness of SRS. Correctness ensures that all specified requirements are performed correctly.
Ranked for importance/stability
- All requirements are not equally important, hence each requirement is identified to make differences among other requirements
- For this, it is essential to clearly identify each requirement. Stability implies the probability of changes in the requirement in future.
Modifiable
- The requirements of the user can change, hence requirements document should be created in such a manner that those changes can be modified easily, consistently maintaining the structure and style of the SRS
Traceable
- SRS is traceable when the source of each requirement is clear and facilitates the reference of each requirement in future
- For this, forward tracing and backward tracing are used
- Forward tracing implies that each requirement should be traceable to design and code elements
- Backward tracing implies defining each requirement explicitly referencing its source
Consistent
- SRS is consistent when the subsets of individual requirements defined do not conflict with each other.
- For example, there can be a case when different requirements can use different terms to refer to the same object
- There can be logical or temporal conflicts between the specified requirements and some requirements whose logical or temporal characteristics are not satisfied
Verifiable
- SRS is verifiable when the specified requirements can be verified with a cost-effective process to check whether the final software meets those requirements
- The requirements are verified with the help of reviews. Note that unambiguity is essential for verifiability.