4.4 Unstable Requirements

Requirements changes have often been reported as a common source of estimation problems (Lederer and Prasad 1992, Jones 1994, Stutzke 2005). In addition to all the general challenges that unstable requirements create, they present two specific estimation challenges.

The first challenge is that unstable requirements represent one specific flavor of project chaos. If requirements cannot be stabilized, the Cone of Uncertainty can't be narrowed, and estimation variability will remain high through the end of the project.

The second challenge is that requirements changes are often not tracked and the project is often not reestimated when it should be. In a well-run project, an initial set of requirements will be baselined, and cost and schedule will be estimated from that baselined set of requirements. As new requirements are added or old requirements are revised, cost and schedule estimates will be modified to reflect those changes. In practice, project managers often neglect to update their cost and schedule assumptions as their requirements change. The irony in these cases is that the estimate for the original functionality might have been accurate, but after dozens of new requirements have been piled onto the project—requirements that have been agreed to but not accounted for—the project won't have any chance of meeting its original estimates, and the project will be perceived as being late, even though everyone agreed that the feature additions were good ideas.

The estimation techniques described in this book will certainly help you estimate better when you have high requirements volatility, but better estimation alone cannot address problems arising from requirements instability. The more powerful responses are project control responses rather than estimation responses. If your environment doesn't allow you to stabilize requirements, consider alternative development approaches that are designed to work in high-volatility environments, such as short iterations, Scrum, Extreme Programming, DSDM (Dynamic Systems Development Method), time box development, and so on.

Tip #16

To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.

Estimating Requirements Growth

If you do want to estimate the effect of unstable requirements, you might consider simply incorporating an allowance for requirements growth, requirements changes, or both into your estimates. Figure 4-5 shows a revised Cone of Uncertainty that accounts for approximately 50% growth in requirements over the course of a project. (This particular Cone is for purposes of illustration only. The specific data points are not supported by the same research as the original Cone.)

image from book
Figure 4-5: A Cone of Uncertainty that allows for requirements increases over the course of the project.

This approach has been used by leading organizations, including NASA's Software Engineering Laboratory, which plans on a 40% increase in requirements (NASA SEL 1990). A similar concept is incorporated into the Cocomo II estimation model, which includes the notion of requirements "breakage" (Boehm et al. 2000).