← 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.
The Software Requirements Specification (SRS) follows the IEEE 830-1998 structure. 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.
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 test to need — proves that every test has a reason to exist. Bidirectional traceability gives you both directions at once, making impact analysis and gap detection fast and reliable.
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.
The Software Requirements Specification (SRS) follows the IEEE 830-1998 structure. 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.
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 test to need — proves that every test has a reason to exist. Bidirectional traceability gives you both directions at once, making impact analysis and gap detection fast and reliable.