Clause 6.4.3.4: Analyze system or software requirements
The complete set is reviewed against the individual and set characteristics.
What clause 6.4.3.4 asks
The complete set is reviewed against the individual and set characteristics. The architecture is used to check that every feature and function is represented. Reused requirements are checked for fit, feasibility, availability, quality, cost, value and whether they are current. Critical performance measures are defined for each requirement. The analyzed set is fed back to the stakeholders to confirm the transformation was correct, using reviews, prototypes, models, simulation or formal methods as appropriate. Issues, conflicts and weaknesses are resolved.
Why it matters
The clause connects the requirement set to the architecture and to validation. The architecture check is a coverage test in both directions: every architectural feature should have a requirement, and every requirement should have a home. The feedback step is where the supplier learns whether the technical set still means what the stakeholders intended.
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
Run three passes: characteristic review, architecture coverage, and stakeholder validation. Record the method used for each and the issues found. Keep the critical performance measures beside the requirements they assess.
Evidence an assessor asks for
The assessor will ask for a requirement that no architecture element implements, or an architecture feature with no requirement. Both are coverage findings.
- Analysis record The characteristic review, the issues and the resolution
- Architecture coverage The mapping from architecture features to requirements and back, with the gaps named
- Critical performance measures The measure for each critical requirement, with the method
- Validation record The stakeholder review, prototype or model used, and the changes made
Where it commonly fails
- The review checks wording only, with no architecture coverage
- A prototype is shown but no requirement is changed as a result
- Critical performance measures are defined for the easy requirements only
What to do before the revision
Do the architecture coverage pass before the stakeholder validation. It removes the obvious gaps and lets the stakeholders focus on meaning.
Read across
- 5.2.5 Characteristics of individual requirements
- 5.2.6 Characteristics of a set of requirements
- 6.4.3.3 Define system or software requirements
- 6.4.3.5 Manage system or software requirements
- 6.5.1 Requirements activities in architecture definition
← 6.4.3.3 Define system or software requirements 6.4.3.5 Manage system or software requirements →
Source for clause 6.4.3.4: ISO/IEC/IEEE 29148:2018, Clause 6.4.3.4, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.