Clause 6.3.3.5: Transform needs into stakeholder requirements
The process identifies the constraints on a solution, identifies which stakeholder requirements and functions bear on critical quality characteristics such as safety, security, assurance, health and the environment, and defines stakeholder requirements consistent with the concepts, scenarios, interactions, constraints and critical qualities.
What clause 6.3.3.5 asks
The process identifies the constraints on a solution, identifies which stakeholder requirements and functions bear on critical quality characteristics such as safety, security, assurance, health and the environment, and defines stakeholder requirements consistent with the concepts, scenarios, interactions, constraints and critical qualities. It also considers reuse of existing requirements and uses several elicitation techniques, because one technique will not fit every source.
Why it matters
This is the transformation step, and it is where a need becomes testable. Constraints are a type of requirement and need a source. Critical quality characteristics are often the ones that decide acceptance, so they cannot be left implicit. Reuse is allowed but needs a consistency check against the new system.
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
For each need, write the requirement with its condition and its source. Add the constraints and the critical qualities as first-class requirements. Where a requirement is reused, record the source and check it against the new context.
Evidence an assessor asks for
The assessor will pick a need and ask for the requirement that serves it, then pick a constraint and ask who imposed it.
- Stakeholder requirements The transformed set, with the source need and the condition for each
- Constraint register Each constraint, its source and the requirement it bounds
- Critical quality requirements The assurance, safety, security, environment and health requirements
- Reuse record Each reused requirement, its source and the consistency check against the new system
Where it commonly fails
- Needs copied into the requirements document without transformation
- A constraint with no source, treated as a design preference
- A reused requirement that conflicts with a new interface
What to do before the revision
Transform one need at a time and keep the link. The link is the evidence, and it is also the fastest way to spot a need that produced no requirement.
Read across
- 5.2.3 Transformation of needs into requirements
- 6.3.3.4 Develop the operational concept
- 6.3.3.6 Analyze stakeholder requirements
- 6.4.3.3 Define system or software requirements
← 6.3.3.4 Develop the operational concept 6.3.3.6 Analyze stakeholder requirements →
Source for clause 6.3.3.5: ISO/IEC/IEEE 29148:2018, Clause 6.3.3.5, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.