High-Level Requirement Stability |
This guideline describes how to measure and use the High-Level Requirement Stability metric.
Main Description
### Overview 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 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 phase completion, or on the duration of this part of 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 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.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.