Clause 5.2.3: Transformation of needs into requirements
Requirements work starts with stakeholder needs, goals or objectives that are still being refined.
What clause 5.2.3 asks
Requirements work starts with stakeholder needs, goals or objectives that are still being refined. An early concern is not yet a stakeholder requirement: it often lacks definition, analysis, consistency and a feasibility check. The concept of operations and the system operational concept are used to move the stakeholders from those early, sometimes unspoken needs to a structured set of statements that meet the construct and characteristic rules. Where the system of interest is a lower level element, the same work is done at that level, because new stakeholders can appear after an architecture decision.
Why it matters
The clause explains why a wish list is not a specification. A need has to be transformed, and the transformation is where ambiguity, conflict and infeasible expectations are found. It also warns that a lower level element has its own stakeholders, so a project cannot assume the top level list covers everything.
No clause level change is public for this unit; the DIS keeps the title and scope, and the requirement text is not released.
What good looks like
Keep a needs register separate from the requirements register. Give each requirement a link back to the need it serves. When a need changes, the link shows which requirements must be revisited. At each level of the architecture, repeat the stakeholder question.
Evidence an assessor asks for
The assessor will follow a requirement back to a need. If the trail stops at a meeting note, the transformation is not evidenced.
- Needs register The stakeholder needs and goals, with the source and the date each was captured
- Transformation record A link from each requirement to the need it serves, with the analysis that turned one into the other
- Concept input The concept of operations or operational concept used to bound the need
- Level check A note that names the system level and the stakeholders added at that level
Where it commonly fails
- The needs register and the requirements register are the same list, so no transformation is visible
- A lower level requirement set with no stakeholders of its own
- A need marked closed because a requirement exists, with no check that the requirement serves it
What to do before the revision
Add a source field to every requirement and make it mandatory. Then review the needs register at each baseline to see which needs have no requirement and which requirements have no need.
Read across
- 5.2.1 General: the requirements engineering function
- 5.2.2 Stakeholders
- 6.2.3.3 Define the problem or opportunity space
- 6.3.3.5 Transform needs into stakeholder requirements
Source for clause 5.2.3: ISO/IEC/IEEE 29148:2018, Clause 5.2.3, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.