The design-decision-tree visualizes design as an exploration along the limbs of a tree of possibilities. The exploration starts at the root with the first vague statement of the problem, and ends at a single leaf with the development of a single specific solution. The exploration proceeds by way of decisions, each of which is represented by a branch of the tree. As we take one fork or another, we reduce the ambiguity in the problem and get closer to the solution. But these decisions are simply dreams until we convert them to agreements, which is the subject of this chapter.
Most of this book has been addressed to the decisions nearest the root of the tree—at least they are the decisions which should be nearest the root. If these decisions have been well made, we can proceed with confidence and efficiency to design a product to meet those requirements. If decisions are poorly made, we will often need to go back down the tree to an earlier branch, or else settle for a less-than-ideal solution. The purpose of all our requirements work is to put us on the right branch, and also to prevent backtracking.
By the time we've finished our requirements work, we've made hundreds or thousands of decisions. We've made many of those decisions directly and consciously. These we call choices. But not all decisions up to this point are choices, for some were made unconsciously by default, through bias, error, or lack of information. These decisions are called assumptions.
Other decisions were forced into the project—possibly by law, or custom, or higher authority—or perhaps they sneaked into the project without our noticing. In either case, these decisions were made for us by someone else, so we will call them impositions. Let's see how best to apply this knowledge using our elevator example.
Figure 24-1. The requirements work establishes a structure of strong limbs onto which the design, the implementation, and the product can grow. Without the requirements work, we may have all the information, but it may be cut up like a random pile of logs.
Here are some decisions in the design of the Elevator Information Device, each of which could be a choice, an assumption, or an imposition:
1. There will be only one control/display panel per elevator car.
2. The elevators will travel vertically only.
3. All New York State elevator codes must be observed.
4. No smoking or carrying of lighted tobacco products will be allowed on these elevators, and the system must be designed to enforce this provision.
5. During a fire in the building, the elevators will be accessible to emergency personnel only.
6. All but emergency power will be supplied by the building through the public utilities, to IEEE standards.
7. The only source of emergency power available whenever the building power fails will be the backup power supplied by the Elevator Information Device.
8. This backup power will be from storage devices such as batteries. It will not be generated.
9. The backup power must be adequate to drive all necessary information device functions at their normal level of performance for at least four hours.
10. The elevators will be standard-sized cars for large buildings, ranging in floor area from 8 by 8 feet to 12 by 15 feet. Ceiling height will range from 8 to 12 feet.
11. The elevator cars will be rectangular in shape with flat, horizontally oriented floors and ceilings when in the normal operating position.
12. The elevator must be safe at all times.
13. The internal elevator temperature may vary from 60 to 80 degrees Fahrenheit.
14. At least one side and the floor of the elevator car will be totally available for controls, displays, and other necessary functions of the information device.
15. People will enter and leave the car from the front and/or rear through standard telescoping elevator doors.
16. People will observe the legal elevator load limits. There will be no stacking, pushing, shoving, or crushing of people.
17. The elevator speed will be limited to 1,440 feet per minute; the acceleration, to ±4.4 feet per second squared.
18. The Elevator Information Device will be completely contained within or attached to the elevator—one device per car.
19. All information used or generated by the device will be available at the car. All information-sensing and -transmission functions will be the responsibility of other parties.
20. The car will be lighted at all times, except after four hours on emergency power.
21. Individuals who attempt to fool the system or make it look foolish (such as computer hackers) will be ignored.
22. No part of the device may intrude more than one-quarter inch into the elevator car.
Even with this partial list, you can see what controversies are avoided by making the jurisdiction of each of these choices explicit. For example, take this requirement:
2. The elevators will travel vertically only.
This requirement could also be an assumption—we never thought of an elevator as traveling horizontally, or even up an incline like the elevators on the Eiffel Tower. If we never thought of it, we could be limiting the market for our control system as design decisions depending on "vertical" become more and more hard-wired into the system.
Of course, any written-down requirement is presumably not an assumption. That's one of the best reasons for converting all choices to written agreements—anything that's not written down is automatically open for discussion at best, and is a poor, unilateral decision at worst.
If someone notices the vertical restriction, the discussion could be quite heated about where it came from. It could be an imposition required by law in certain states, but it could also be a choice if we consider the market for non-vertical elevators too small to justify the extra effort. Since it's important for the designers to know which it is, every requirement should be traceable to its source.
For instance, if the requirement were an imposition, the restriction could be rewritten as
2. The elevators will travel vertically only because by law none of the states in our marketing area allow non-vertical elevators.
This informs the designers under what conditions it might be worth questioning this restriction, and perhaps gives them an estimate of how much it would be worth to allow for future non-vertical extension of the system.
On the other hand, if the restriction were a choice, it could be expressed as
2. The elevators will travel vertically only because we don't see any appreciable market for non-vertical elevators at this time.
Now the designers have slightly different information about what might happen in the future.
In the decision tree model, we can think of the requirements process as an orderly, reliable way of creating the trunk and the first major limb on which the design branch, the implementation twig, and finally the product leaf will grow. If our assumptions are not reliable, they will not form a reliable limb to support the design process.
Some assumptions are just false right from the start, though we are not aware they are false. Assuming the human body was immune to asbestos, builders used asbestos/concrete pipe and asbestos insulation sprayed on walls. This assumption caused thousands of deaths.
Some assumptions are true now, but gradually become false. When the telephone system in the United States was designed, calls were assumed to arrive more or less independently. But the telephone system was designed before the radio became widespread, and little by little, people all over the country began to be tied together by radio. On April 12, 1945, the announcement of Franklin Delano Roosevelt's death was broadcast over the radio. A large number of people heard the news at the same time and picked up their telephones to tell someone else. The entire telephone system was swamped and died, and so did the assumption of the independence of calls.
Economists sometimes make an assumption they call the "perfect market." In a perfect market, selling a product doesn't affect the size or quality of the remaining market. In real life, of course, there are many "imperfect" markets, and some assumptions are rendered false by the product itself, once it comes into use.
For instance, certain load factors are assumed in designing a computer system, and the system is built with large capacity to handle the maximum assumed usage. But the old system's low capacity resulted in poor response, and so restrained the load. Now, when the new system's larger capacity removes the restraints, the load increases. Sometimes, the load changes so much the new system is also swamped, but at a much higher level of traffic. This is called the "turnpike effect" or "parking lot effect," from two other common occurrences of the same phenomenon (Figure 24-2).
Figure 24-2. The turnpike effect, or parking lot effect, occurs when the introduction of a new facility with larger capacity ultimately results in swamping by calling forth more load.
Assumptions can also be invalidated by requirements leakage. Whenever a product is used, new requirements are born. They may be requirements for more capacity as in the turnpike effect or requirements to "fix" problems—which may have been caused by mistakes in requirements, design, implementation, or training. They may be requirements for new functions, as the users master the existing function and now want to go where no one has gone before. If you look at any product a year after it reaches the users, you can be sure that literally hundreds of new "requirements" have leaked in (see Figure 24-3).
Figure 24-3. Requirements leakage occurs when new requirements are introduced by other than the official requirements process. In one software organization, 202 leaks were documented for a single product, in 6 weeks, from 14 different sources.
The purpose of requirements work is guiding future actions in developing a product. But even if all the decisions have been made correctly, they may not suffice to guide future actions correctly. In particular, assumptions and impositions create conditions not under the developers' direct control, conditions determining the success or failure of the project. These assumptions and impositions represent risks to timely and efficient project completion.
Because impositions can be seen as intrusions, some of the implementors may resent them, or at least disagree with them. They may refuse to conform to the impositions, yet every nonconforming action drops the project off the correct branch of the design tree.
Because assumptions may be implicit, it's likely some people won't really understand them. Similarly, others will misunderstand choices made but not communicated. Indeed, if choices are not communicated, some people may simply be unaware of their existence. So, even if participants' intentions are blameless, they may fall off the correct design branch out of ignorance.
In short, much requirements work will be negated if choices, impositions, and assumptions are not both understood and accepted by everyone involved. Thus, before moving out of the requirements phase into the rest of the design process, all parties must understand and accept their responsibilities. Otherwise, customers will be disappointed when the product is delivered. To ensure understanding and acceptance, you must attempt to convert every choice, imposition, and assumption into an explicit, documented agreement.
1. We like to have people actually sign their names to signify agreement. Some people say this practice is too formal, but we've found a document is just another piece of paper with little value if it lacks a signature,. The signature adds value.
2. Think of signing as yet another test. If people hesitate to sign, don't try to pressure them into signing. Instead, work with them to discover what's holding them back. You'll almost always find another assumption worth documenting.
3. "Teams may work from sun to sun, but requirements work is never done." Some definition of assumptions is always left to the designers, builders, and users. What you can do, however, is document the meta-assumption: certain assumptions are being left to others to define.
4. One way to document assumptions left to others is to create safety factors, a traditional way for engineers to say, "We don't know what to assume here. Therefore we're allowing a large margin for error—the error in our knowledge of assumptions." Take your lead from the engineers and express safety factors by saying simply, "We don't know what to assume here, so we're assuming a wide range. This may lead to overdesign, so watch for opportunities to narrow this assumption."
5. The safety factor image shows what underlies the attempt to get agreement is the concept of risk. When you try to convert assumptions to agreements, you are really trying to reduce risk. As you go through this process, you needn't think of it as pure documentation. Ideally, you will notice areas where you can transform some assumptions into actions to reduce the risk. For example, you may agree to a process for seeking what's missing. Or for buying insurance against failure. Or for involving someone with special resources in the development.
Elevate all assumptions to consciousness so you can control them as the development process continues.
Just before you believe you are finished, test your assumption you are done by getting explicit, written agreements.
To move toward agreement, take the following steps:
1. Write down every assumption.
2. Trace each assumption to its source: Is it a choice, an imposition, or an agreement?
3. Add information to identify the source of each assumption.
4. Get participants to sign their names to each written document.
5. Look for opportunities to agree to actions to reduce risk caused by assumptions.
Anyone left out of the agreement phase will show up later and make trouble, so include everyone whose later objections could be troublesome.