What this heading covers
The population is the functional requirement baseline, and the trap is that the baseline moves. A completeness result is only as good as the set of functions it was measured against, and that set has to be identified and versioned before testing starts. The draft places this family under functional suitability rather than under requirements management because completeness is a property of the product, not of the document. A requirement that was never written is outside the measure, and a requirement that was written and then dropped is a change to the population that has to be recorded.
Record position: family 1 of 40 in clause 6, under 6.2 Functional suitability, which carries 3 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.2.2 in the public contents; the text behind it is not public.
How a measure for this family is built
Take the number of functions or requirements delivered and working as the numerator, and the number specified for this release as the denominator. Both elements have to come from the same baseline version. A count alone says how big the product is; the ratio says how complete it is against the promise made.
Our worked formula
Delivered functions that work divided by the functions the baseline specifies, at one baseline version.
Measure elements that can feed it
Number of requirements, Number of functions
Chosen by us from the thirty-one quality measure elements named in Annex B. The draft does not publish which elements feed functional completeness, so the choice above is a worked example, not the draft's assignment.
What to put in place before publication
- Freeze and version the requirement baseline before the measure is taken.
- Record every requirement removed or added during the release, with the date and the approver.
Evidence to keep
| Kind | What it looks like |
|---|---|
| Baseline | The functional requirement baseline with an identifier and a status for every entry |
| Trace | A trace from each requirement to the test that shows it works |
The test a reviewer asks
- Does the denominator match a baseline that can be produced on request?
- Is every numerator entry traceable to a test result, not to a developer note?
Two questions to ask
- Which requirement baseline did the completeness figure use, and can you produce that version?
- How many requirements were removed during the release, and who approved each removal?
Where teams usually fall short
- A baseline edited at release time so the ratio ends at one hundred.
What the number cannot tell you
It cannot tell you whether the baseline included the function the user needed. A complete product against a thin baseline is still a product missing the job.
What happens next
Read functional correctness next: a complete product can still be wrong.
Source
ISO Online Browsing Platform, free preview of ISO/IEC DIS 25000-23.2 https://www.iso.org/obp/ui#iso:std:iso-iec:25000:-23:dis:ed-1:v2:en read 22 October 2026
ISO/IEC 25010:2023, Product quality model https://www.iso.org/standard/78176.html read 22 October 2026
ISO/IEC 25023:2016, Measurement of system and software product quality https://www.iso.org/standard/35747.html read 22 October 2026