In our world, where it is increasingly necessary to replace legacy systems with new systems that answer existing requirements, it is especially critical that our process surface all assumptions in order to permit us to make intentional design choices. This is best accomplished by beginning our analysis at the highest level and explicitly constructing the behavioral model from our high level requirements. Any attempt to leapfrog the behavioral analysis step and proceed directly to allocating requirements to a physical architecture creates an environment which invites the unintentional introduction of design assumptions. These can shove aside potential design choices which would then be lost to us as we design the system.
We see here the advantage of beginning our analysis at the very highest level and explicitly considering the high level behavior. We will begin with the high level requirement to transport Zane and his equipment to and from his work station each week.
Now that we have started to construct a model of the system that we will use to replace my five-year-old, 270,000 mile Camry, we can begin our analysis of the originating requirements for the system. At this point our model contains a single requirement,” the system shall transport Zane and his possessions from his home to his workstation and back again.” The high-level behavior is to transport Zane and his possessions from his home to his workstation and back again. At this level the implementation system is represented graphically by a “gray box” architecture.
The first task is to capture the originating requirements insofar as they are known. These can be determined by looking at the concept of operations statement concerning the existing system. In this case it is necessary to travel from home to my workstation on a weekly basis. The distance between home and the workstation is approximately 400 miles. All but 60 of those miles are across interstate highways where the speed limit is 65 to 70 miles per hour. Together with incidental travel at both ends the total mileage becomes approximately 900 miles per week. Experience with the legacy system (per the Camry log) shows the gross yearly travel to average 45 to 50,000 miles per year. (Alternatively the trip can be made from the tri-Cities regional Airport to Baltimore-Washington’s Thurgood Marshall International Airport with ground transportation at either end.)
Although the trip is weekly it is not made every single week of the year. Of the 52 weeks in the year the trip is made approximately 45 times. The system must also make provisions for local travel at the work destination during the week. The system must provide transportation for trips to other destinations during the year. It is frequently necessary to stop in Blacksburg on the way to and from home in order to transact business in the company office located there.
Given these requirements, the system must perform these functions at the lowest possible total cost. These form the basic requirements for the system. Using them we can decompose the high-level behavior with which we began. This will allow us to see that we have several alternatives for a physical architecture. For the purposes of this example we will consider that there are three basic alternative physical architectures.
NEXT TIME: ALTERNATIVE ARCHITECTURES
The Rest of the Series: Check back as we explore the rest of the process.
