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

Purpose 

This metric shows the degree of consistency and alignment of the requirement set. It measures the number of low-level requirements that are not substantiated by the presence of approved high-level requirements (as defined in the Requirement Management Plan).

The Untraced Requirements metric 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. This metric can be used to determine if your team is putting effort towards requirements that do not have higher-level justification.

Definition

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.

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.

It is useful to create a drill through report to show the list of requirements that cannot trace to high level requirements. Confirm with stakeholders that they need the functionality described in these requirements. Update high level requirements to capture these requirements as needed.

Frequency and reporting

Monitor Untraced Requirements each iteration during iteration planning to confirm that all low-level requirements the team plans to implement in that iteration can be traced to high-level requirements.

Collection and reporting tools

 The number of untraced requirements can be obtained from the Requirements Traceability Matrix. Various tools, such IBM® Rational® Team Concert®, IBM® Rational® DOORS®, IBM® Rational® Requirements Composer®, and IBM® Rational® RequisitePro®, provide full support for data collection and reporting of this metric.

Pitfalls, advice, and countermeasures

  • When refining high-level requirements to lower-level requirements, it is possible that you will derive new requirements. The derived requirements should be added and documented in the requirement repository.

  • 90% of untraced requirements are product and product-component requirements, which are introduced with the design solution [1]. So, it is important to pay more attention to the derived product and product-component requirements that can be left untraced.