System requirements specification (SRS)

A system requirements specification (SRS) is a document that records the complete set of requirements a system must satisfy before any commitment is made to its design and construction. Where a product requirements document (PRD) expresses needs in the language of stakeholders and end users, the SRS translates them into a precise, technical statement aimed at the engineers and designers who will build and test the system.

An SRS documents both the functional requirements of the system – what it must do – and its non-functional requirements – how well it must perform, and the constraints under which it operates. As a change moves through design and delivery, the SRS elaborates the higher-level PRD: each user-facing need is decomposed into specific, testable system behaviors, and the quality attributes the system is expected to meet – performance, availability, security, and so on – are pinned down as measurable targets.

Typical structure

The SRS is conventionally organized around the kinds of requirements it contains. A typical outline includes:

  • Functional requirements. The behaviors, features, and capabilities the system must provide, often expressed as use cases or user stories for larger systems.
  • Non-functional requirements. The quality attributes the system must exhibit, such as performance, reliability, and security, each stated as a measurable target where possible.
  • External interfaces. The interfaces the system exposes to and expects from users, other systems, hardware, and software, including data formats and communication protocols.
  • Constraints. Design and implementation constraints the system must respect, such as a required technology stack, regulatory compliance, or hardware limitations. Constraints are not requirements in the usual sense, since they bound the solution space rather than describe a system behavior.
  • Design assumptions and dependencies. Assumptions made about the operating environment and dependencies on external services or components.

The SRS is also the reference against which traceability is maintained. Each requirement is assigned an identifier and followed forward into the design elements and tests that realize and verify it, and backward to the stakeholder need that motivated it. Well-formed requirements are individually necessary, unambiguous, testable, and traceable; collectively they should be complete and consistent, with no two requirements contradicting one another.

Standards

The SRS has been the subject of formal standardization since the late 1980s. The most influential early standard was IEEE 830-1998, IEEE Recommended Practice for Software Requirements Specifications, which codified a recommended SRS structure and a set of qualities a well-written SRS should exhibit. IEEE 830 was withdrawn and superseded in 2011 by ISO/IEC/IEEE 29148:2011, Software and systems engineering – Life cycle processes – Requirements engineering, which unified the IEEE practice with earlier ISO and IEC requirements-engineering standards. ISO/IEC/IEEE 29148 was revised in 2018. The standard places the SRS within the wider requirements engineering lifecycle, alongside elicitation, analysis, and validation activities.

Relationship to PRDs and use cases

The SRS sits one layer down from the PRD in the requirements stack. A PRD answers what the product should do for its users, written for a business audience; the SRS answers what the system must do to deliver that, written for a technical audience. The two are not always kept as separate documents – in smaller or more agile settings their roles may merge – but the distinction in purpose is real: the SRS is the artifact that hands a fully specified set of requirements to design and delivery teams.

Functional requirements within an SRS are commonly elaborated using use cases, which describe each system behavior as a sequence of interactions between an actor and the system, or as user stories with associated acceptance criteria. The choice of artifact depends on the nature of the change and the team’s process.

History

The term system requirements specification, and the practice of producing a distinct SRS document, emerged from the plan-driven, document-centric software engineering traditions of the 1970s and 1980s. The SRS was a defining deliverable of methods such as the waterfall model and later the Unified Process, where a complete, signed-off specification was expected to precede design and construction. The rise of agile methods shifted the emphasis towards lighter, evolving requirements artifacts such as user stories and backlogs. The SRS nonetheless remains the conventional vehicle where a formal, contractual, or regulatory basis for the requirements is required, or where the system is large enough that a single shared specification is essential.

See also

References

  • IEEE (1998). IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998).
  • ISO/IEC/IEEE (2018). Software and systems engineering – Life cycle processes – Requirements engineering (ISO/IEC/IEEE 29148:2018).
  • How to Write a Software Requirements Specification, by MicroTools Inc.