Requirements and their lifecycle
What a requirement holds, the nine states it moves through from draft to verified, how the bar over the requirements table counts them, how a story's state follows from its requirements, and the standards and research behind them.
What a requirement holds
A requirement is one thing the system shall do, stated so that someone can check it was done. Each has an id, such as Req-004, and these parts:
| Part | What it says |
|---|---|
| Requirement | What the system shall do, in one statement. |
| Priority | Must, Should, Could or Won't. |
| Source stories | The user stories it serves. This is the link that keeps it traced. |
| Source requirements | For a requirement of a subsystem: the system requirements it was derived from, in place of stories. |
| Acceptance criteria | How to tell it is done, often as given / when / then. |
| Rationale | Why it is needed. |
| Category | Its kind: functional, non-functional, constraint, interface, process, usability or human. |
| Risk | What goes wrong without it. |
| Guidance | Ideas and good practice for building it. |
| Component | The part of the system it applies to. |
The first four are part of every project. The rest are the project's choice, made when it is created, under Advanced: model and requirement fields: acceptance criteria, rationale and category, unless you change them.
The lifecycle
Every requirement is in one of nine states. Six are rungs on one ladder, from written to tested. The other three are not progress at all.
| State | Means |
|---|---|
| Draft | Written, not yet reviewed. Where every new requirement starts. |
| In review | Someone is reviewing it. |
| Reviewed | Agreed. Ready to build. |
| In progress | Being built. |
| Implemented | Built. |
| Verified | Built, and checked against its acceptance criteria. |
| Blocked | Cannot move until something else is resolved. |
| Rejected | Decided against. Kept, so the decision stays visible. |
| Superseded | Replaced by another requirement. |
Anyone who can edit the project sets the state in the requirements table's Status column. A connected coding agent sets it as it works, so implemented and verified often arrive from the agent.
The bar over the requirements
At the top right of the requirements, one line sums up the rows on screen. From left to right:
- What it covers: Project for every requirement, or This view when a subsystem is chosen or the table is filtered by story, stakeholder, status or search.
- A state: where they stand together, by the same rule as a story's state below. One blocked requirement makes it Blocked.
- A bar: how they are spread across the states, one colour each.
- A count: how many are implemented or verified, of all of them.
Hover it for the exact numbers and what narrowed it. Two kinds of row are left out, and the tooltip says so: interface requirements, which have no state, and requirements still being generated. Rejected and superseded requirements are counted, but the bar leaves them out of progress.
A story's state
A story has no state of its own. It takes the state of its requirements, by the weakest link: the lowest rung any of them is on. A story whose requirements are all verified except one in progress is in progress.
- One blocked requirement makes the story blocked, whatever else is done.
- Rejected and superseded requirements are left out.
- A story with no requirements left to build has no state.
For experts: the sources behind requirements
A requirement's parts and states follow published requirements-engineering standards and practice. ISO/IEC/IEEE 29148:2018 gives a requirement's attributes as examples to choose from (§5.2.8), not as a fixed set; the fields a project chooses are such a choice.
| Part | Based on |
|---|---|
| Id | A unique identifier, so that each requirement can be referred to: the INCOSE Guide to Writing Requirements, and IEEE Std 830-1998, §4.3: traceable. |
| Requirement | The characteristics ISO/IEC/IEEE 29148:2018 sets for an individual requirement (§5.2.5) and its language criteria (§5.2.7), and the INCOSE guide's rules. The Spec score checks them: see the standards behind the score. |
| Priority | MoSCoW, from the DSDM method. IEEE Std 830-1998, §4.3: ranked for importance. An import from OpenSpec or Spec Kit reads it from the RFC 2119 keyword: MUST and SHALL as Must, SHOULD as Should, MAY as Could. |
| Source stories | Tracing a requirement back to where it came from, which Gotel and Finkelstein (1994) call pre-requirements-specification traceability. They found most traceability problems there. IEEE Std 830-1998, §4.3: traceable, the origin of each requirement clear. The INCOSE guide's trace to source attribute. |
| Source requirements | The path upward from a child requirement to its parents, in ISO/IEC/IEEE 29148:2018's definition of requirements traceability (3.1.23). Allocating requirements to the parts of a system, in ISO/IEC/IEEE 15288:2023. The INCOSE guide's trace to parent attribute. |
| Acceptance criteria | What has to hold for the requirement to count as verified: in Wiegers and Beatty's statuses, a verified requirement is one that has satisfied its acceptance criteria. Given / when / then is the scenario form of behaviour-driven development (North, 2006). |
| Rationale | Why the requirement is needed: in the INCOSE guide, the attribute that shows a requirement is necessary. |
| Category | A requirement's type, an attribute ISO/IEC/IEEE 29148:2018 gives examples of (§5.2.8.3). Whether the quality requirements cover what the product needs, the Spec score judges against ISO/IEC 25010:2023. |
The lifecycle follows the requirement statuses Wiegers and Beatty (2013) suggest for tracking a project through its requirements. They count requirements by status rather than estimate how complete the work is, and that count is what the bar over the requirements shows.
| State | In Wiegers and Beatty |
|---|---|
| Draft | Drafted: the first version is written. |
| In review | No status of its own. |
| Reviewed | Approved: the key stakeholders agreed to it, and the team committed to build it. |
| In progress | No status of its own. Their In Progress is the requirement still being written. |
| Implemented | Implemented. |
| Verified | Verified: it has satisfied its acceptance criteria. |
| Blocked | Not a requirement status. Leffingwell (2011) gives it to user stories. |
| Rejected | Rejected, kept with the reason, because rejected requirements tend to come back. |
| Superseded | No status of its own. Deleted is the nearest. |
Where Entalpa departs from these sources, it says so:
- Verified means built and checked. In ISO/IEC/IEEE 29148, verifying a requirement means confirming it is well-formed (3.1.26), and validating it, confirming it defines the right system (3.1.25). Entalpa calls the first review. Its Verified is Wiegers and Beatty's, and the sense of verification in ISO/IEC/IEEE 15288: evidence that what was built fulfils the requirement.
- In progress means being built. It names the step between agreed and built, which the statuses above leave unnamed.
- No Proposed, Deferred or Deleted. A new requirement starts as a draft. One left for a later release has no state for it; its priority says so, Won't being MoSCoW's "won't have this time". One dropped is rejected, so the decision stays visible.
- Blocked belongs to requirements. Leffingwell gives it to stories. Entalpa sets it on a requirement, and a story is blocked when one of its requirements is.
- A story's state is derived, not set. In agile tracking a story has a status of its own. Entalpa derives it from the story's requirements, by the weakest link, because a story is delivered only when everything it needs is. The two can never disagree.
References
- ISO/IEC/IEEE 29148:2018. Systems and software engineering: Life cycle processes, Requirements engineering.
- ISO/IEC/IEEE 15288:2023. Systems and software engineering: System life cycle processes.
- ISO/IEC 25010:2023. Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE), Product quality model.
- IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Specifications. Superseded by ISO/IEC/IEEE 29148, and still widely cited.
- INCOSE Requirements Working Group (2023). Guide to Writing Requirements, version 4.
- Wiegers, K. and Beatty, J. (2013). Software Requirements, 3rd edition. Microsoft Press.
- Gotel, O. C. Z. and Finkelstein, A. C. W. (1994). An analysis of the requirements traceability problem. Proceedings of the First International Conference on Requirements Engineering (ICRE '94), 94–101.
- North, D. (2006). Introducing BDD. Better Software, March 2006.
- Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.
- Bradner, S. (1997). Key words for use in RFCs to indicate requirement levels. RFC 2119, IETF.
- DSDM Consortium. The DSDM Agile Project Framework: MoSCoW prioritisation.