Test Your Requirements
Use these three 10-minute checkpoints to verify your project requirements throughout the application lifecycle.
by Jeff Gainer

Posted October 15, 2003

Contrary to what many software practitioners think, testing is not an activity that begins when coding is mostly complete. For that matter, testing doesn't necessarily begin with unit testing, either. The good news is that you can begin testing even earlier.

You can remove defects long before they reach the coding phase, and best of all, you can produce higher-quality software and save your project money. The cost of removing a defect (or bug, if you want to be politically incorrect) rises exponentially throughout the product lifecycle. In fact, studies have demonstrated that it can cost as much as 200 times more to remove and fix a bug in production than if the same bug had been caught in the requirements phase.

But how can you test requirements? And isn't that the job of the requirements team, anyway?

Ideally, testing commences as soon as the business case development begins. From that moment on, testing runs in parallel with requirements definition, and then testing continues all the way through design, coding, release, and maintenance. (For further reading, see the FTPOnline Special Report on Testing and Performance.)

The Three Checkpoints for Requirements
This article describes three 10-minute checkpoints for your project requirements. A 1997 study found that requirements errors can be traced back to as much as 85 percent of project rework costs (see Resources).

Test a requirement by asking three straightforward questions: Is it correct? Is it complete? Is it measurable? If the requirement passes all three of these tests, your requirement is in good shape and you're ready to proceed with writing tests based on that requirement.

Checkpoint One: Correctness
This is the most obvious test, and also the most problematic to determine. At this point, you might need to work closely with business analysts and domain experts. Walk through each path of the use cases (or user stories, if you're doing XP). Each path or scenario in the use case will specify one or more functional requirements. You'll be surprised how often a fresh, independent eye and a simple walkthrough of a use case will uncover missed alternate paths or incorrect assumptions.

Checkpoint Two: Completeness
During these walkthroughs, keep an eye out for completeness. Are all the possibilities of a use case clearly defined? What if a process fails at any point? Are there appropriate error paths in the use case? Do the requirements clearly spell out every scenario for each eventuality?

Checkpoint Three: Measurability
Lastly, determine if a requirement is measurable. As Richard Marshall notes elsewhere in this Special Report, it isn't adequate merely to specify that a system be "easy to use," or "fast." A solid requirement should attach specific numbers to characteristics such as response times and expected training time. A requirement for an online shopping system, for instance, could be: "The system shall respond with an order confirmation within six seconds after the user completes the ordering process."

At this checkpoint, keep the formula for a good test in mind. It's relatively simple: A test specifies an action or series of actions that results in an expected value. If the actual value—that is, the result of the test—matches that expected value, the test passes. If anything else happens, the test fails.

Remember, a defect or bug, regardless of the term you use, is not a matter of opinion. If the requirements are correct, complete, and measurable, a test will either pass or fail. Verify your requirements with these three checkpoints and you'll be well on your way to creating tests that can execute in parallel throughout the project lifecycle. And you'll catch bugs earlier—when they're easier and cheaper to fix.

About the Author
Jeff Gainer is a principal partner at Darwin Partners (www.darwinpartners.com), where he specializes in software process improvement consulting. He has written a profusion of management and technical articles for numerous publications including Enterprise Development and Visual Basic Programmer's Journal. You can reach him by e-mail at gainerj@jeffgainer.com or read his previously published work on the Web at www.jeffgainer.com.