Not every manager is convinced that his team needs to do a better job on requirements development and management or that such an investment will pay off. Numerous industry studies, however, indicate that requirements issues are a pervasive cause of project distress. Let’s see why investing in better requirements is a smart business decision for any organization.
An Economic Argument
The case for implementing better requirements practices is an economic or business argument, not a philosophical or technical position. Think about how your company’s bottom line is affected by requirements-related problems. Then use that understanding to justify investing in better requirements practices that can pay off for the long term.
A vivid case study of requirements failure was the Federal Bureau of Investigation’s new case management software system, called VCF. This project was abandoned after $170 million had been spent because the delivered software was full of defects and off-target functionality. As one investigator wrote:
I suspect what happened with the VCF is that in the rush to put in place a system, you think you got your requirements nailed, but you really don’t. It was a classic case of not getting the requirements sufficiently defined in terms of completeness and correctness from the beginning. And so it required a continuous redefinition of requirements that had a cascading effect on what had already been designed and produced. (Goldstein, Harry. 2005. “Who Killed the Virtual Case File?” IEEE Spectrum 42(9): 24–35).
Numerous studies have examined the effects of errors in requirements on software projects. They consistently find that nearly half of the discovered defects originated as requirement errors. The typical outcome of shortcomings in requirements is an expectation gap, a gulf between what developers build and what customers really need (Figure 1). If this expectation gap is discovered too late in the project, it comes as a rude surprise. In my experience, surprises in software are rarely good news. Any domain that’s the root cause of so many problems clearly deserves our attention.
Figure 1. Requirements shortcomings lead to an expectation gap.
The main reason errors in requirements are so damaging is that they force the development team to perform extensive rework to correct the errors. The cost of correcting a software error increases dramatically the later it is discovered, as shown in Table 1. Even on agile projects, where problems with working software can be detected soon after construction, it’s cheaper to avoid defects than to correct them. An error, omission, or misunderstanding in the requirements forces developers to redo all the work they’ve already done based on the incorrect requirement. Therefore, any technique that can reduce requirement defects and prevent some of this wasted effort is a high-leverage investment indeed. One analysis of the potential return on investment from better requirements suggested that requirement errors can consume between 70 and 85 percent of all project rework costs.
Table 1. Relative Cost to Correct a Requirement Error
| Stage Error Is Discovered |
Relative Cost to Correct |
| Requirements Development |
1X |
| Design |
2–3X |
| Construction |
5–10X |
| System or Acceptance Test |
8–20X |
| Operation |
68–110X |
What Better Requirements Can Do for You
In addition to avoiding some of these negative consequences, better software requirements provide numerous benefits. These include selecting the right projects to fund, facilitating estimation, enabling rational prioritization, avoiding unnecessary work, developing better designs, and testing more effectively.
Selecting projects to fund. Good preliminary requirements enable senior managers to make effective business decisions as organizations decide which among a set of potential projects to launch. Better requirements allow more accurate projection of business returns. Once a project is funded, better requirements allow project managers to more sensibly partition tasks across their teams and among individual team members.
Facilitating estimation. Well-understood requirements can help your team estimate the effort and resources needed to execute a project. Reliable estimation requires some historical correlation between requirements size and development effort.
Enabling prioritization. Documented requirements let the team prioritize its backlog of remaining work. Projects need to make compromises to ensure that they implement the most important and most urgent functionality. Prioritized requirements guides the team to incorporate those changes that will deliver the maximum customer value. One study revealed that just 54 percent of the originally defined features were delivered on an average project. If you can’t implement all of the requested functionality, make sure the team implements the right set.
Avoiding unnecessary work. Good requirements ensure that the development team works on the right problem. I’ve personally experienced the frustration of implementing functionality that people swore they needed, only to find that no one ever used it. One survey indicated that fully 45 percent of the delivered software product features were never used. Wasting less time implementing the wrong functionality accelerates the project and maximizes its business return.
Developing designs. Well-understood and well-communicated requirements help developers devise the most appropriate solution. Vague and volatile requirements can lead to sub-optimal architectures and designs that don’t accommodate change well.
Testing effectively. Well-defined and testable requirements allow testers to develop accurate test procedures to verify the functionality. Prioritizing requirements tells testers which ones to focus on first. Assessing requirement difficulty and risk helps testers know which functionality should receive the closest scrutiny.
Tracking project status. A body of work is complete when all of the requirements allocated to it are either verified as being correctly implemented in the solution or deleted from the baseline. If you aren’t tracking the requirements, how do you know when the project is done? Defined business requirements also let the stakeholders determine whether the project has met its goals.
Accelerating development. Investing more effort in developing the requirements can actually accelerate software development. This seems counterintuitive, but it’s true. Defining business requirements—the expected business outcomes the product will provide—aligns the stakeholders with shared vision, goals, and expectations. Effective user involvement in requirements definition reduces the chance that users will reject the new system upon delivery. Following are some published illustrations.
- In a study of 15 banking and telecommunications projects, the most successful projects spent 28 percent of their resources on requirements engineering, whereas the average project in the study devoted just 15.7 percent of its effort to requirements.
- Increasing the fraction of the total budget devoted to requirements on a group of NASA projects led to substantially lower overrun of both cost and schedules; see Table 2 (Hooks, Ivy F., and Kristin A. Farry. 2001. Customer-Centered Products: Creating Successful Products Through Smart Requirements Management. New York: AMACOM).
- In a European survey, the fastest project teams spent about twice as much of their schedule (17 percent versus nine percent) and effort (14 percent versus seven percent) on requirements activities as the slower teams.
Table 2 Cost and Schedule Overruns on Some NASA Projects
| Percent of Budget Spent on Requirements |
Number of Projects |
Average Project Cost Overrun |
| < 5% |
5 |
125% |
| 5 to 10% |
7 |
83% |
| > 10% |
6 |
30% |
Accurate requirements ensure that the functionality built will let users perform their essential business tasks. The requirements also establish achievable quality expectations. This lets the team address both the capabilities and the product characteristics—the nonfunctional requirements—that will make users happy. And emphasizing requirements development is cheaper than relying on beta testing to find requirements problems. Fixing problems that late in the game costs a lot more than correcting them earlier. And nobody’s having fun at that point.
Author: Karl Wiegers
Karl is the author of numerous books on software development, project management, consulting, and other topics. During the past 50 years, he has designed chemistry experiments, software applications, user interfaces, software development processes, books, games, songs, and training courses. Contact Karl at ProcessImpact.com, KarlWiegers.com, or Thoughtless-Design.com.