Why are requirements important to a project? The answer may seem trivial but let's look at some empirical evidence.
- According to the Standish Group's chaos report (1995), only 16.2% of software projects are completed on-time and on-budget.
- The KPMG Canada Survey (1997) stated that over 61% of projects were deemed to have failed.
- According to Forrester Research, "No single factor is responsible for more wasted effort, rework, or failed projects than inadequate requirements (Carl Zetie.)"
- Borland recently posted a new press release for Caliber DefineIT in which they state, "Analysts ... cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group's annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. In addition, requirements errors are a primary factor behind most rework efforts, which ... can add up to 40 percent of the total development effort within a given project."
Let's also consider trends in business.
- We are dealing with more complex systems.
- We need to move faster because the business environment is changing faster. We need to react more quickly.
- Project teams are moving towards more people-oriented development paradigms (e.g., Agile.)
What does this all mean? Successfully delivering projects (e.g., on-time and on-budget) is a difficult task. Furthermore, the environment is evolving and becoming more complex than ever, making a difficult task more even difficult.
I remember talking to a small group of business folk about requirements management practices and its importance (I've uploaded a variant of the presentation I used, titled The Need For Requirements.) It was very encouraging to watch the expressions of the different individuals as we went through the conversation and they started to appreciate the complexity of a project and their role. Understanding is step one.