Clause 8.5: SRS example outline
The SRS outline follows the software view.
What clause 8.5 asks
The SRS outline follows the software view. It covers identification and front matter, the purpose and scope, the product perspective and interfaces, product functions, user characteristics, limitations, assumptions and dependencies, apportioning of requirements, the specified requirements, external interfaces, functions, usability, performance, logical database requirements, design constraints and standards compliance, software system attributes, verification and supporting information. The detailed content is in clause 9.6. The outline can be organized by system mode, user class, object, feature, stimulus, response or functional hierarchy.
Why it matters
The SRS is the software counterpart of the SyRS and should agree with it. The outline includes the sections a template driven SRS most often omits: database requirements, design constraints, standards compliance and verification. Those sections carry the obligations a software team is most likely to miss.
No clause level change is public for this unit; the DIS keeps the title and scope, and the requirement text is not released.
What good looks like
Trace the SRS to the SyRS before writing. Use the outline as the skeleton and choose an organization that fits the software. Record precedence and criticality for each requirement.
Evidence an assessor asks for
The assessor will compare the SRS with the SyRS. A software requirement with no parent in the system set is either derived or unsupported.
- SRS skeleton The outline with each section present, not applicable, or merged
- Interface set System, user, hardware and software interfaces, with the source of each
- Specified requirements Functions, usability, performance, database, constraints, standards and attributes
- Verification and supporting information The verification approach and the material a reader needs
Where it commonly fails
- The SRS is a generic template with the project name changed
- Performance requirements have no measure or condition
- The database and design constraint sections are omitted because the design is not fixed
What to do before the revision
Write the interface and specified requirement sections first. They carry the testable content and expose the gaps in the system set early.
Read across
- 8.1 Requirements information item outlines
- 9.6 SRS content
- 6.4.3.3 Define system or software requirements
- 9.5 SyRS content
← 8.4 SyRS example outline 7 The required information items →
Source for clause 8.5: ISO/IEC/IEEE 29148:2018, Clause 8.5, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.