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 behavior of the proposed software. SRS is also helping the clients to understand their own needs.
We’ll be covering the following topics in this tutorial:
Advantages
Software SRS establishes the basic for agreement between the client and the supplier on what the software product will do.
• A SRS provides a reference for validation of the final product.
• A high-quality SRS is a prerequisite to high-quality software.
• A high-quality SRS reduces the development cost.
Characteristics of an SRS
• Correct
• Complete
• Unambiguous
• Verifiable
• Consistent
• Ranked for importance and/or stability
• Modifiable
• Traceable
An SRS is correct if every requirement included in the SRS represents something required in the final system. An SRS is complete, if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. Correctness ensures that what is specified is done correctly, completeness ensures that everything is indeed specified.
An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language, which are inherently ambiguous.
An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement. An SRS is consistent if there is no requirement that conflicts with another.
Terminology can cause inconsistencies; for example, different requirements may use different terms to refer to the same object. All the requirements for software are not of equal importance. Some are critical, others are important but not critical, and there are some, which are desirable, but not very important. An SRS is ranked for importance and the stability of the requirement are indicated. Stability of requirement reflects the chances of it changing in future. An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development. Forward traceability means that each requirement should be traceable to some design and code elements. Backward traceability requires that it be possible to trace design and code elements to the requirements they support. Traceability aids verification and validation.
