Given our analysis to this point, air travel at $30K+ per year is clearly uneconomical. Had the gross analysis indicated that it was in the $10K to $15K range we might have continued our analysis because its performance against other requirements might have made it a viable choice. But its delivery of a cost profile of over 3 times what we would expect causes us to eliminate it as an alternative for further consideration.
Depending upon how we feel about the validity of the cost analysis done to this point and the relative importance we assign to it we might also eliminate the rental option at this point. For the sake of this example we will continue considering both options as we develop the system further. By so doing we will avoid the dangers of too much convergence and continue the analysis.
At this point we will turn to the additional requirements that grow out of the higher level requirements statements. As an outgrowth of cost concerns we are also concerned with fuel efficiency. We can establish a quantifiable level by looking at the range of possibilities. Along the same lines we are concerned with maintenance reliability. We could gather this information from a variety of sources that rate cars on their reliability. Research can be an important piece of our design effort as we test our alternatives against our requirements.
We also need to explore the requirements further with our stakeholder- me! Because of the amount of time involved in travel the system must provide some undefined minimum level of comfort and convenience. In the past I have expressed this requirement by joking that any automobile which I might use for this purpose needs to have two features: a cruise control and a CD system. The CD system allows me to pass the time with listening that ranges from educational to entertaining. The cruise control helps me to avoid the speeding infractions that can result from continuous manual monitoring of speed for extended periods as well as escaping the fatigue of constantly applying pressure to the gas pedal.
We are now beginning to get a more robust requirements picture. We need a car that will have a fuel efficiency of “x”. We need a car that has a maintenance reliability rating of at least “y” (naming some standard rating system). We need a car that can control the speed at a set level and can play CD based media.
As we develop these requirements we also need to develop the behavior. Our logical architecture will now reflect the car conveying Zane and his equipment back and forth at a fuel efficiency of at least “x” and controlling its own speed. As we make these refinements we will determine that there are further considerations. For example, the behavior of controlling its own speed must receive an input setting that speed. This should come from the driver. That implies an additional requirement.
The behavioral (or functional) architecture will be allocated to the physical architecture. Our car architecture will be modified or elaborated to include a cruise control that accepts driver input so that the “control speed” behavior can be allocated to that component. At each level of granularity we move back and forth from domain to domain. And at each level we verify and validate the physical architecture back against the requirements.
NEXT TIME: CONCLUSIONS
The Rest of the Series: Check back as we explore the rest of the process.
