B Annex B: Quality Measure Elements used to define product quality measures

What this heading covers

The annex is the vocabulary of the raw material. Each of the thirty-one subclauses names one element: number of functions, requirements, failures, faults, hazards, test cases, restarts, jobs, tasks, user actions, user inputs, data items, records, responses, results, user operations, system operations, languages, software modules, components, interfaces, information structures, user interfaces, interface items, operational usage scenarios, events, input conditions, hardware environments, software environments, operational environments, and duration. The names are public in the contents; the text of each subclause is behind the paywall. The list is worth reading as a whole because it shows the shape of the measure set: almost everything is a count of something, or a duration, and the quality measures combine those counts into ratios, percentages and statistics. A team that wants a measure the draft does not name can build it from the same elements and should label it as a local measure.

Record position: annex 2 of 5. The heading is B in the public contents; its text is informative and not public.

What the heading asks of a team

What to put in place before publication

1. Build an element catalogue with the unit, the source and the collection window for each element you use.
2. Map each element to the thirty-one names where it fits, and mark the ones you add.
3. Record the population behind each count, because the same element name can mean different populations.
4. Test one element twice from the same source, and record any difference.
5. Keep duration separate from counts in the catalogue, because the combination rules differ.

Where teams usually fall short

• An element collected with no unit, so the measure cannot be recomputed.
• Local elements presented as if Annex B defined them.

What happens next

Annex C explains the data types those elements produce. Read it before writing a measurement function.