Life As A System

Let’s go back to The Fearless Trapezoid and the TrapezoidMobile for an example of design specifications.  I’m not going to get too deep into the design specs (I’m not someone who knows how to design vehicles), but I’d like to provide a short example, given the previous discussion on the TM’s design requirements.

With the speed requirements of the TM, you can start to design a vehicle.  In order to reach a higher speed, you usually need a bigger engine.  You can start to design the specs for the size, RPMs, number of cylinders, and actual shape of the engine.  You can design the shape and length of the TM’s body, as well as the size and shape of the tires.

The problems, as I alluded to, lie in the interfaces.  A fast engine may cause TFT to spill the super math-juice used to power a fight against crime and bad geometry solutions.  So, you need to trade off the aspects of design.  I’ll get to tradeoff studies in another post (there is a quantitative way to do them), but for now, we just need to know that an improvement in one requirement may mean a degradation in another requirement.

The heavy engine and requirement for speed may mean that some hardware for the supercomputer needs to be left out, and that the supercomputer isn’t as super as it could be.  This is where the interface may cause some problems, as you either have to trade engine size off for computer size, or computer size for engine size.

And I’m going to wrap it up before long.  As you can tell, us systems engineers are not specialists in design specifications.  This is where the really detailed engineering work comes in, but we are there to guide the process.  I’m interested in hearing about interface issues, though.  Anyone run into interesting interface specification mismatches out there?  Comment below!