Requirements Specification
Requirements specification is the activity of documenting elicited and analyzed requirements in a precise, consistent, and verifiable form that serves as an agreed basis for design, construction, and acceptance.
Definition
Requirements specification is the production of a documented representation of system requirements, written so that each requirement is unambiguous, verifiable, and traceable, and the collection as a whole is consistent and complete.
Scope
This topic covers the structure and content of a software requirements specification; styles ranging from structured natural language to use cases, user stories, and formal models; quality attributes of good requirements such as unambiguity, completeness, consistency, and testability; and standards such as ISO/IEC/IEEE 29148 that prescribe specification contents.
Core questions
- How can natural-language requirements be made unambiguous and verifiable?
- When are formal or model-based specifications worthwhile?
- What quality attributes characterize a good specification?
- How should functional and non-functional requirements be organized in a document?
Key theories
- Quality attributes of requirements
- Individual requirements should be unambiguous, verifiable, feasible, and necessary, while the set should be complete, consistent, and traceable; these attributes give concrete criteria for reviewing a specification.
- Formal versus informal specification
- Specifications range from structured natural language and use cases to formal mathematical notations; formality increases precision and analyzability at the cost of effort and accessibility, so the level is chosen to match risk and audience.
Clinical relevance
A clear specification is the contract between stakeholders and developers and the reference for verification; ambiguity or omission in the specification propagates into defective designs and disputes over what was promised.
Evidence & guidelines
ISO/IEC/IEEE 29148 defines the recommended structure and quality characteristics of requirements specifications and is the principal standard governing their content.
History
Early specifications were largely free-form prose; the IEEE 830 standard formalized the software requirements specification in the 1990s, and later work introduced use cases, user stories, and model-based and formal notations, culminating in the consolidated ISO/IEC/IEEE 29148 standard.
Debates
- Heavyweight documents versus lightweight user stories
- Plan-driven practice favors comprehensive specification documents, while agile practice prefers lightweight user stories elaborated just in time; the choice trades thoroughness and contractual clarity against adaptability and reduced documentation overhead.
Key figures
- Axel van Lamsweerde
- Michael Jackson
- Ian Sommerville
Related topics
Seminal works
- iso29148
- vanlamsweerde2009
- sommerville2015
Frequently asked questions
- What makes a requirement testable?
- A requirement is testable when it is stated precisely enough that an objective procedure can determine whether the delivered system satisfies it; vague terms like fast or user-friendly must be quantified or given measurable acceptance criteria.
- Do user stories replace requirements specifications?
- User stories are a lightweight specification style suited to iterative development, but they still require acceptance criteria and, for complex or regulated systems, are often supplemented by more detailed documentation to ensure completeness and traceability.