We can use the requirements and behavior as the basis for purchasing a replacement vehicle. But we could also use some form of air transportation to cover the long segments of the trip. This would have to be coupled with some sort of ground transportation at either end to provide for transportation needs that could not be covered by airplanes. The third alternative would be to use an automobile rented from a vendor rather than owned by the system.
In comparing (verifying and validating) the second alternative, air transportation, against the originating requirements it becomes clear that two major obstacles mitigate against further exploration of this alternative. In doing a rough economic evaluation of this alternative against the lowest possible total cost requirement it becomes clear that the fact that the airline flight must service a small regional airport acts to greatly increase the cost of the tickets (~$700/trip at 45 trips per year is $31,500). Coupled with the fact that any air transport solution must include a provision for destination ground transportation and the attendant costs associated with that, the relatively high cost of either commercial or charter flights make it hard for them to compete with either owned or rented ground transportation solutions. However, because we are constructing models of the alternatives we can model the air transportation alternative and run verified cost comparisons against the other alternatives. This is one of the significant advantages to using a model-based approach to the systems design.
We have so far constructed a high level model of the system and gathered the originating requirements. It is clear that we must move across the requirements, behavior and architecture domains as we create a more and more detailed model of the system. Likewise, we test each successive iteration of the model in a more and more detailed way. At the levels which we have explored our testing of the model has been at a gross estimation level. (We used an approximation of the cost of airline tickets to establish a gross estimate of the yearly cost in order to get an idea of where we’re headed with that particular architecture.) In our next post we will push the derivation of requirements and behavior in the detail of the design alternatives further and further as we drive toward the ultimate solution.
The Rest of the Series: Check back as we explore the rest of the process.
Can i have access to Part 1 and Part 2 of this series:
Part 1: Framing the Problem
Part 2: High Level Requirements
Part 3: Alternative Architectures
Part 4: Some Basic Decomposition
Part 5: Zeroing In
Part 6: Conclusions
Are Part 5 and 6 out?
My apologies. Part 1 and part 2 of this series appear to have been lost during a platform migration. They have been recovered, re-published, and re-linked. Parts 1-6 are all available and properly connected. You can find the first blog at https://systems-wise.com/how-to-buy-a-car-like-a-systems-engineer-part-1-framing-the-problem/.