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.
|