Requirements Management

Many studies out there confirm the fact that poor requirement management during software project lifetime contribute to the cancellation or failure of the project. Here are a few of them:

In “Major Causes of Software Project Failures”, one of the major failures identified is vague requirements: "You can't design a process that assumes [requirements] are stable". Also there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented. "User wants and needs are two different things. What they put in a requirement document is what they want. What they want you to produce is what they need" (http://discuss.joelonsoftware.com/default.asp?joel.3.36443.16), Joel Spolsky mentioned in one of his blogs.

The well known "Chaos Report" released in 1994 by the Standish Group sites incomplete requirements and changing requirements and specifications as playing a major role in failed projects.

"Why software fails" is an IEEE article that was published in 2005 in the IEEE Spectrum Magazine, and which mentions that badly defined system requirements are one of the most common factors in software failures.

Many other studies exist, but all of them have one central message: poor requirements management leads to poor functionality of the end software, or even cancellation of the project. In order to alleviate this, we could and should manage requirements, and the best way is by using requirement management tools. INCOSE came out with a survey on such tools that can be read here. There are 38 tools surveyed; I recommend reading it if you need to make a decision on what requirement management tool to go with.