Requirements Quality

At this stage, let us take a moment to consider the effect of requirements quality. After all, we are suggesting here that you make an effort to ensure the correctness of your requirements. Thus it is appropriate we lay out the reasons for undertaking this endeavor.

For the purposes of this chapter, please read the word "specification" to mean the collection of one or more requirements held in whatever manner you use, including the requirements held inside your head.

We are about to talk about a specification. Keep in mind that it need not take the traditional form of a written, sometimes long, usually boring document with sign-offs, versions, release dates, and so many other things appended. We recognize the need for this kind of document in some situations, and the lack of a need for it in others. So, for the purposes of this chapter, please read the word "specification" to mean the collection of one or more requirements held in whatever manner you use, including the requirements held inside your head.

The requirements specification is used by several downstream activities and eventually used to build the product, whatever it may be. As a result, if the specification is wrong, the product will also be wrong. The Quality Gate way testing is meant to ensure, as far as possible, the correctness of the requirements.

Between 50 and 60 percent of errors in software development originate in the requirements and design activity. About 5 percent of these errors originate in the programming part of the development. This suggests, in the strongest possible way, the benefits that can be realized by putting a little effort into getting the requirements right. Errors are expensive and, if allowed to continue to the downstream activities beyond the requirements process, become more and more expensive.

The cost of repairing an error increases each time the development effort reaches a new phase. A requirements error that might cost $1 to correct during the requirements activity might cost up to $100 during implementation, and even ten times more if the error is not detected and corrected until the product is in the field.

Jones, Capers. Estimating Software Costs. McGraw Hill, 1998.

The precise numbers from different researchers vary, but all of them point to a large increase in the cost of repair in downstream activities. And this cost increases regardless of which type of life cycle you usewaterfall, incremental, eXtreme Programming, whatever. All downstream activities have dependencies on the requirements. An undiscovered error in requirements means a disproportionate effort to correct it later. Capers Jones has calculated that the rework needed to remove requirements errors typically accounts for as much as 50 percent of software development costs.

The earlier an error is discovered, the cheaper it is to correct.

You may dispute some of the research, and you can dispute some of the numbers within reason, but the underlying fact remains true regardless of any other variable in the development cycle: The earlier an error is discovered, the cheaper it is to correct.

The numbers suggestno, let's be honest here, they screamthat you should spend the time testing and correcting your requirements during the requirements activity instead of allowing incorrect requirements to percolate through to a downstream activity. Many development projects do not start testing until software is being implemented. This is far too latemost of the errors originated several activities before implementationand far too expensive. At this point the cost of repair for the majority of errors can now be as much as 100 times more than it need be.

Simply put, testing the requirements is the cheapest and fastest way to develop your product.