Overview
Stability of the high-level requirement set early in project lifecycle reflects the health of a project and the
effectiveness of the practices the project employs. This measure brings focus on getting stability of high-level
requirements earlier in the project to reduce the impact of discovery 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 the project objectives.
For purposes of this discussion, 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”.)
Measurement Method
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 the phase completion or the duration into the project lifecycle.
Measurement 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 is achieving not more than 25% of the requirement set to change beyond the end of
inception, 10% beyond the end of elaboration and 0% beyond the end of construction.
By graphing the number of requirement set changes based on whether they are new, modified, de-scoped or extraneous can
provide more insight. For instance, an increase in high-level requirement de-scoping late in the lifecycle is an
indication that the project was not initially properly scoped and this was not discovered and/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. This
would indicate 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.
|