Processes and Tools for Defining a System

6.0 Introduction - In Chapter 3 the product development cycle was defined in the simplest possible terms as “define, design, build, test and produce”. Four systems engineering tasks were defined to be carried out over the development cycle although there is not a one to one correspondence between the five steps in the development cycle and the four systems engineering tasks. Chapter 4 discussed processes and tools for the first systems engineering task, Plan the Program. This chapter addresses the second systems engineering task, Define the System. Chapters 8 and 9 address the remaining two tasks, Selecting the Preferred Design and Verifying the Technical Performance. After some introductory material this chapter and chapters 8 and 9 cover the systems engineering process as  described  in Figure 3-1 of the DoD SEF handbook. Because of the four task approach being followed in this text the flow does not follow the DoD systems engineering process step by step. However, this text follows the DoD nomenclature as much as possible and adds some useful tools. It is hoped that the reader studies both this text and the DoD SEF handbook and that, by studying the process in two different ways, gains deeper insight into systems engineering.

6.1 Overview of System Development and System Engineering Processes

System  development is a complex process and there are almost as many diagrams defining this process as there are handbooks of systems engineering. Before showing diagrams illustrating the Define the System task it is helpful to examine some of the more popular diagrams. Rather than repeat the detailed diagrams, which are available in the referenced handbooks, simplified diagrams are presented here that just show the approach to defining the development process or the systems engineering portion of the development process. The reader should always keep in mind the five fundamental steps of define, design, build, test and produce to keep oriented when examining these diagrams.

6.1.1System Development Diagrams - Perhaps the most popular diagram historically is the “VEE” diagram, which is shown in the NASA Systems Engineering Handbook SP610S of June 1995 and attributed to Kevin Forsberg and Harold Mooz, A Commitment to Success, Proceedings of the first annual meeting of the National Council for Systems Engineering and the 12th annual meeting of the American Society for Engineering Management, Chattanooga, TN, 20-23 October 1991. The VEE diagram describes the overall development process as a downward flow of decomposition and definition, connected to an upward flow of integration and verification as shown in the simplified diagram in Figure 6-1. The decomposition and definition starts at the top left with the “requirements analysis” task and ends with a tested system at the top right. This diagram is appealing because it illustrates both the “flow down” and “flow up” aspects and the sequential progress of the overall process with a rightward flow suggesting time or schedule. The time flow enables listing sequential tasks or design reviews along each leg of the V.

Figure 6-1 A VEE diagram illustrates tasks in two of the main activities of system development.

The 2007 version of the NASA handbook replaces the VEE with a more detailed diagram that adds the technical management and control aspects of the development process and changes some of the nomenclature. A simplified version of this diagram is shown in Figure 6-2. Although the 2007 diagram lacks some of the ascetic appeal of the VEE diagram it is more representative of the complexity of the overall process. This diagram also substitutes the more abstract descriptions  “system design processes” and “product realization processes” for the more descriptive and simple terms “decomposition and definition” and “integration and verification” used in the VEE diagram. This tendency to abstract the processes for completeness at the expense of clarity is a primary reason to keep coming back to the simplest terms of define, design, build, test and produce.

6.1.2 System Engineering Process Diagrams - The IEEE 1220-1998 and DoD handbooks focus on the system design part of the overall development process and provide more detail on this part. A simplified version of the IEEE system engineering process diagram is

Figure 6-2 The system development process as defined in the NASA Systems Engineering Handbook SP-2007-6105 Rev 1, Dec 2007 includes the technical management processes.

shown in Figure 6-3.  This diagram more explicitly brings in the important trade studies and assessment activities that are necessary for achieving a good system design and lumps the technical control processes into one box labeled Control.

Finally, the DoD handbook illustrates the system engineering process with a diagram that includes the important iterative nature of system design. A modified version of the DoD diagram that includes the technical management processes from the NASA diagram is shown in Figure 6-4. It also explicitly includes trade studies as in the IEEE diagram.

The DoD diagram more explicitly represents the iterative rather than sequential nature of systems design. One aspect of design that isn’t obvious in these standard diagrams is the option for design synthesis being either top down, bottoms up, or a combination of top down and bottoms up. An example of the bottoms up design approach is designing a new car model by choosing from sets of available engines, transmissions, suspension systems and other major subsystems. Many of the requirements analysis, trade studies and assessments involved in top down design are still needed to ensure a balanced design and verify the design but the overall development process is streamlined by having proven subsystems available for the class of system being developed. An experienced systems engineer can interpret the loops in the DoD diagram as allowing for starting a process at any point on a loop but this isn’t apparent to the novice. The remaining discussion in this chapter treats the system design processes as top down for convenience but should not be interpreted as endorsing only a top down design approach.

Figure 6-3 A simplified version of the IEEE 1220 diagram defining the systems engineering process illustrating the three types of trade studies and analysis central to systems design.

Figure 6-4 A Combination of the NASA and DoD diagrams of the systems engineering process includes the technical management processes, the three verification processes and illustrates the iterative nature of requirements analysis, design synthesis.

By now the reader should have concluded that the system design process is sufficiently complicated that it isn’t easily defined in any one diagram. Similarly, systems are sufficiently complicated that many diagrams are needed to adequately define them. It isn’t wise to attempt to define a fixed list of diagrams and documents needed to define systems either because the complexity of a system and the maturity of the development team usually determine what diagrams are necessary.