Why you need good requirements
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.
3 comments:
I'm going to try to contribute to this post by offering my own, Using Functional Requirements More Effectively. This is the second part of my series on why I feel that the existence of a category called "non-functional requirements" is a problem, and how to do without it. Hope you like it.
One other hindrance on requirements is that there are numerous approaches to capturing them, and project staffers can become quite dogmatic about the approach, losing sight of the trees and the forest. Before gathering requirements, the team needs to agree on the method for collecting and documenting the requirements, and how these requirements will be translated into the tasks for the project scope. For more on this topic, visit my blog at www.carpefactum.com (especially the post on WRECK-quirements).
Thanks for the input timothy!
One of the things I advocate is to set expectations properly. This includes agreeing on: required prep work, interview techniques, defined roles, & defined deliverables.
Post a Comment