Overview
Requirement Defect Count shows the number of defects that have been attributed to the quality of the requirements. This
may be due to missing, incorrect, ambiguous or extraneous requirements. These defects may be found at any phase of the
project lifecycle and in the performance of any discipline, but most likely during testing.
This measure reflects a form of root cause analysis of defects, attributing defects with one or more attributes to
perform analysis and modeling.
There is a range of possible methods for identifying and analyzing this measure. Real simply, this can be measured with
a single attribute on defects that identifies the root cause. With this approach, the possible values could be as
simple as: requirements, design, code, test. For a more complex and thorough approach, consider Orthogonal Defect
Classification, or ODC. In this approach, defects have 8 orthogonal attributes that characterize the defects from which
a comprehensive analysis and modeling can be performed. The Impact and Target attributes can reflect upon the quality
of the requirements. For more information see Details of Orthogonal Defect Classification and Adopting ODC to improve
software quality: A case study
Within the project lifecycle it is most effective to find the defects attributed to requirement as early as possible.
The later defects are found the more that has been invested in the system based upon missing, incorrect, ambiguous or
extraneous requirements.
Measurement Method
Count:
Number of product defects attributed to requirements management.
Within a project lifecycle a good way to monitor requirement defects is using a line chart that maps through the
project lifecycle the following:
-
cumulative number of requirement defects over time
-
number of unresolved defects attributed to requirements over time
-
number of new requirement defects identified over
Measurement Analysis
The cumulative measure will identify the magnitude of defects that are rooted in the requirements management. If a high
percentage of defects are attributed to the requirements, then more skills development or increased formality may be
necessary.
The unresolved defect chart will identify the responsiveness to making the necessary requirements additions or changes
and any subsequent design and coding changes, for instance, to resolve the defect. A highly responsive team will have
reduced number of unresolved requirement defects. Although, the impact of defects due to requirements is usually
greater as the lifecycle progresses.
Watch for requirement defects identified late in the project lifecycle. This is an indication that insufficient
validation of the requirements is taking place early in the project lifecycle before significant investment has been
made in implementation and testing. It is important to include stakeholders and the project team in the validation
activity. Again, more skills development or increased formality may be necessary.
In the latter half of the project lifecycle it is more difficult to expediently resolve requirement defects because of
the impact of change is greater because of the greater investment already made in design, code and testing, for
example.
Comparison of these measures across projects gives an indication and feedback on which projects and project teams are
more effective and will identify where additional skills development and formality in their requirements management may
be necessary.
If using the ODC method above, the Activity and Trigger attributes will indicate in which activity the defect was
found, and thus, how much investment was made in the requirement before it was discovered
|