Why Do I Need Requirements?

The product is whatever you want to construct. You might want to produce it from scratch, buy it ready-made, install it for free using open source components, or acquire it in some other way. For the sake of simplicity, we will use the term "constructing" the product. It stands to reason that the product's requirements must be understood before its construction begins. The correct requirements come from understanding the work that the product is intended to support. Only when you know the correct requirements can you design and build the correct product, which in turn enables the product's users to do their work in a way that satisfies their business needs.

Sadly, the requirements are not always correctly understood. Both Steve McConnell and Jerry Weinberg provide statistics that show that as many as 60 percent of errors originate with the requirements activity. Clearly, although developers of products have the opportunity to almost eliminate the entire largest category of error, they chooseor, even worse, their managers chooseto rush headlong into constructing the wrong product. As a result, they pay many times the price for the product than they would have if the requirements and analysis had been done correctly in the first place. Poor quality is passed on. It is as simple as that.

McConnell, Steve. Code Complete (second edition). Microsoft Press, 2004. Weinberg, Jerry. Quality Software Management. Volume 4: Anticipating Change. Dorset House, 1997.

If you are working in an agile shop doing pair programming (this means you are developing a rabbit project), you still need to understand requirements. Programming is constructing the solution to the problem. Sure, you can turn out many iterations of a solution in a weekbut they are still solutions. Without an understanding of the fundamental work the user needs to do and of the broader ramifications of introducing your solution into the work environment, your solution can be no better than the user's perception of a fix to the current problem. There is no conflict between agile development and requirements, just a difference in the way you discover and manage the requirements.

"First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project."

Source: Joel Spolsky, Joel on Software, Apress/Springer-Verlag, 2004

The cost of good requirements gathering and systems analysis is minor compared to the cost of poor requirements. But you have bought this book, so we shall not preach to the converted any longer. If you need more justification for installing a quality requirements process, do this: Measure the cost to your organization of repair to substandard products, the cost of cancelled projects that suffered requirements breakdown (no one could agree on the requirements), and the cost of the opportunity lost by not having the correct products at the correct time. If this wastage is insignificant, then stop reading this book. You already have your requirements process under control.

Otherwise, read on.