INTRODUCTION
Today we begin a series of posts designed to explore a common decision- replacing an aging automobile- in the context of some systems engineering concepts. What will follow is by no means a comprehensive treatment of SE concepts or the process of purchasing a replacement vehicle. It is merely an attempt to use the lens of a commonplace decision to focus on some helpful SE principles and practices. Please enjoy!
FRAMING THE PROBLEM
We have all found ourselves in the position of needing a new automobile. The process of choosing that next car can be daunting. There are a myriad of choices and a host of considerations that must factor into the process. Although most people don’t think of it in this way we all go through some sort of systems engineering process in order to select a new car. Organizing that choice can become a good illustration of some of the basic principles of systems engineering.
We begin of course, with requirements. It is helpful to start the process at a very high level. My 2007 Toyota Camry sits in the parking lot with 270,000 miles on its odometer. The time is approaching for me to consider purchasing a new (brand new) or newer (than my current) vehicle. (Just two sentences into our example and we already have a potential trade off consideration. Should I buy a new or used vehicle?)
By starting at a very high level I can consider the primary purchase rationale for the new vehicle. I drive the vehicle from home to my workstation and back every week, a distance of approximately 400 miles each way. Most of this driving is done at highway speeds across the interstate system. I need a vehicle which will reliably carry me and my possessions back and forth approximately 45 times a year.
At this point we should pause to notice that even in this high level discussion I have already made a design assumption which may or may not be warranted. I am assuming that I will replace the legacy system (my existing automobile) with another car. Had I begun with the highest level requirement, that of moving me and my possessions from my home to my workstation and back again, together with the behavior necessary to accomplish that, it would have been apparent or at least more apparent, that that behavior could have been allocated to physical architectures other than a successor automobile.
This highlights an all too typical problem in the replacement of legacy systems, the failure to track back to high level behavior stead of beginning with assumptions about the physical architecture. By not focusing on the behavior at the highest level we may well lose a whole set of potential design choices.
In this case an obvious alternative choice would be to fly instead of drive. This would allocate the behavior of transporting me and my possessions to an airplane instead of an automobile. In fact, at an earlier juncture in my travel life I did accomplish my weekly trips via airplane. There was a system design decision point at which I decided for a variety of economic reasons to reallocate that behavior to an automobile and it was at that point that I begin to drive instead of fly.
But in any case, it is helpful to leave the entire field of choices unencumbered by physical design assumptions in order to produce the broadest possible set of alternatives for consideration. Often in systems design projects some of the potential design choices are foreclosed by such assumptions. Sometimes the assumptions are made unconsciously without any intentional choice to make them or not.
NEXT TIME: HIGH LEVEL REQUIREMENTS
The Rest of the Series: Check back as we explore the rest of the process.
