Untraced Requirements
This guideline describes how to measure and use the Untraced Requirements metric.
Main Description

Overview

The Untraced Requirements measure shows the degree of consistency and alignment of the requirement set. It measures the amount of low-level requirements that are not substantiated by the presence of approved high-level requirements (as defined in the Requirement Management Plan, or RMP).

This measure assumes that two or more levels of requirements are used. For instance, there are features at one level that have traceability with use-cases at a lower level. If use-cases are present that do not have traceability to features, then the use-case may not be substantiated and within scope.

If there are many levels of requirements, then there may be multiple levels of traceability among the requirements. The measure of untraced requirements among the levels could be assessed separately, in order to reflect consistency and alignment for different purposes.

Untraced requirements generally provide insight into the alignment of development efforts with business objectives. In effect, your team may be putting effort towards requirements that do not have higher-level justification. 

Measurement Method

The percent of lower-level requirements (as defined in the RMP) not traced to higher-level requirements. This measure applies separately (or combined) for each pair of requirement levels that have traceability among them.

Measurement Analysis

A good way to monitor untraced requirements is a line chart that shows the change in percent of low-level requirements that are not traced to high-level requirements. Ideally, a non-zero measure reflects proper alignment and consistency. Typically, an increasing level of untraced requirements indicates a challenge with keeping analysis efforts focused on those requirements that align with higher business objectives. Additionally, a high percentage of untraced requirements reflects difficulty in managing scope creep through the lifecycle. Lower-level requirements may not be traced initially early in the lifecycle, when requirements are elicited, defined, and refined.