Purpose
Stability of the high-level requirement set early in your project lifecycle reflects the health of a project, and the
effectiveness of the practices that the project employs. This measure brings focus on ensuring that high-level
requirements are stable earlier in the project. This reduces the impact of discovering high-level requirement changes
late in the lifecycle. Given the nature of requirements management as upstream of most other efforts, high-level
requirement stability is that much more important in achieving your project objectives.
For purposes of this metric, the high-level requirement set typically includes the features and use cases. Lower-level
requirements than these are not included in this measure.
Convergence toward zero in the number of new, modified, and de-scoped requirements earlier in the project lifecycle is
a desirable outcome. However, it is important to only converge toward a zero level while still allowing the opportunity
to innovate and remain adaptable to changing context. (That is why the term "converge toward" is used instead of
"converge to.")
Definition
Count:
Number of new requirements during time i
Number of modified requirements during time i
Number of de-scoped requirements during time i
Number of extraneous requirements during time i
The measure can be based on phase completion, or on the duration of this part of the project lifecycle.
Analysis
Use a time-based line chart to represent the stability of the high-level requirement set. The number of new, modified,
de-scoped, and extraneous high-level requirements are each placed on the y-axis. Expect significant change in the
high-level requirement set in the first third of the project lifecycle (typically through Inception and the first half
of Elaboration). Thereafter, stability in the high-level requirement set typically will improve certainty in achieving
the project goals.
In general, a reasonable target to achieve is for not more than 25% of your requirement set to change beyond the end of
inception, 10% beyond the end of elaboration, and 0% beyond the end of construction.
Graphing the number of requirement set changes based on whether they are new, modified, de-scoped, or extraneous can
provide you with more insight. For instance, an increase in high-level requirement de-scoping late in the lifecycle is
an indication that the project was not properly scoped initially, and that this was not discovered or remedied until
very late. More attention should then be placed on properly managing the scope of projects throughout the lifecycle.
If, at the same time, new requirements were being added even midway through the lifecycle, there should have been a
commensurate change in the schedule and budget, or other requirements should have been de-scoped at that time. If these
events do not occur in the same time period, this indicates unmanaged scope creep. Similarly, if a high number of
requirements continue to be modified late into the lifecycle, this reflects a need to establish stability in the
requirement set earlier in the lifecycle.
Collection and reporting tools
IBM® Rational® Team Concert® and IBM® Rational® Requirements Composer® are used to collect data for this
this metric.
|