Dau Se Guidebook

DoD Systems Engineering Guidebook (OUSD R&E, February 2022)

Source: US Department of Defense (OUSD R&E) — US Government work, public domain; Distribution A | Chapters: 6

When to use

Use this skill when you need to apply, explain, or assess the DoD's systems engineering approach for defense acquisition programs: the 16 SE processes and how they map to ISO/IEC/IEEE 15288, the event-driven technical review and audit sequence, the Systems Engineering Plan (SEP), risk/issue/opportunity management, technical performance measurement, system-of-systems and digital-engineering practice, or any of the 24 design considerations (RAM, system safety, HSI, system security engineering, MOSA, etc.). This is the OUSD(R&E) companion to DoDI 5000.88 (Engineering of Defense Systems); it is guidance, not policy — programs scale and tailor it.

Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.

How to Use This Skill

• Without arguments — load the core frameworks below for an overview of the SE process model, the review/audit sequence, and the SEP.
• With a topic — ask about a specific process (e.g., "architecture design process", "configuration management"), a review/audit (e.g., "PDR entrance criteria", "SVR/FCA"), the SEP, TPMs/leading indicators, or a design consideration (e.g., "human systems integration", "system security engineering").
• With a chapter — ask for ch04 (8 technical management processes), ch05 (8 technical processes), ch03 (reviews & audits), ch06 (design considerations).

Supporting files: glossary.md, patterns.md, cheatsheet.md.

Core Frameworks & Mental Models

The DoD SE Process Model — 16 Processes (8 + 8)

The practice of SE is composed of 16 processes: eight technical management processes and eight technical processes. They map to the ISO/IEC/IEEE 15288 SE processes and are applied in an integrated, overlapping, iterative manner along the V-diagram. Programs scale the processes to the system's maturity, complexity, size/scope, acquisition pathway, and life-cycle phase.

Eight Technical Processes (top-down design, then bottom-up realization — the V):

1. Stakeholder Requirements Definition — translate operational requirements from stakeholders into top-level technical requirements.
2. Requirements Analysis — decompose into a complete set of system functional and performance requirements.
3. Architecture Design — capture functional requirements and interdependencies in the system architecture (often via system modeling, trade-offs, decision analyses).
4. Implementation — mature and realize the design of the system and system elements; generate the product baseline.
5. Integration — assemble system elements into the system for test.
6. Verification — developmental test: did we build the system right (conformance to requirements)?
7. Validation — operational test: did we build the right system (meets the operational need)?
8. Transition — formally deliver the capability and enabling system elements to the end users for operation and sustainment.

Eight Technical Management Processes (run across the whole life cycle, providing insight and control):

1. Technical Planning — plan, organize, and resource the technical effort; outputs feed the SEP, IMP, IMS, WBS.
2. Decision Analysis — apply formal criteria, alternatives, and analysis to significant technical decisions.
3. Technical Assessment — measure technical progress against plans; conduct technical reviews; track TPMs and leading indicators.
4. Requirements Management — maintain bidirectional traceability and control requirement changes.
5. Risk Management — manage risks, issues, and opportunities (RIO) with reporting matrices.
6. Configuration Management — establish and control configuration baselines and changes.
7. Technical Data Management — capture and manage technical data, trade studies, and analyses.
8. Interface Management — define and control internal and external interfaces.

Not the NASA 17-process model. This is the DoD's 8 + 8 model (16 processes) tied to the Major Capability Acquisition life cycle and ISO/IEC/IEEE 15288 — distinct from NASA NPR 7123's SE Engine (17 processes). The review names differ too (DoD has ASR, SVR/FCA, PRR, PCA).

Technical Reviews & Audits (event-driven)

Reviews are event-driven (triggered by meeting entrance criteria documented in the SEP, not by calendar). Each provides a knowledge-based control point that reduces risk over time. The Major Capability Acquisition sequence:

A review is well-run when entrance criteria are met first, the right products are at the right maturity, action items (RFAs) are dispositioned, and the result informs the next milestone decision.

The Systems Engineering Plan (SEP)

The SEP is the master technical plan: it documents the program's SE approach, technical risks, processes, resources, metrics, SE products, organization, design considerations, and the timing/entrance criteria of technical reviews. Key rules:

• Required for MDAPs and ACAT II/III programs (per DoDI 5000.88) unless waived; recommended best practice for all other development.
• A living document — updated as the approach evolves and (best practice) reapproved before each technical review.
• Prepared by the Lead Systems Engineer under the PM; approval authority depends on ACAT level (USD(R&E) for ACAT ID).
• Must be consistent with the APB, TEMP, PPP, LCSP, IMP/IMS, WBS, and Risk Management Plan — no redundancy, plain language.

Risk, Issue, and Opportunity (RIO) Management

The Risk Management process manages three related things, each with its own reporting matrix:

• Risk — a future event with negative consequence; scored on a likelihood × consequence 5×5 matrix; managed by mitigation (accept / avoid / transfer / control).
• Issue — a risk that has been realized (or a present problem); scored on a consequence-based issue matrix; managed by corrective action (a "burn-down").
• Opportunity — a potential future benefit (cost/schedule/performance); managed by pursue / reject decisions.

Technical Performance Measurement

• TPMs — quantitative measures tracked against a planned profile to assess whether the design will meet requirements; organized in a TPM hierarchy.
• Leading indicators — forward-looking measures (trends) that signal whether risk-mitigation is on track before a threshold is breached; drive early corrective action.
• TPMs roll up to MOPs/MOEs and feed the Technical Assessment process and reviews.

System-Level Considerations

• System of Systems (SoS) — four types (virtual, collaborative, acknowledged, directed); SE differs from single-system SE in authority, funding, and interface control.
• Digital Engineering (DE) — an authoritative source of truth and models used across the life cycle; changes how reviews/analyses are done, not what must be done.
• MOSA — Modular Open Systems Approach; required "to the maximum extent practicable" for evolvability and competition.
• Mission engineering, software engineering, value engineering, sustainability analysis — enterprise techniques feeding SE.

Design Considerations (24)

Section 5 carries 24 cross-cutting design considerations the SE process must balance — among them Reliability & Maintainability (R&M) engineering, System Safety (incl. software system safety, ESOH, hazard tracking), Human Systems Integration (HSI), System Security Engineering, Manufacturing & Quality (incl. manufacturing readiness), Supportability, Survivability, Interoperability, Modular Design, Standardization, Spectrum Management, Corrosion Prevention, DMSMS, Operational Energy, Affordability trade-offs, Section 508 accessibility, Anti-counterfeiting, Critical Safety Items, and Demilitarization & Disposal.

Chapter Index

Topic Index

• 16-process SE model / ISO 15288 mapping / V-diagram / process scaling → ch01, ch04, ch05
• Systems Engineering Plan (SEP) → ch01, ch04, cheatsheet
• Roles (PM, Systems Engineer, Lead Software Engineer) / IPTs → ch01, ch02
• System of Systems (SoS) / Digital Engineering / mission engineering → ch02
• MOSA / modular design → ch02, ch06
• Contracting / RFP technical content → ch02
• Technical reviews & audits (ASR, SRR, SFR, PDR, CDR, SVR/FCA, PRR, PCA) → ch03, cheatsheet
• Baselines (functional / allocated / product) → ch03, ch05
• Technical management processes (Technical Planning, Decision Analysis, Technical Assessment, Requirements/Configuration/Technical Data/Interface Management) → ch04
• Risk / Issue / Opportunity (RIO) management → ch04, cheatsheet
• TPMs / leading indicators → ch04, cheatsheet
• Technical processes (Stakeholder Requirements, Requirements Analysis, Architecture Design, Implementation, Integration) → ch05
• Verification vs. Validation / Transition → ch05, cheatsheet
• Design considerations — the 24 (R&M, System Safety/ESOH, HSI, System Security Engineering, Manufacturing & Quality/MRLs, supportability, survivability, DMSMS, …) → ch06, cheatsheet

Supporting Files

• glossary.md — key DoD SE terms (processes, reviews, baselines, RIO, TPM, SoS, design considerations), alphabetical, with chapter references
• patterns.md — reusable SE patterns (process scaling, event-driven review gating, SEP maintenance, risk vs. issue triage, MOSA adoption, design-consideration balancing) with When/How/Trade-offs structure
• cheatsheet.md — decision rules, the 16-process table, review/audit sequence, RIO matrices, TPM vs. leading indicator, design-considerations list, tells & smells

Scope & Limits

Covers: the DoD SE approach for defense acquisition programs per the OUSD(R&E) Systems Engineering Guidebook (February 2022) — the 16 SE processes (8 technical management + 8 technical) and their ISO/IEC/IEEE 15288 mapping; the event-driven technical review and audit sequence (ASR, SRR, SFR, PDR, CDR, SVR/FCA, PRR, PCA) with products and entrance/success criteria; the Systems Engineering Plan (SEP); risk/issue/opportunity management; technical performance measurement (TPMs, leading indicators); system-of-systems and digital-engineering practice; engineering resources, roles, IPTs, and the SE role in contracting; and the 24 design considerations.

Does not cover in depth: detailed cost estimating and JCL analysis (see a cost-estimating source); contracting law and the FAR/DFARS; the Adaptive Acquisition Framework pathways themselves (see the Engineering of Defense Systems Guidebook and DoDI 5000.02); test & evaluation planning detail (see the DoD T&E guidance / TEMP); program protection and cybersecurity RMF detail (see the Program Protection Plan and NIST/RMF sources); software development methodology detail; and non-DoD, commercial, or civil-agency life cycles. This is guidance, not policy — the binding requirements live in DoDI 5000.88 and related issuances.

Jurisdiction: US Government public domain work (Distribution Statement A). Applies to DoD acquisition programs; non-DoD organisations may adopt the framework voluntarily.