Software requirements specification
A software requirements specification (SRS), commonly just called a requirements document, is a formal document that captures everything the software must do (the functional requirements), the qualities it must have (the non-functional requirements), and the constraints it works under. It is the agreed reference for what will be built, the thing everyone can point back to when there is a dispute.
The SRS is the classic output of the Requirements stage of the SDLC in plan-driven work. In agile work it is largely replaced by a living Product backlog of user stories with acceptance criteria, written just in time rather than all up front.
Also known as
SRS · requirements document · requirements specification · software requirements document
Don't confuse with the other "requirements documents" (the acronym soup)
Different companies slice the requirements into different documents, and the names collide. Roughly, from business to technical:
- BRD (Business Requirements Document): the why, the business goals and needs, in business language.
- PRD (Product Requirements Document): the what, the product’s features and user needs, from a product-management view. Common at product companies.
- FRD (Functional Requirements Document): the detailed functional behaviors only (and often just folded into the SRS rather than kept as a separate document).
- SRS: the comprehensive, engineering-facing spec (functional + non-functional + constraints) for the team that builds it.
No two organizations use these identically. Ask what a given document actually contains rather than trusting the acronym. And note the big split: all of these are up-front documents, whereas the agile alternative is a Product backlog elaborated continuously.
What it contains (typical format)
A standard SRS (the shape comes from IEEE 830, now folded into ISO/IEC/IEEE 29148) has roughly:
- Introduction: purpose, scope, definitions, references, overview.
- Overall description: product perspective and context, major functions, user characteristics, constraints, assumptions, and dependencies.
- Specific requirements: the detailed functional requirements, the non-functional or quality requirements, and external interface requirements (UI, hardware, software, communications).
- Appendices and index: supporting data, models, and a glossary.
What good requirements look like
ISO/IEC/IEEE 29148 says each requirement should be necessary, unambiguous, singular, feasible, and verifiable, and the whole set should be complete and consistent. In plain terms: you can tell exactly what each one means, you can test whether it is met, and it does not contradict another. (Traceability, following a requirement back to its source and forward to its tests, is tracked separately, not as a property of the requirement itself.)
Plan-driven vs agile
- Plan-driven / waterfall: write a thorough SRS up front and sign off before building. Good when requirements are stable, or a contract or regulator demands it.
- Agile: skip the big document; keep a Product backlog of stories, each with acceptance criteria, refined just before it is built. Good when requirements will change.
- Hybrid: many teams keep a light SRS or PRD for the stable core and use stories for the rest.
See also
- Functional requirement and Non-functional requirement: what an SRS is made of
- Product backlog and User story: the agile alternative
- Software development life cycle: the Requirements stage this is the output of
- Waterfall model: the approach that leans on a full SRS
References
- ISO/IEC/IEEE 29148:2018 (Systems and software engineering: requirements engineering), which defines the modern SRS. https://www.iso.org/standard/72089.html
- IEEE 830-1998, Recommended Practice for Software Requirements Specifications (the classic SRS template, superseded by 29148). https://standards.ieee.org/ieee/830/1222/
- K. Wiegers and J. Beatty, Software Requirements (3rd ed., Microsoft Press, 2013). https://www.microsoftpressstore.com/store/software-requirements-9780735679665