What is System Engineering?
The only real technique we humans have for attacking complex problems is “divide and conquer”: i.e., we break a complex job down into a series of simpler jobs. When the goal is to design and build a complex system, we break the system down into subsystems, and we break the skills needed to perform the work into separate disciplines. This allows us to bring more manpower to bear, which is efficient and necessary (see project management). However, what we pay for this benefit is often a loss of overall perspective on the project. Breaking a system down this way brings with it the danger of overlooking something important. It is thus the job of system engineering to decide how best to break things down to maximize the benefits and minimize the disadvantages, and then to attend to the overall project as a whole, to anticipate problems and to prevent things from “falling through the cracks”.
In systems engineering, we consider how subsystems interact, and how a system as a whole interacts with the environment. Every engineer deals with this to some extent, because even the most basic component is a system at some level. However, top-level systems work on complicated programs is an engineering discipline in it own right. It requires a broad technical background, a lot of curiosity, and a nose for ambiguities, muddy thinking, unexamined assumptions, and oversights. In large part, successful system engineering involves simply asking the right questions
Some of the organizational tools of system engineering are interface definitions, trade studies, requirements flowdown analyses, and tolerance budgets. A basic analytical tool is the block diagram, which enables a single person to focus on different levels of abstraction, as required, when thinking about the system. These tools are necessary, but their employment is no substitute for simply thinking deeply about “what can go wrong?” and “what will be required?”.
While the system engineering methodology is very powerful, it is important that one not become fixated on top-down system design. Sometimes bottom-up as well as top-down design is required for success. A good example, which I have seen violated several times with disastrous results, is when a key technology must be mastered before a system can be successfully designed using it.
|
Copyright © 2002, David F. Schaack. All Rights Reserved. |