Requirements
A requirement is “a property that must be exhibited to solve a real-world problem” [1]. Requirements management is the set of activities that identify, control and track those properties, and changes to them, for as long as the project runs [2].
SWEBOK splits the work in two, and the split is worth holding on to: requirements development is reaching an agreement on what software is to be constructed; requirements management is maintaining that agreement over time.
1. Where a requirement stops
Two boundaries do more work than the definition, and both can be checked by reading a sentence.
- A requirement is not a design. It “limits the range of valid designs, but does not specify any particular design” [3]. “Must comply with GDPR” and “must run on Android 11 and above” are requirements. “Use a three-tier architecture with a Redis cache” is a design decision wearing a requirement’s clothes. A requirement narrows the design space; one that narrows it to a single point has stopped being a requirement.
- A requirement is not a project constraint. Cost, delivery schedule, staffing, reporting procedures and the QA plan are all real constraints, and none of them belongs in a requirements specification — that document is about the product, not about the process that builds it.
A requirement narrows the space. A design picks a point. [3]
A third distinction saves arguments later: an implied requirement is one everybody assumes and nobody writes down. “The system shall be secure” is implied until it becomes “all traffic shall use TLS 1.2 or later”.
2. What the pages cover
| Page | The question it answers |
|---|---|
| Stakeholders | Who gets to state a requirement, and who did you miss? |
| Elicitation | How do you find out what is needed, when nobody can just tell you? |
| Requirement statements | How do you write one, and classify it? |
| Requirements engineering | What are the activities, and what is validation versus verification? |
| Methods | User stories, use cases, scenarios — which and when? |
| Documenting requirements | What goes in an SRS, a backlog, a statement of work? |
| Validation, traceability and change | What happens once a requirement changes? |
| Organising requirements | How do you structure and prioritise a large set? |
| Requirements with LLMs | What can a language model do here, and where does it fail? |
One word is worth correcting before any of them. The activity is elicitation, not capture: “the term ‘elicitation’ is preferred to ‘capture’, to avoid the suggestion that requirements are out there to be collected simply by asking the right questions” [4].
Acknowledgments
This page adapts material from lectures by Eduardo Miranda and David Root [2] on software project management.
References
- IEEE Computer Society, Ed.,“Guide to the Software Engineering Body of Knowledge (SWEBOK Guide).” IEEE Computer Society, Oct. 15, 2024.
- D. Root,Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.
- ISO/IEC/IEEE,ISO/IEC/IEEE 29148:2018 — Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. International Organization for Standardization, 2018. [Online]. Available: https://www.iso.org/standard/72089.html
- B. Nuseibeh and S. Easterbrook,“Requirements Engineering: A Roadmap,” in Proceedings of the Conference on The Future of Software Engineering (ICSE ’00), ACM, May 2000, pp. 35–46. doi: 10.1145/336512.336523.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.