Clause 5.3.2: Iteration and recursion in requirements engineering
The requirements processes are applied iteratively and recursively.
What clause 5.3.2 asks
The requirements processes are applied iteratively and recursively. Iteration means the same process is run again at the same level as understanding improves. Recursion means the process is applied at the next level down, to a system element, with its own stakeholders and its own requirement set. The standard treats both as normal, not as evidence of a failed first pass. Each application produces a baseline that the next level can use, and the baselines are managed through configuration control.
Why it matters
The clause explains why a single pass through the process is rarely enough and why a lower level element deserves its own requirements work. It also sets the expectation that iteration is planned. An unplanned re-run looks like churn; a planned re-run is how the set converges. The baseline is the point at which the output is stable enough to use.
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
Put the iterations and the recursion levels in the requirements plan. Name the entry and exit criteria for each pass and the baseline it produces. When a lower level element is reached, repeat the stakeholder and concept work rather than copying the parent set.
Evidence an assessor asks for
The assessor will ask why the set was revised three times. A planned iteration with a baseline is a different answer from an uncontrolled rewrite.
- Process plan The planned iterations, the levels of recursion and the entry and exit criteria for each
- Baseline record The baseline produced at each level, with the approval and the date
- Lower level stakeholder list The stakeholders identified for each system element, including any new ones
- Change note The reason for each re-run and what changed in the set
Where it commonly fails
- One pass declared complete, with the lower level elements copying the parent requirements
- Iteration that changes the baseline without a change record
- A lower level element with no stakeholders because the parent list was assumed to cover it
What to do before the revision
Show the iterations on one page with the baseline at the end of each. That page is the answer to the question of why the set changed.
Read across
- 5.2.3 Transformation of needs into requirements
- 6.4.3.5 Manage system or software requirements
- 6.6.2.2.2 Configuration identification
- 6.6.2.2.3 Configuration change control
Source for clause 5.3.2: ISO/IEC/IEEE 29148:2018, Clause 5.3.2, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.