Stress-Free Wireless Development.

Three Rules of Specifications

If you have been designing for any length of time you have run across vague specifications that you did not know how to meet or if you had met them. You of course want do better and write your specifications so they are clear.

Or maybe you have been asked to review a design spec or requirements document. This can be rather mind numbing when the spec is large (I know from first-hand experience).  To review a spec successfully you need a review process, otherwise many flaws will be missed.  Included in this process you should have a simple way of reviewing the clarity of specifications.

Recognizing a good spec is helpful for both creating and reviewing technical documents. I have three main rules that I always look for.

Rule 1: Specifications have to be verifiable.

In general when we think of verifying specifications we think of testing, but there are actually five ways that can be used to show that something meets its specifications:

1. Demonstration
2. Inspection
3. Analysis
4. Certification
5. Test

While the common meaning of these terms is clear, we will discuss each of these in another post. What is important when you write a specification is to think about how one would verify that the specification has been met or not. If you cannot see how to verify that it has been met, then neither will your test team or customer.

Rule 2: Non-discrete parameters require boundaries.

While it is possible to specify that something contains a fixed quantity of marbles, it is not practical to specify a weight, height, volume, speed, etc. exactly. Because these are continuous quantities (unlike a discrete item such as a marble) you must specify a range. Each of the following are valid specifications:

1. W = 10 kg ± 0.01 kg
2. W < 10 kg
3. W ≥ 10 kg
4. 9 kg < W < 10 kg

Most engineering specifications are continuous in nature. If you see a specification that is exact take the time to figure out its acceptable boundary values.

Rule 3: Adjectives require a reference to compare against

“Fast” is not a specification. “Faster than competitor X’s product”, on the other hand is a valid specification, if you can define the test conditions accurately. “Easy to use” is not a specification that can be tested, it is a marketing statement that needs to be turned into a specification. Whenever possible turn fuzzy adjectives into a quantifiable number. An example from the telecom world is the Mean Opinion Score (MOS) for voice quality [ref ITU P.800 or ITU P.862] .

MOS Quality Impairment
5 Excellent Imperceptible
4 Good Perceptible but not annoying
3 Fair Slightly annoying
2 Poor Annoying
1 Bad Very annoying

While the impairments in the above table are qualitative in nature, a numeric value is achieved by taking the opinions of many users running a standardized set of tests.

That’s it. Three simple things to remember when specifying your system.

1. Determine how you will verify the spec.
2. Establish the boundary between pass and fail.
3. Turn fuzzy marketing terms into something measurable.

If you do these three things everyone will understand your spec’s intentions.