Introduction to Systems Engineering

Systems engineering is defined in many texts. Rather than repeat the standard definitions at this time it is helpful to define these terms in the simplest possible manner. The reason is that having very simple definitions helps us to consider things from a fundamental point of view, which makes it easier to come up with new insights. Later traditional definitions are presented and comparing the two may give new insights. New insights are needed in order to understand new methods and, eventually, to develop improved methods. This chapter, presented in several articles, defines four fundamental tasks that systems engineers perform, provides definitions of systems engineering, compares the rolls of systems and design engineers and shows how systems engineers fit in a modern product development organization. The four systems engineering tasks are deliberately defined before defining systems engineering or systems engineering processes. Although this seems out of order it helps take a fresh look at systems engineering methods. To set the stage for defining the four tasks of systems engineering we look at the overall product development process or development cycle as it is usually called.

The Product Development Cycle

In the exercises at the end of the last post the reader was asked to define the product development cycle in simple terms a grandmother would understand, assuming the grandmother is not a systems engineer. The purpose of this question is to make the reader think about the fundamental tasks that comprise product development. Sometimes people get into the detail of their work to the point they lose sight of the fundamentals of what they are doing. Figure 3-1 illustrates what the reader might have said.

Figure 3-1 Product development consists of five tasks, or phases, at a fundamental level.

Product development organizations typically define the product development cycle in a much more complex diagram, or set of diagrams, that describe the tasks to be performed in much more detail than shown in Figure 3-1. However, it is important to step back and look at the fundamental tasks, or phases if you prefer, in as simple of terms as possible if we intend to improve the overall process. Starting with the simple flow chart in Figure 3-1 we define the work that systems engineering encompasses, again in simple terms, because our objective is to seek better methods for systems engineering. Note that Figure 3-1 leaves out the object of the verbs. This forces us to think about what it is that we are defining, designing, etc. For example, it’s necessary to define both the product and the program for developing the product. Decisions must be made about what will be designed, what will be tested and what will be produced. These decisions are product dependent and involve systems engineers if only as advisors. We can add some of the top level inputs and outputs of each step in Figure 3-1 as we think about what it is that we are defining, designing, etc. A result for one type of product might look like Figure 3-2.

The tasks shown are performed by a variety of managers, technicians, and engineers; systems engineers, design engineers, test engineers, etc. We seek to define just the tasks performed by systems engineers. Actually systems engineers are involved in all five tasks to some extent. Typically systems engineers are responsible for the specifications and plans that are produced in the “Define” task and contribute to or oversee work in the other four tasks. With these roles in mind we can think about the tasks the systems engineers perform. Recall that here nontraditional terminology is used at to describe the systems engineering work.

Figure 3-2 The outputs of a fundamental product development task are the inputs of the next task

Four Fundamental Tasks for Systems Engineers

A simple but useful terminology for defining systems engineering work is shown in Figure 3-3.

Figure 3-3 Four fundamental tasks performed by systems engineers during the product development cycle.

The four tasks listed in Figure 3-3 are not the only way to define systems engineering tasks, or are these are a complete description, but these four tasks help us understand the fundamentals, if we allow for some flexibility in our definitions. This becomes apparent as we examine in more detail the four tasks in later chapters.

Notice that the first three systems engineering tasks are shown as overlapping in time rather than being sequential in time. This is because these tasks should overlap in time. This is a good point to introduce one complexity in the fundamental task list shown in Figure 3-1, then we can return to defining systems engineering.

Progressive Freeze of Product Development

The product development tasks should not be rigidly sequential but should allow for some overlap in time, as indicated in Figure 3-4.

Figure 3-4   The fundamental product development tasks should be allowed to overlap in time.

Often major product development tasks, or phases, are gated by milestone reviews. This implies that all work must be completed on one phase of the product development before work can start on the next phase. It is not good practice to demand rigid adherence to the gating process. A better approach is to allow some work to begin as soon as the information needed for initiating the task is available. This is called progressive freeze, as discussed in previous  articles, and it adds flexibility to the work that offers benefits that outweigh the small additional risks incurred.

Progressive freeze is practiced by freezing an element of the engineering work, when the risk of freezing the work is acceptable and allowing work on the next phase to begin before the next milestone review. Engineering judgment is used to determine when the risk is acceptable that the continuing work on other elements of the development work won’t change the results of the frozen work element.

A couple of examples help understand the progressive freeze concept. Consider a radio frequency (RF) sensor. Freeze the antenna architecture when the gain, antenna configuration and interfaces are determined; initiate the antenna design in parallel with other subsystem architecture trades. Hold a system design review (SDR) or architecture review, if required, when all subsystem architectures are frozen. Second, consider an infrared sensor. The telescope architecture can be frozen when the aperture size, the form, the optical subsystem f/# and interfaces are determined. The telescope design can then proceed while the focal plane, electronics and cooling architecture trades continue.

There are several benefits from beginning the design early for the RF antenna or the telescope in these two examples. The biggest is the flexibility in scheduling the skilled antenna and telescope designers. Critical skills such as these are often in high demand on several programs. By enabling early starts of the design work involving critical skills it increases the total time period for the design work to be accomplished without impacting the program schedule and helps avoid program delays due to the unavailability of critical skills.

A second benefit is that progressive freeze facilitates sequencing design decisions throughout a design phase. Product development involves thousands of decisions in each phase of the work. Delaying decisions until just before major design reviews complicates decision management to the point that the quality of the work can be threatened. Making decisions as soon as risk allows spreads the decisions throughout a development phase and makes decision management easier. We will return to this issue in a later chapter where we explore design decision management in more detail.

 Another benefit is that should a problem arise in the design that impacts other architecture the architecture changes can be made easily if these trades are still underway. For example, suppose the RF antenna designer discovers that the desired gain margin cannot be achieved within the constraints defined in the architecture trades. If the other trades are still underway it is much easier to decide how to accommodate the problem. It may be that a larger envelope is available or it may be that the lower gain is acceptable with tighter control of noise figure in the amplifier electronics. Finally, allowing more time for the designers to work on a design element may result in a better design. Sometimes engineers need to set work aside for a short period while they mull over a difficult design issue. Sometimes unforeseen difficulties arise in design and having extra time to work out these difficulties helps avoid program delays.