Good Requirements - Part V - Be Verifiable

At some point in a project the question, "Did we meet the requirement?" will be asked. This seems like a simple yes / no question, but sometimes, there is no eloquent answer. At times, development staff may produce something similar but not as articulated while at other times the articulation of the requirement itself will make it difficult to verify success. In this posting, I will be focusing on how to articulate requirements to enhance the ability to verify that they have been met.

Consider the following two examples:

Example 1 - A traditional "prose-like" articulation of requirements
A sports car that goes from 0-60 mph within 5 seconds, meets local emission standards and has a 6 speed manual transmission system. There will be a 6 disc CD changer and a DVD player available.

Example 2 - An atomic articulation of requirements
Accelerates from 0-60 within 5 seconds.
Meets local emission standards.
Available with a 6-speed manual transmission.
Option for a 6-disc CD changer.
Option for a DVD player.

Now, suppose that the car accelerates from 0-60 in less than 5 seconds, meets emission standards (in the applicable locals), has a 5 speed manual transmission and has a 6 disc CD changer but no DVD player. In example one, is the requirement met or not? Fully? 60%? Yes? No?

In the second example it is very clear that the 1st, 2nd and 4th requirements have been meet while the 3rd and 5th requirements have not been met.

The point I am trying to express is that by stating requirements as simple atomic statements the ability to easily verify them is enhanced significantly. All requirements must be testable. At the end of the day, one must show a solution adheres to its specifications. This is imperative towards building credibility with one's clients.