Clause 6.6.3.3: Perform requirements measurement
The process collects, analyses and reports objective data about the requirements and the process.
What clause 6.6.3.3 asks
The process collects, analyses and reports objective data about the requirements and the process. Useful measures include requirements quality against the characteristics, requirements quantity as a progress and completeness indicator, and requirements volatility as a signal that the process is not converging or that stakeholders cannot agree. Other measures include trends, change rate and backlog, traceability coverage, verification and validation status, and the closure of TBD and TBR items against the plan. More than one measure is usually needed to answer a management question.
Why it matters
The clause gives a small set of measures that are cheap to collect and hard to fake. Volatility is the most useful early warning: a rising change rate usually means the requirement set is not ready, not that the team is slow. The measure has to be tied to a decision, or it becomes reporting for its own sake.
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
Choose two or three measures for the current decision, not a dashboard of everything. Define the data source and the collection method. Report the trend with the decision it supports, and stop the measure when the decision is made.
Evidence an assessor asks for
The assessor will ask what decision a measure changed. A dashboard with no decision behind it is not measurement.
- Measurement plan The information need, the measure, the data source, the method and the decision it supports
- Quality and quantity report The quality against 5.2.5 and the quantity trend, with the baseline
- Volatility report The change rate, the backlog and the requirements driving the change
- TBx closure The TBD and TBR items closed against the plan, with the open items named
Where it commonly fails
- Every requirement is counted, but no one knows whether the set is good
- Volatility is reported as a team performance problem rather than a requirement readiness signal
- The TBD count is reported without the age of the open items
What to do before the revision
Start with volatility and traceability coverage. They answer the two questions a project board actually asks: is the set settling, and can we show where each requirement came from.
Read across
- 6.6.1 Management overview
- 6.6.3.3 Perform requirements measurement
- 5.2.5 Characteristics of individual requirements
- 5.2.6 Characteristics of a set of requirements
← 6.6.2.3.3 Perform information management 8.1 Requirements information item outlines →
Source for clause 6.6.3.3: ISO/IEC/IEEE 29148:2018, Clause 6.6.3.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.