← Business and Systems Analysis from Scratch
Lesson
Specification artifacts: SRS, glossary, traceability
The learner can describe the purpose and structure of the key specification artifacts: the software requirements specification (SRS structure), the glossary, and the requirements traceability matrix.
Three pillars of a solid specification
Three pillars of a solid specification
When requirements are agreed upon, they need to live somewhere structured so that every team member — now and six months from now — can find, understand, and verify them. Three artifacts do most of that work: the SRS, the glossary, and the traceability matrix.
A classic Software Requirements Specification (SRS) follows the IEEE 830-1998 outline. IEEE 830 has since been replaced by ISO/IEC/IEEE 29148 (2011, revised 2018), which keeps the same core idea — introduction, overall context, specific requirements — so you will still meet this structure in practice. It opens with an Introduction section that states the document's purpose, the product's scope, key definitions and abbreviations, and references to related documents. The next section, Overall Description, paints the big picture: the product context, the major user classes, assumptions, and constraints. Finally, Specific Requirements is where functional requirements (what the system shall do) and non-functional requirements (how well the system shall do it — performance, security, usability, etc.) are listed in detail. Think of the SRS as the single source of truth that everyone signs off on.
Classic SRS outline (IEEE 830; ISO/IEC/IEEE 29148 keeps the idea)
| Section | What goes there | Example line |
|---|---|---|
| 1. Introduction | purpose, scope, definitions, references | This document specifies Customer Portal v2.0 |
| 2. Overall description | product context, users, constraints, assumptions | Add-on to the existing ERP; users are warehouse staff |
| 3. Specific requirements | functional and non-functional requirements | The system shall let an admin deactivate an account |
Lesson notes
Three pillars of a solid specification
When requirements are agreed upon, they need to live somewhere structured so that every team member — now and six months from now — can find, understand, and verify them. Three artifacts do most of that work: the SRS, the glossary, and the traceability matrix.
A classic Software Requirements Specification (SRS) follows the IEEE 830-1998 outline. IEEE 830 has since been replaced by ISO/IEC/IEEE 29148 (2011, revised 2018), which keeps the same core idea — introduction, overall context, specific requirements — so you will still meet this structure in practice. It opens with an Introduction section that states the document's purpose, the product's scope, key definitions and abbreviations, and references to related documents. The next section, Overall Description, paints the big picture: the product context, the major user classes, assumptions, and constraints. Finally, Specific Requirements is where functional requirements (what the system shall do) and non-functional requirements (how well the system shall do it — performance, security, usability, etc.) are listed in detail. Think of the SRS as the single source of truth that everyone signs off on.
Shared words and traced requirements
The glossary is a living dictionary of terms used in the project. Ambiguity kills projects: if 'client' means a paying customer to the sales team but an API consumer to the developers, every requirement that says 'client' becomes a ticking time bomb. The glossary removes that ambiguity by defining each term once and making the definition visible to all.
The Requirements Traceability Matrix (RTM) is a table that connects business needs to requirements and from requirements to test cases (and sometimes to design elements). Tracing forward — from need to test — lets you check that every need is covered. Tracing backward — from a test or a delivered feature back to the need — proves that everything built has a reason to exist; this is how analysts catch gold plating and scope creep. Bidirectional traceability gives you both directions at once, making impact analysis and gap detection fast and reliable.