SRS and characteristics of a good SRS

Software Requirement Specification (SRS)

A Software Requirements Specification (SRS) is the official document that describes completely what the software system must do (functional requirements) and the constraints on it (non-functional requirements), without describing how it will be implemented. It is produced at the end of requirements analysis and is agreed by the customer and the developer.

Users of the SRS

• Customers: check that it meets their needs and specify changes.
• Managers: plan the bid, estimate cost and schedule.
• System engineers / developers: understand what to build.
• Test engineers: develop validation tests.
• Maintenance engineers: understand the system and its parts.

Typical structure (based on IEEE 830)

 1. Introduction
    1.1 Purpose   1.2 Scope   1.3 Definitions
    1.4 References   1.5 Overview
 2. Overall description
    2.1 Product perspective  2.2 Product functions
    2.3 User characteristics 2.4 Constraints
    2.5 Assumptions and dependencies
 3. Specific requirements
    functional requirements, external interfaces,
    performance, design constraints, quality
    attributes (security, reliability, etc.)
 Appendices and index

Characteristics of a good SRS

IEEE 830 lists the following qualities.

1. Correct: every requirement stated is one that the software must actually meet. Only the user can confirm correctness.
2. Unambiguous: every requirement has only one interpretation. Words like "fast" or "user friendly" are avoided or defined; a glossary is included.
   • Bad: "The system shall respond quickly." Good: "The system shall display search results within 2 seconds for 95% of queries."
3. Complete: includes all significant requirements (functions, performance, interfaces, constraints), defines responses to all valid and invalid inputs, labels all figures and tables, and has no "to be decided" items left.
4. Consistent: no requirements conflict with each other, for example one saying "report in tabular form" and another "report in text form", or two different names for the same object.
5. Ranked for importance and/or stability: each requirement is marked as essential, conditional or optional, and as likely or unlikely to change, so that priorities can be set.
6. Verifiable: there is a finite, cost-effective process (test, inspection, analysis) to check that the software meets each requirement. "Works well" is not verifiable; "MTTF of at least 500 hours" is.
7. Modifiable: the structure and style allow changes to be made easily, completely and consistently: organised with a table of contents and index, no redundancy, each requirement stated once.
8. Traceable: the origin of each requirement is clear (backward traceability), and each requirement has a unique ID so it can be referenced in design, code and tests (forward traceability).

Other desirable qualities:

• Understandable by customers and developers (simple language, diagrams).
• Design independent: states what, not how, leaving design choices open.
• Concise: no unnecessary detail or repetition.
• Organised: grouped logically by feature, user class or mode.

A good SRS reduces development effort, provides a baseline for validation and verification, and makes cost estimation and future enhancement easier.