Purpose of the SRS & Qualities of a Good SRS

Purpose of the Software Requirements Specification (SRS)

The SRS is a formal, documented statement of the complete requirements of the software to be built. Its purposes:

1. Contract / agreement baseline — an unambiguous, agreed-upon description of what the system will do, shared by customer and developer (basis for scope, payment, acceptance).
2. Communication medium — a common reference that lets users, analysts, designers, testers, and managers understand the system consistently.
3. Basis for design and implementation — the designer derives architecture/modules from it; the coder implements to it.
4. Basis for testing / V&V — test cases, acceptance tests, and validation criteria are derived from the stated requirements.
5. Input to project planning and estimation — supports effort/cost/schedule estimation and risk analysis.
6. Change control baseline — later change requests are evaluated against the frozen SRS.

Attributes / qualities of a good SRS

A good SRS should be (quoting IEEE 830 standard characteristics):

1. Correct — every requirement stated is one the software shall actually meet (truthfully reflects the real need).
2. Unambiguous — every requirement has exactly one interpretation; no vague words like "fast", "user-friendly", "etc.". (Often checked by formal/structured specification.)
3. Complete — includes all functional and non-functional requirements, all inputs/outputs, all constraints, and defined behaviour for all inputs.
4. Consistent — no requirement conflicts with another (no contradictions between sections).
5. Verifiable — each requirement can be checked/tested by a finite process (e.g., "response < 2 s" is verifiable; "fast" is not).
6. Traceable — each requirement is uniquely identified and traceable to its origin (stakeholder need) and to design/test artifacts.
7. Ranked for importance/stable — requirements are prioritized (e.g., must/should/may) so trade-offs can be made; also modifiable yet controlled by change management.
8. Modifiable — structured so that changes can be made consistently without rewriting the document.

Structure (typical)

• Introduction (purpose, scope, definitions, references, overview)
• Overall description (product perspective, functions, user characteristics, constraints, assumptions)
• Specific requirements (functional requirements, non-functional requirements — performance, security, reliability, portability; external interfaces; design constraints)
• Appendices/index

Summary: the SRS is the agreed definition of "what to build"; a good one is correct, unambiguous, complete, consistent, verifiable, and traceable.