Requirement Defect Count
This guideline describes how to measure and use requirement defect count.
Main Description

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