It can be very difficult to know where to begin in the huge decision-making process needed to go from a one-sentence goal to a complete product implementation. Use a stage-by-stage requirements/design philosophy to make sure you're proceeding in an orderly way.

The idea is that the whole process is broken into separate stages. At each stage there are two parts: the requirements, which are the goals that specify what must be accomplished at that stage; and the design, which is the solution created at that stage to satisfy the requirements.

Another key point is that the design from one stage of the process becomes the requirements for lower stages. For instance, a mission statement may leads to 5 strategy points; those 5 points are the design that results from the mission statement requirement. The first of those 5 points then becomes the requirement for the architecure stage, and so forth.

Rules for Each Stage

If certain rules are followed, and careful thought is put into each stage, it is possible to arrive a lower-level decisions that can be relied upon without having to go back to the higher-levels all the time. When done most correctly, the requirements from each stage are complete of themselves; designers at that stage need not look back at even the previous stage's requirements to see where these requirements came from. This is a huge benefit, as it reduces the communication between stages to a single concise statement of requirements from one to the next.

To make this work, the requirements must be very precise. It works out in practice that the more concise the requirements are, the better they are. They should say exactly what is really required and no more. This leaves the most flexibility for the next stage designers.

The hardest stages to do right are the top-level ones, because they typically deal with broad concepts that are hard to specify precisely. Because the concepts are so broad it's important that the requirements be short, otherwise they overspecify details best left to later levels. But because they are short there is an inevitable tendency toward vagueness that must be combatted. It is possible to have precise but short requirements, that's the skill in producing top-level requirements.

One way to determine whether requirements are precise is to see whether they can be used to test various statements. This is called testability. A testable requirement gives a clear yes, no, or how much answer for questions that might occur to designers at the next stage.

How Formal Should It Be?

At most stages it's beneficial to have the whole thing in writing: the requirements coming in, the design produced, and the reasons for the design.

This last, the design rationale, is important when one comes back to a design later to modify it to meet new circumstances or information. When modifying the design one is much less likely to have at hand all the details and thought that went into the original design, and for that reason it's easy to make a mistake in the modification that wouldn't have happened the first time around. For instance, it's common for a design mistake to be found and corrected, then later someone will uncorrect the fix, mistakenly thinking that the original way was better after all. By documenting the reason for the correction, later reviewers will learn from past mistakes and not repeat them.

Substantive changes:
    March 2, 1996: created.
Copyright © 1996, Steve Colwell, All Rights Reserved
Home page