Software Requirements Specification (SRS)
In short A software requirements specification (SRS) states what a software system must do and how well it must do it, in enough detail to design, build and test it. This page compares the common SRS layouts and gives practical rules for labelling requirements, tracking open issues and deciding whether screens belong in the spec.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 10; IBM RUP Software Requirements Specification templates; Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture 6.
On this page
Key ideas#
Three layouts you will meet#
- Traditional RUP SRS, based on IEEE 830-1998. An introduction and an overall description (product perspective, functions, user characteristics, constraints, assumptions, but no individual requirements) come first. Then a large “specific requirements” section groups functionality, usability, reliability, performance, supportability, design constraints, documentation, purchased components, interfaces (user, hardware, software, communications), licensing, legal notices and applicable standards.
- RUP SRS with use cases. Maglinets describes this version as a container: functional requirements live in the use-case model, and the SRS packages them together with supplementary specifications for quality requirements that do not belong to any single use case. It opens with a system overview (actors, use cases, a use case diagram, assumptions and dependencies).
- Wiegers and Beatty’s template, in the IEEE 830 tradition: introduction, overall description, system features, data requirements, external interfaces, quality attributes, internationalization and localization, and other requirements, with a glossary and analysis models as appendices.
How many specifications?#
Wiegers and Beatty reject “one SRS per project” as a rule. Very large systems may need a system-level specification plus subordinate software and hardware ones; small agile teams may generate an SRS per iteration from a requirements tool. They warn against one giant document that also holds estimates and test plans (a versioning nightmare), requirements kept only on sticky notes (which eventually fall off the wall), and a modest specification split into a dozen files that must be kept in sync.
Give every requirement a label#
A bulleted list cannot be referenced in a test case, a change request or a conversation. Wiegers and Beatty compare three schemes:
- Sequential IDs (UR-9, FR-26). Simple and stable; never reuse a deleted number. They show no grouping, though.
- Hierarchical numbers (3.2.4.3). Familiar but fragile: insert a section and the numbers shift, breaking cross-references. The authors reject the workaround of forbidding insertions to protect the numbering.
- Hierarchical text tags, credited to Tom Gilb (Booking.Slot.Conflict). The parent is a feature heading, and its children together cover that feature. Tags are meaningful and survive reorganization, but they get long and need discipline to stay unique.
TBD is a tracked gap, not a hiding place#
Mark unknowns as TBD (“to be determined”), give each one an owner and a due date, and track it to closure. Unresolved gaps do not fade; developers either guess or wait. Keep an issues list alongside the spec for TBDs, pending decisions, missing information and unresolved conflicts. Maglinets describes such a list as a standard appendix.
Screens in the SRS: a trade-off#
Screens make requirements tangible. They also replace requirements with design, bloat the document and fix the interface in readers’ minds too early. Wiegers and Beatty suggest a middle path: include conceptual sketches clearly labelled as sketches, as one more view of the requirements rather than a substitute for them. On enhancement projects, where the interface already exists, current screens are a reasonable inclusion.
The GOST counterpart#
In Russian public-sector projects, a technical specification under GOST 34.602-89 plays the role of the SRS. Maglinets notes that it adds explicit sections on acceptance and on preparing the organization for go-live, which the RUP and IEEE-style templates lack.
How to apply it#
- Pick a layout. Use the container layout if you model with use cases; the traditional layout otherwise; a tool-generated report per iteration for small agile teams.
- Decide the split. One SRS, or a system specification plus subsystem specifications.
- Choose the labelling scheme before writing the first requirement.
- Write the overall description first. It forces agreement on users, constraints and assumptions.
- Write requirements, each with a label and a link to its source (business objective, use case or stakeholder request).
- Keep the issues list alive. Review open TBDs at every requirements meeting.
- Add a glossary and the analysis models you used.
- Baseline the SRS and put it under change control as set out in your requirements management plan.
Template#
# Software Requirements Specification: <system>, version <n>
## 1. Introduction — purpose, intended readers, scope, conventions, references
## 2. Overall description
- Product perspective — context, related systems
- User classes — who uses it and how
- Operating environment — platforms, locations
- Constraints — design, technical, regulatory
- Assumptions and dependencies — what must stay true
## 3. Functional requirements — grouped by feature or use case; each with a label
## 4. Data requirements — data model, dictionary, retention, reports
## 5. External interfaces — user, software, hardware, communications
## 6. Quality attributes — usability, performance, reliability, security, maintainability; measurable
## 7. Localization — languages, formats, time zones (if relevant)
## 8. Other requirements — legal, licensing, installation
## Appendix A. Glossary
## Appendix B. Analysis models — diagrams referenced above
## Appendix C. Issues list — TBDs with owner and due date
Example#
The Workshop (a fictional bike-repair chain) uses text tags for its booking feature:
- Booking.Slot.Select: the customer shall be able to choose a free repair slot at a chosen workshop.
- Booking.Slot.Conflict: if another customer takes the slot first, the system shall offer the three nearest free slots.
- Booking.Slot.Lead: the earliest bookable slot shall be TBD (owner: the chain’s owner; due: before the design review).
The tags tell every reader these belong to slot booking, and the TBD has a name and a date.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 10 (SRS template, labelling schemes, TBDs, interface elements in the SRS).
- IBM Rational Unified Process (RUP) document templates: Software Requirements Specification (traditional and use-case versions).
- Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007, lecture 6 (RUP container template, issues list, comparison with GOST).