A Guide to the Systems Engineering Body of Knowledge (SEBoK)

II. Systems Engineering Processes

by Dennis Buede, Kevin Forsberg, Hal Mooz, Catherine Plowman, Bob Tufts

Systems Engineering is a set of processes performed by people (assisted by automated support tools). This section provides the reader with various descriptions of these systems engineering processes and their temporal relationships. The reader should understand that there is no cook-book recipe for performing systems engineering because there is such great diversity in the kinds of systems that are produced by the systems engineering activities, in the characteristics of customers and associated users/operators/maintainers/manufacturers/etc. As a result experienced systems engineering practitioners tailor their favorite processes to meet the needs of each specific project.

The purpose of this section is to describe several generic systems engineering process models, each of which highlight different aspects of an overall, complex systems engineering process. These process models are the traditional system development life cycle model of the U.S. Department of Defense, a highway design life cycle process model that is an adaptation of the traditional defense system development process, the Vee Model of Systems Engineering Design and Integration, Tufts’ Systems Engineering Process Model, Plowman’s Model of the Systems Engineering Process, and the INCOSE Handbook process model.

Traditional Defense System Development Life Cycle

The traditional system development life cycle model (see Figure II-1) of the U.S. Department of Defense provides a serial representation of major activities as well as well-defined reviews and document baselines. Time progresses from left to right in this model; most people are willing to agree that the activities in the boxes should not be serial. Generally though these process start and stop in the order presented.

Figure II – 1. Traditional Defense System Development Life Cycle

Highway Design Process Life Cycle

Members of the Systems Engineering Applications Working Group of INCOSE modified the traditional system development life cycle model of the U.S. Department of Defense to represent highway design. The reviews and baselines were removed and defining issues were added.

Figure II – 2. Highway Design Process Life Cycle

Vee Model of Systems Engineering Design and Integration

The Vee Model is a system development model designed to simplify the understanding of the complexity associated with developing systems. Predecessor models of the Waterfall and Spiral, while making important contributions to the understanding of the process, fall short in conveying several important concepts necessary to doing development right the first time and every time.

The Vee model is rooted in the project cycle, which is displayed from left to right to represent project time and maturity. Coupled with this depiction is the recognition of levels of decomposition, which are illustrated, in the vertical dimension from top to bottom. The User is at the highest level and parts and lines of code the lowest. The plane orthogonal to the plane of the Vee illustrates the number of entities at each level of decomposition, which relates to the complexity of the system.

The concept of an evolving baseline, progressively increasing in depth and under change control, creates the Vee shape, which is called the core of the Vee. The left leg of the Vee represents Decomposition and Definition and the right leg represents Integration and Verification

An important attribute of the Vee diagram is the “Time Now” line, which explicitly highlights the iterative nature of the development process. Iterations between levels of decomposition are an important part of system development and definition. Since one can never go back in time, all such iterations are vertical on the “Time Now” line.

The most significant contribution of the Vee is recognition of the off-core activities. Downward off-core activities on the left leg allow investigation of opportunities and risks to justify baseline decisions on the Vee core (see Figure II-3). The off-core results are not baselined but are used to justify on-core decisions as being valid. Unlike the spiral model investigations may be conducted in series with or in parallel with normal development activities.

Figure II-3. Design Activities in the Vee Model

Upward off-core activities encourage in-process validation with the user. When the user approves progressive baselining decisions then it is highly probable that the end product will be satisfactory.

Downward off-core activities on the right side of the Vee (Figure II-4) are used to investigate and resolve anomalies discovered during integration and verification, which may lead to adjustment of the as verified baseline. Again upward off-core activities provide in-process validation with the user to achieve continuous buy-in to the solution as it evolves.

The Decomposition Analysis and Resolution Process orthogonal to the left Vee leg provides for the trade studies leading to the baselining decisions. The Verification Analysis and Resolution process orthogonal to the right Vee leg provides for anomaly correction and/or baseline modification.

Figure II-4. Integration and Verification in the Vee Model

Tufts’ Systems Engineering Process Model

The processes selected for this model are those associated with EIA632 and the Integrated Capability Maturity Model (CMMI). One purpose for selecting these systems engineering processes is to use those most recognized as the core processes for most systems engineering projects (see Figure II-5). A second purpose is to identify other systems engineering processes used on many projects, but are not recognized as common enough to be included in formal standards.

This model defines eight high-level activities, each of which is composed of two to eight lower level activities. These high level activities span the front end marketing and business capture to operations and maintenance portion of the life cycle.

Time generally starts at the top and proceeds to the bottom. However the dual up and down arrows between Project Management and Program Office Support/Systems Integration, as well as Program Office Support/Systems Integration and each of Requirements and Architecture Development, Product Design and Development, and Systems Integration and Test indicate that time is not strictly moving down. The presence of these dual arrows indicates that information and physical items can move in both directions between lower level functions of the associated high level activities.

Within some of the boxes associated the high-level activities there are arrows that move generally from left to right; in these cases time does move from left to right and the intention is to have the lower level activities proceed serially. The remaining high-level activities do not have arrows between lower level functions inside the box. In these cases all of the lower level functions can proceed concurrently due to the complex and iterative nature of the systems engineering process.

Figure II-5. Tufts Systems Engineering Process Model

Plowman’s Systems Engineering Process Model

System Engineering is a structured discipline that considers all aspects of a particular system (physical and organizational) in helping programs and projects conceive, develop, integrate, test, and deliver products and services that meet customer requirements within cost and schedule. The following description of the process, functions, and products of Systems Engineering was derived from study of: MIL-STD 499B, ISO 15288 (draft), EIA 632, EIA 731, Lockheed’s Code 66, Lockheed-Martin’s EPIC SE Process Description, INCOSE SE Handbook (draft), TRW’s SE Handbook, Blanchard’s Systems Engineering Management text, and other related text books. These references all point to the following high-level functions in common:

Systems Engineering supports programs and projects by performing the following activities (see Figure II-6):

· defining and managing system requirements,

· identifying and minimizing risk,

· integrating system components (physical and organizational),

· managing system complexity,

· enhancing communication and system understanding,

· conducting trade studies as a basis for informed decision making,

· and verifying that products and services meet customer needs.

The result is a cyclic and recursive model that is applied at different levels of rigor depending on the type of program or project involved. If you “unroll” the SE Process, the central “Plan and Integrate Your Work” element breaks into five distinct activities that bridge the efforts from the four main blocks. These five planning and integrating efforts are different from the four main functions in that they are typically done by systems engineering practitioners acting on the team-based input from the previous step. While many cycles of the SE process typically occur during the course of a project, each cycle covers the same basic steps only with different levels of emphasis and rigor.

Figure II-6. Plowman’s Model of the Systems Engineering Process

This process typically creates the following products: Systems Engineering Management Plan, risk mitigation, configuration management, and verification plans; mission and customer needs statements; system requirement, description, and specification documents; Technical Performance Metrics and progress towards them; Functional Flow Block Diagrams, N2 charts, functional hierarchies, system physical architecture(s); system alternatives, trade study results, and preferred solution(s); cost, schedule, and technical baselines; interface/integration control agreements and Interface Control Documents; and verification matrices/verification discrepancies.

INCOSE Handbook Systems Engineering Process Model

“What is known as the systems engineering process is basically an iterative process of technical management, acquisition and supply, system design, product realization, and technical evaluation at each level of the system, beginning at the top (the system level) and propagating those processes through a series of steps which eventually lead to a preferred system solution. At each successive level there are supporting, lower-level design iterations which are necessary to gain confidence for the decisions taken.

During each iteration, many concept alternatives are postulated, analyzed, and evaluated in trade-off studies. There are many cross-coupling factors, where decisions on one subsystem effect other subsystems. These factors must also be evaluated. An overview of the steps in the systems engineering process is shown in Figure II-7. Systems engineering is involved in all steps and leads during System Design down into the subsystem level, and integrates many other activities including design, design changes and upgrades, customer feedback, and operational support.” (INCOSE SE Handbook, p. 16)

Figure II-7. INCOSE Handbook SE Process Model

“The basic engine for systems engineering is an iterative process that expands on the common sense strategy of (1) understanding a problem before you attempt to solve it, (2) examining alternative solutions (do not jump to a point design), and (3) verify that the selected solution is correct before continuing the definition activities or proceeding to the next problem.

The basic steps in the systems engineering process are:

(1) Define the System Objectives (User’s Needs)

(2) Establish the Functionality (Functional Analysis)

(3) Establish Performance Requirements (Requirements Analysis)

(4) Evolve Design and Operations Concepts (Architecture Synthesis)

(5) Select a Baseline (Through Cost/Benefit Trades)

(6) Verify the Baseline Meets Requirements (User’s Needs)

(7) Iterate the Process Through Lower Level Trades (Decomposition)

This process is shown in Figure II-7 for the system level. The basic steps listed above are focused in the System Design process block. It is iterated at lower levels to produce hardware, software, and service implementation requirements. The process involves a Requirements Definition Process that establishes both performance (quantified) requirements and functional area (architecture) requirements, and a Solution Definition Process that translates those requirements into design and operations concepts solutions. Overarching Technical Management Processes and Technical Evaluation Processes are performed continuously throughout the development processes.

A clear understanding of the difference between defining what must be done and how well it must be done is mandatory for effective systems engineering. Unless requirements are expressed in measurable terms, it is difficult to determine when a job is done or when a product is acceptable. Also, a requirement is not effective unless it can be verified.

The systems engineering process is used iteratively at each phase of the development cycle to generate more detailed descriptions of the system under development. These descriptions constitute the “Decision Database”. The database includes what needs to be achieved (functional requirements), how well it must be achieved (performance requirements), how it is to be achieved (design and operation concepts), and analysis or test results of the latter’s capability to actually satisfy requirements (verification). The hardware engineers traditionally developed physical views of the systems, while software engineers traditionally provided functional views of their code. Systems engineers must be able to assist hardware engineers to appreciate the power of functional views, and assist software engineers to link physical descriptions to their functional processing. The keys to effective systems engineering are to effectively communicate a "shared vision" of the systems being developed and avoidance of omissions or confusion that often result from a lack of integration.” (INCOSE SE Handbook, pp. 30-31)