4.1. Introduction

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.1. Introduction

4.1. Introduction

Systems engineering (SE) establishes the technical framework for delivering materiel capabilities to the warfighter. SE provides the foundation upon which everything else is built and supports program success.

SE ensures the effective development and delivery of capability through the implementation of a balanced approach with respect to cost, schedule, performance, and risk using integrated, disciplined, and consistent SE activities and processes regardless of when a program enters the acquisition life cycle. SE also enables the development of engineered resilient systems that are trusted, assured, and easily modified (agile).

SE planning, as documented in the Systems Engineering Plan (SEP), identifies the most effective and efficient path to deliver a capability, from identifying user needs and concepts through delivery and sustainment. SE event-driven technical reviews and audits assess program maturity and determine the status of the technical risks associated with cost, schedule, and performance goals.

"Positive acquisition outcomes require the use of a knowledge-based approach to product development that demonstrates high levels of knowledge before significant commitments are made. In essence, knowledge supplants risk over time." (Source: GAO Report 12-400SP)

Additional SE benefits are it:

• Supports development of realistic and achievable program performance, schedule, and cost goals as documented in the Joint Capabilities Integration and Development System (JCIDS) documents, Acquisition Program Baseline (APB), Technology Development Strategy (TDS), and Acquisition Strategy (AS).
• Provides the end-to-end, integrated perspective of the technical activities and processes across the system life cycle, including how the system fits into a larger system of systems (SoS) construct.
• Emphasizes the use of integrated, consistent, and repeatable processes to reduce risk while maturing and managing the system baseline. The final product baseline forms the basis for production, sustainment, future changes, and upgrades.
• Provides insight into system life-cycle resource requirements and impacts on human health and the environment.

This chapter uses the following terms:

• The "Systems Engineer" refers to the Program Lead Systems Engineer, the Chief Engineer or Lead Engineer with SE responsibility, and the SE staff responsible for SE processes and who plan, conduct, and/or manage SE activities in the program.
• The "end user" includes the warfighter and other operational users, including support personnel, maintainers, and trainers who use or support the system.
• The "developer" refers to the system prime contractor (including associated subcontractors) or the Government agency responsible for designing and building the system.

Definition of Systems Engineering

Systems engineering (SE) is a methodical and disciplined approach for the specification, design, development, realization, technical management, operations, and retirement of a system. As illustrated in Figure 4.1.F1., a system is an aggregation of system elements and enabling system elements to achieve a given purpose or provide a needed capability. The enabling system elements provide the means for delivering a capability into service, keeping it in service, or ending its service and may include those processes or products necessary for developing, producing, testing, deploying, and sustaining the system.

Figure 4.1.F1. The System

SE applies critical thinking to the acquisition of a capability. It is a holistic, integrative discipline, whereby the contributions across engineering disciplines such as structural engineers, electrical engineers, mechanical designers, software engineers, human factors engineers, and reliability engineers are evaluated and balanced to produce a coherent capability - the system.

The Systems Engineer balances the conflicting design constraints of cost, schedule, and performance while maintaining an acceptable level of risk. SE solves systems acquisition problems using a multi-disciplined approach. The Systems Engineer should possess the skills, instincts, and critical thinking ability to identify and focus efforts on the activities needed to enhance the overall system effectiveness, suitability, survivability and sustainability.

SE activities begin before a program is officially established and are applied throughout the acquisition life cycle. Any effective SE approach should support and be integrated with sound program management. Prior to program initiation, the Program Manager, or Service lead if no Program Manager has been assigned, should perform development planning to lay the technical foundation for successful acquisition. Development planning encompasses the engineering analyses and technical planning activities that provide the foundation for informed investment decisions on which path a materiel development decision takes. Development planning effectively addresses the capability gap(s), desired operational attributes, and associated dependencies of the desired capability. In addition, development planning ensures that there exists a range of technically feasible solutions generated from across the entire solution space and that consideration has been given to near-term opportunities to provide a more rapid interim response to the capability need. Development planning is initiated prior to the Materiel Development Decision review, continues throughout the Materiel Solution Analysis phase, and transitions the knowledge (documents, tools, and related data) to the designated program.

Affordability

The Systems Engineer contributes to defining, establishing, and achieving affordability targets throughout the life cycle of the system. Affordability targets are based on what the Department can afford to spend for the capability, including program acquisition and sustainment costs. Affordability targets are used as design constraints in the development, procurement, and sustainment of an affordable system. See DAG section 4.3.18.2. Affordability – Systems Engineering Trade-Off Analyses, for more information on how affordability drives design decisions.

The Program Manager controls requirements growth and should use affordability goals early to guide design trades and program decisions. The Systems Engineer assists in managing affordability by working closely with the program cost estimator/analyst team when developing common cost and technical models and aligning baselines. See DAG Chapter 3 Affordability and Life-Cycle Resource Estimates for more information on affordability.

Throughout the acquisition life cycle, the Program Manager and Systems Engineer should monitor the system affordability, seek out cost saving opportunities, and identify any associated cost, schedule, and performance risks. The Program Manager’s emphasis prior to Milestone B should be on defining and achieving affordability targets and desired capabilities. During the Technology Development (TD) phase, the Program Manager and Systems Engineer work to reduce technical risk and develop a sufficient understanding of the materiel solution development to validate design approaches and cost estimates, to refine requirements and to ensure affordability is designed in to the desired capability. After Milestone B, the emphasis shifts to defining and achieving should cost estimates.

Should cost management is a deliberate strategy to drive cost efficiencies and productivity growth into programs. The will cost estimate is the likely life-cycle cost of the system based on historical data and represents the program’s independent cost estimate, i.e., as generated by the Cost Assessment and Program Evaluation (CAPE) office or Service equivalent. As the program identifies inefficiencies, the should cost estimate is developed based on specific actions and opportunities to mitigate, eliminate, or reduce those inefficiencies that allow the program to come in below the expected will cost estimates. The Program Manager, with support from the Systems Engineer, develops program office cost estimates reflecting should cost opportunities and plans. The Program Manager uses the should cost estimate as a tool to:

• Influence design trades and choices when analyzing and setting contract/production execution targets
• Manage all costs throughout the product’s life cycle
• Manage the product’s final unit and sustainment cost
• Provide incentives for both of the parties (Government and industry) to execute efficiently: Government managers, who seek more value for the warfighter and taxpayer; and industry managers, who develop, build and sustain the systems and provide needed services

Should cost focuses on controlling the cost of both current and planned work. To have an impact, these activities should inform contract negotiations leading up to Engineering and Manufacturing Development (EMD) and Production and Deployment (P&D) phases.  Should cost management does not mean trading away the long-term value of sound design practices and disciplined SE activities for short-term gain; it does mean eliminating non-value-added activities and reports that are not required and that are deemed unessential. For guidance on implementing should cost management, see the Better Buying Power website.

Program Managers address affordability requirements and begin to apply should cost management early in the acquisition life cycle. This includes applying SE to define an affordable system design while also working to eliminate inefficiencies and duplication where applicable and to drive productivity improvements into their programs.

Systems Engineering Processes

The practice of systems engineering (SE) is composed of 16 processes: eight technical processes and eight technical management processes as listed in Figure 4.1.F2. and described in DAG section 4.3. Systems Engineering Processes. These 16 processes provide a structured approach to increasing the technical maturity of a system and increasing the likelihood that the capability being developed balances mission performance with cost, schedule, risk, and design constraints.

The eight technical management processes are implemented across the acquisition life cycle and provide insight and control to assist the Program Manager and Systems Engineer to meet performance, schedule, and cost goals. The eight technical processes closely align with the acquisition life-cycle phases and include the top-down design processes and bottom-up realization processes that support transformation of operational needs into operational capabilities.

The ultimate purpose of the SE processes is to provide a framework that allows the SE team to efficiently and effectively deliver a capability to satisfy a validated operational need. To fulfill that purpose, a program implements the SE technical processes in an integrated and overlapping manner to support the iterative maturation of the system solution. The level of SE required supporting these processes declines as a program progresses into the later phases of the acquisition life cycle. Implementation of the SE processes begins with the identification of a validated operational need as shown in the top left corner of the V-diagram (see Figure 4.1.F2). The technical processes enable the SE team to ensure that the delivered capability accurately reflects the operational needs of the stakeholders. The key activities that are accomplished by the execution of the technical processes are described below:

• During the Stakeholder Requirements Definition process, the operational requirements and inputs from relevant stakeholders are translated into a set of top level technical requirements. These requirements are decomposed and elaborated during the Requirements Analysis process to produce a complete set of system functional and performance requirements. (Note: Figure 4.1.F2 is provided as a framework to illustrate where requirements are addressed within the SE Process flow. See DAG section 4.3.11. Requirements Analysis Process for more information on operational and system requirements.)
• During the Architecture Design process, the Systems Engineer, often through system modeling, trade-offs, and decision analyses, captures the functional requirements and interdependencies in the system architecture. Trade-offs and analyses are also used to mature and realize the design of the system and system elements during the Implementation process, generating the product baseline.
• During the Integration process, the program assembles the system elements together to provide the system for testing in the Verification process (developmental tests verifying the functional requirements) and Validation process (operational tests validating the system meets the operational need), resulting in a validated solution.
• During the Transition process, the program formally delivers the system capability to the end users, including all enabling system elements to support operational use and sustainment activities.

The technical management processes, listed at the bottom of Figure 4.1.F2, provide a consistent approach to managing the program’s technical activities and controlling information and events that are critical to the success of the program. Taken together, these 16 processes are a systematic approach focused on providing operational capability to the warfighter while reducing technical and programmatic risk.

Figure 4.1.F2. Systems Engineering Processes

All organizations performing SE should scale their application and use of the processes in DAG section 4.3. Systems Engineering Processes to reflect the unique needs of the program and the type of product or system being developed. This scaling should reflect the system’s maturity and complexity, size and scope, life-cycle phase, and other relevant considerations. For example, lower-risk, less-complex programs may scale the processes to ensure key activities are effective but not overly cumbersome (e.g., simpler and less-expensive tools, less-frequent reporting, and activities adjusted to fit smaller organizations with fewer personnel).

Top of page