Characteristics of SRS:
SRS is an essential document in the software engineering lifecycle. The entire software engineering relies on this document. It also describes the functionality the software product needs to fulfill the needs of all stakeholders. The main four elements of SRS document can be simply summarized:
- Define your product’s purpose
- Describe what you’re building
- Detail the requirements
- Deliver it for approval
Characteristics of Good SRS Documents:
Concise: The SRS document should be concise at the same time unambiguous, consistent, and complete. It reduces Verbose and irrelevant descriptions and readability. It also increases the possibility of errors in the document.
Implementation-independent: The SRS should be free of design and implementation decisions unless those decisions reflect actual requirements. It should only specify what the system should do and refrain from stating how to do this. It means that the SRS document should specify the externally visible behaviour of the system.
Traceable: It should be possible to trace a specific requirement to the design elements that implement it and vice versa. Similarly, it should be possible to trace a requirement to the code segments that implement it and vice versa. Traceability is also important to verify the results of a phase concerning the previous phase. It analyses the impact of changing a requirement on the design elements and the code.
Modifiable: Customers frequently change their requirements during software development due for a variety of reasons. Therefore, in practice, the SRS document undergoes several revisions during software development. SRS document is often modified after the project completes to accommodate future enhancements and evolution. To cope up with the requirements changes, the SRS document should be easily modifiable.
Identification of response to undesired events: The SRS document should discuss the system responses to various undesired events and exceptional conditions that may arise.
Verifiable: All requirements of the system as documented in the SRS document should be verifiable. It means that it should be possible to design test cases based on the description of the functionality as to whether or not requirements have been met in an implementation.
Characteristics of Bad SRS Documents:
Over-specification: It occurs when the analyst tries to address the “how-to aspects in the SRS document“.
Forward references: It should not refer to aspects that are discussed much later in the SRS document. Forward referencing seriously reduces the readability of the specification.
Wishful thinking: This type of problem concern the description of aspects that would be difficult to implement.
Noise: The term noise refers to the presence of material not directly relevant to the software development process.
