Systems Engineering Process
DAU GLOSSARY DEFINITION
A methodical and disciplined approach for the specification, design, development, realization, technical management, operations, and retirement of a system.
DoD systems engineering (SE) process model has revised several times. It evolved from a collection of processes that was design focused to a collection of two subsets processes, technical management processes and technical processes, as depicted in Figure 1 through Figure 4. The evolution of DoD systems engineering process model has been based on a number of industry systems engineering process standards, including
- IEEE15288.1-2014 Application of SE on Defense Programs
- ISO/IEC 26702, Application and Management of the Systems Engineering Process
- ISO/IEC/IEEE 42010, Architecture Description
- EIA 632, Processes for Engineering a System
Initial DoD SE Process Model
As illustrated by Figure 1, the fundamental systems engineering activities are requirements analysis process, functional analysis and allocation process, and design synthesis process—all balanced by techniques and tools collectively called system analysis and control. Systems engineering controls are used to track decisions and requirements, maintain technical baselines, manage interfaces, manage risks, track cost and schedule, track technical performance, verify requirements are met, and review/audit the progress.
Figure 1. Initial DoD SE Process Model
Process inputs consist primarily of the customer’s needs, objectives, requirements and project constraints. Inputs can include, but are not restricted to, missions, measures of effectiveness, environments, available technology base, output requirements from prior application of the systems engineering process, program decision requirements, and requirements based on “corporate knowledge.”
Requirements analysis process is used to develop functional and performance requirements; that is, customer requirements are translated into a set of requirements that define what the system must do and how well it must perform. The systems engineer must ensure that the requirements are understandable, unambiguous, comprehensive, complete, and concise.
Functions are analyzed by decomposing higher level functions identified through requirements analysis into lower-level functions. The performance requirements associated with the higher level are allocated to lower functions. The result is a description of the product or item in terms of what it does logically and in terms of the performance required. This description is often called the functional architecture of the product or item. Functional analysis and allocation process allows for a better understanding of what the system has to do, in what ways it can do it, and to some extent, the priorities and conflicts associated with lower-level functions. It provides information essential to optimizing physical solutions. Key tools in functional analysis and allocation are functional flow block diagrams, time line analysis, and the requirements allocation sheet.
Performance of the functional analysis and allocation results in a better understanding of the requirements and should prompt reconsideration of the requirements analysis. Each function identified should be traceable back to a requirement. This iterative process of revisiting requirements analysis as a result of functional analysis and allocation is referred to as the requirements loop.
Design synthesis is the process of defining the product or item in terms of the physical and software elements which together make up and define the item. The result is often referred to as the physical architecture. Each part must meet at least one functional requirement, and any part may support many functions. The physical architecture is the basic structure for generating the specifications and baselines.
Similar to the requirements loop described above, the design loop is the process of revisiting the functional architecture to verify that the physical design synthesized can perform the required functions at required levels of performance. The design loop permits reconsideration of how the system will perform its mission, and this helps optimize the synthesized design.
For each application of the system engineering process, the solution will be compared to the requirements. This part of the process is called the verification loop, or more commonly, Verification. Each requirement at each level of development must be verifiable. Baseline documentation developed during the systems engineering process must establish the method of verification for each requirement. Appropriate methods of verification include examination, demonstration, analysis (including modeling and simulation), and testing. Formal test and evaluation (both developmental and operational) are important contributors to the verification of systems.
Systems analysis and control include technical management activities required to measure progress, evaluate and select alternatives, and document data and decisions. These activities apply to all steps of the systems engineering process. The purpose of systems analysis and control is to ensure that:
- Solution alternative decisions are made only after evaluating the impact on system effectiveness, life cycle resources, risk, and customer requirements
- Technical decisions and specification requirements are based on systems engineering outputs
- Traceability from systems engineering process inputs to outputs is maintained
- Schedules for development and delivery are mutually supportive
- Required technical disciplines are integrated into the systems engineering effort
- Impacts of customer requirements on resulting functional and performance requirements are examined for validity, consistency, desirability, and attainability
- Product and process design requirements are directly traceable to the functional and performance requirements they were designed to fulfill, and vice versa.
Process output is dependent on the level of development. It will include the decision database, the system or configuration item architecture, and the baselines, including specifications, appropriate to the phase of development. In general, it is any data that describes or controls the product configuration or the processes necessary to develop that product.
DoD SE Process Model of 2003
DoD SE process model of 2003 are comprised of categories consisting of:
- Technical Processes
- Technical Management Processes
Figure 2. DoD SE Process Model 2003
Among the technical processes, requirements development process, logical analysis process and design solution process are collectively called design processes, as shown in Figure 2. They are used to design the products of a system, including the operational products and the supporting or enabling products required to produce, support, operate or dispose of a system. The rest of technical processes are collectively called realization processes. They are used to realize these system products. The descriptions of the technical processes are listed below:
- Requirements development process takes all inputs from users and stakeholders, clarifies them as necessary and ultimately translates these inputs into Technical Requirements.
- Logical analysis process via functional analysis, improves understanding of the defined Technical Requirements and the relationships among them (e.g., functional, behavioral, time-related) by creating and analyzing functional architectures.
- Design solution process translates the outputs of the Stakeholder Requirements Definition and Requirements Analysis processes into alternative design solutions, physical architectures and ultimately a final design solution (set of Solution-Specified Requirements).
- Implementation process determines the three means, makes buys or reuses, of realizing low-level system elements.
- Integration process incorporates lower-level system elements into higher-level subsystems and systems.
- Verification process confirms that a system element meets its design-to or build-to specifications.
- Validation process confirms that a system element meets its Stakeholder Requirements.
- Transition process moves the system element to the next stage of development, or for the end-item system, to the user.
Technical management processes are used to manage the development of system products, including supporting or enabling products. They are used in tandem with technical processes. The latter do the work of systems engineering while the former ensure that the work gets done right. The descriptions of the technical management processes are listed below:
- Technical planning process ensures the proper application of systems engineering processes.
- Requirements management process provides traceability, ultimately back to user-defined capabilities and needs.
- Interface management process ensures interface definition and compliance among the elements that compose the system as well as with other systems with which the system or system elements must interoperate.
- Risk management process examines the technical risks of deviating from the program plan.
- Configuration management process establishes and maintains consistency of a product's attributes with its requirements and product configuration information.
- Technical data management process plans for, acquires, accesses, manages, protects and uses data of a technical nature to support the total life cycle of the system.
- Technical assessment process measures technical progress and the effectiveness of plans and requirements. Key technical assessment tools include: earned value management (EVM), technical performance measurement (TPM) and Technical Reviews.
- Decision analysis process provides the basis for evaluating and selecting technical alternatives when decisions need to be made.
DoD SE Process Model of 2008
DoD SE process model of 2008 only changed the names of the design processes of the previous model, as depicted in Figure 3. Requirements development process is renamed as stakeholder requirements definition process. Logical analysis process is renamed as requirements analysis process, and design solution process is renamed as architecture design process.
Figure 3. DoD SE Process Model 2008
DoD SE Process Model of 2014
DoD SE process model of 2014 changed the illustration of the previous model, as depicted in Figure 4, which incorporate the relationship of major SE activities and SE process. It also renamed the design process set as the decomposition process set. All the processes remain the same definitions of the previous model.
Figure 4. DoD SE Process Model of 2014