Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.
DAG Chapter 4 Update
May 2013 | Page-1

•
– Define systems engineering activities to support the updated Joint
Capabilities Integration and Development System (JCIDS) (Chairman of the
Joint Chiefs of Staff Instruction (CJCSI) 3170.01H)
– Reflect Better Buying Power initiatives
– Respond to systems engineering systemic root cause analyses recommendations from program assessments
– Incorporate Department-wide best practices; avoiding Service and domainspecific implementations
•
•
•
DAG Chapter 4 Update
May 2013 | Page-2
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

•
•
– Policy (Direction / Requirement) → Process (How) → Product (What)
•
•
•
•
– 24 organizations (DoD Services/Agencies)
– 149 participants contributed as authors, collaborators, reviewers, and independent subject matter experts (includes ODASD(SE))
DAG Chapter 4 Update
May 2013 | Page-3
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

– Systems Engineering Definition
–
Why it’s important
– Description of Technical Maturity Points
–
By-phase description of key technical activities
– Technical Reviews and Audits
– Description of technical and technical management processes
–
Design Considerations (include Specialty Engineering)
DAG Chapter 4 Update
May 2013 | Page-4
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

4.0 Overview
4.0.1 Purpose
4.0.2 Contents
4.1 Introduction
4.1.1 Systems Engineering Policy and Guidance
4.1.2 Systems Engineering Plan
4.1.3 Systems Level Considerations
4.1.4 Engineering Resources
4.1.5 Certifications
4.1.6 Systems Engineering Role in Contracting
4.2 Systems Engineering Activities in the Life Cycle
4.2.1 Life Cycle Expectations
4.2.2 – 4.2.7 Acquisition Phases
4.2.8 – 4.2.17 Technical Reviews and Audits
4.3 Systems Engineering Processes
4.3.1 Systems Engineering Processes Overview
4.3.2 – 4.3.9 Technical Management Processes
4.3.10 – 4.3.17 Technical Processes
4.3.18 Design Considerations (includes 24 subsections, one for each design consideration)
4.3.19 Tools, Techniques, and Lessons Learned
DAG Chapter 4 Update
May 2013 | Page-5
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

•
Focused on target audience being Program Manager and Systems
Engineering practitioners
•
Consolidated and strengthened Systems Engineering Plan (SEP) Outline content in 4.1.2
• Added new content:
– 4.1.3 Systems Level Considerations (includes Software)
– 4.1.5 Certifications
– 4.1.6 Systems Engineering Role in Contracting
– 4.3.19 Sustainability Analysis
•
Added detailed SE technical reviews and audits information (4.2.8-4.2.17)
• Enhanced Design Considerations section 4.3.18:
– Streamlined Parts Management and Standardization
– Added new subsections: Anti-Counterfeiting; Intelligence; Operational Energy; and Packaging,
Handling, Storage, and Transportation (PHS&T)
– Added guidance for Producibility (under Producibility, Quality, and Manufacturing Readiness)
• Removed/reduced topics covered in other DAG chapters
– Earned Value Management and Integrated Baseline Reviews (IBR) content removed, both found in
Chapter 11 Program Management
– Test and Evaluation content reduced, found in Chapter 9 Test & Evaluation
• Removed phase-specific systems engineering ‘V’s
DAG Chapter 4 Update
May 2013 | Page-6
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

Content
Major Sections
SEP Outline
Technical
Reviews and
Audits
Design
Considerations
Added content
Non-SE content •
•
DAG Chapter 4 (October 2012)
7 (4.0 to 4.6)
Note: 4.0 included SE definition and SE Policy and
Guidance
• Content split between two locations:
• 4.1 SE Overview
• 4.5 SE Execution: Key SE Tools and Techniques
• Missing guidance on mandatory table for
Certifications
• Embedded in phases throughout 4.3
• Summary in 4.5.9
22 in section 4.4
Earned Value Management (EVM)
Integrated Baseline Reviews (IBR) (one per each acquisition life cycle phase)
• Test and Evaluation (T&E) content
DAG Chapter 4 (February 2013)
4 (4.0 to 4.3)
• Expanded 4.1 Intro to include SE definition and SE Policy and
Guidance
• Removed 2 sections related to tools (embedded content into
4.1 Intro and 4.3 SE Processes)
• Moved 1 section on Design Considerations (embedded into 4.3 SE
Processes)
• Consolidated into one section, 4.1.2 Systems Engineering Plan
• Strengthened content supporting SEP Outline (e.g., Technical
Performance Measures, Design Considerations)
• Added new section 4.1.5 Certifications
• Detailed information on SE Technical Reviews and Audits, 4.2.8-17
• Separated out from phases, focused on technical maturity and risk
• Changed ASR based on CJCSI 3170.01H demand signal
• Removed ITR, IBRs, TRR
24 in section 4.3.18
• Combined Parts Management and Standardization
• Moved Software to 4.1.3 Systems Level Considerations
• 4 New: Anti-Counterfeiting, Intelligence, Operational Energy, PHS&T
• Added guidance for Producibility (under PQM)
• Added 4.1.3 Systems Level Considerations
• Added 4.1.6 SE Role in Contracting
• Added 4.3.19. Sustainability Analysis
• Removed EVM, covered in DAG Chapter 11 PM Activities
• Removed IBRs, covered in DAG Chapter 11 PM Activities
• T&E content reduced, linked to DAG Chapter 9 Test & Evaluation
DAG Chapter 4 Update
May 2013 | Page-7
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

Metric
Page Count
Links
Sections
Diagrams
Design Considerations
SE Processes
DAG Chapter 4
(October 2012)
197
825
(478 external,
347 internal to DAG Chapter 4)
7
(4.0 – 4.6)
14
(includes 5 different ‘V’ diagrams)
22
16
DAG Chapter 4
(February 2013)
250
(minus table of contents)
359
(external only)
4
(4.0 – 4.3)
34
(includes life cycle diagram depicted 17 times; removed phase specific ‘V’ diagrams )
24
16
(Implementation Process includes design and realization)
DAG Chapter 4 Update
May 2013 | Page-8
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

DAG Chapter 4 Update
May 2013 | Page-9
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

DAG Chapter 4 Update
May 2013 | Page-10
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

4.0
Overview
4.0.1 Contents
4.0.2 Definition of Systems Engineering
4.0.3 DoD Policy and Guidance on Systems Engineering
4.1
Systems Engineering Overview
4.1.1 Systems Engineering in DoD Acquisition
4.1.2 Participants in Systems Engineering
4.1.3 Systems Engineering Throughout Life-cycle Management
4.1.4 System of Systems (SoS) Engineering
4.1.5 Systems Engineering Within the Integrated Product and Process Development (IPPD) Framework
4.1.6 Systems Engineering Leadership
4.2
Systems Engineering Processes: How systems Engineering is Conducted
4.2.1 Process Standards and Capability Models to Accomplish Systems Engineering
4.2.2 The Contractor’s Systems Engineering Processes
4.2.3 Standardization Process Terminology
4.2.4 Application of Systems Engineering Processes
4.3
Systems Engineering Activities in the System Life Cycle
4.3.1 – 4.3.5 Acquisition Phases
4.3.6 Evolutionary Acquisition Programs
4.4
Systems Engineering Design Considerations
4.4.1 – 4.4.22 (22 subsections on design considerations)
4.5
Systems Engineering Execution: Key Systems Engineering Tools and Techniques
4.5.1 Systems Engineering Plan (SEP)
4.5.2 Integrated Master Plan (IMP)
4.5.3 Integrated Master Schedule (IMS)
4.5.4 Earned Value Management (EVM) and Work Breakdown Structure (WBS)
4.5.5 Value Engineering (VE)
4.5.6 Types of Technical Assessments
4.5.7 Trade Studies
4.5.8 Modeling and Simulations (M&S)
4.5.9 Summary of Technical Reviews
4.6
Systems Engineering Resources and Tools
4.6.1 Best Practices
4.6.2 Case Studies
4.6.3 Lessons Learned
4.6.4 Standards and Models
4.6.5 Handbooks and Guides
DAG Chapter 4 Update
May 2013 | Page-11
Distribution Statement A – Approved for public release by OSR, SR Case #s 13-S-1371 and 13-S-1836 apply. Distribution is unlimited.

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering
4.3.8. Technical Data Management Process
4.3.8. Technical Data Management Process
Through the Technical Data Management process, the program identifies, acquires, manages, maintains, and ensures access to the technical data and computer software required to manage and support a system throughout the acquisition life cycle. Key
Technical Data Management considerations include understanding and protecting
Government intellectual property and data rights, achieving competition goals, maximizing options for product support, and enabling performance of downstream lifecycle functions. DoDI 5000.02
contains Technical Data Management requirements for
Acquisition Category (ACAT) I and II programs.
Effective acquisition, upgrades, and management of product data provide:



Information necessary to understand and evaluate system designs throughout the life cycle
Ability to operate and sustain weapon systems under a variety of changing technical, operational, and programmatic environments
Ability to re-compete item acquisition, upgrades, and sustainment activities in the interest of achieving cost savings; the lack of product data and/or data rights often makes it difficult or impossible to award contracts to anyone other than the original manufacturer, thereby taking away much or all of the Government’s ability to reduce total ownership costs (TOC)
Activities and Products
The Program Manager and Systems Engineer, in conjunction with the Product Support
Manager, should ensure that life-cycle requirements for weapon system-related data products and data rights are identified early and that appropriate contract provisions are put in place to enable deliveries of these products. Figure 4.3.8.F1 shows the activities associated with Technical Data Management, including:
- Identify Data Requirements


Formulate the program’s Technical Data Rights Strategy (TDRS) and technical data management approach, with emphasis on technical and product data needed to support the product throughout its life cycle. (see DAG Chapter 2 Program
Strategies for more information about Data Rights).
Ensure that data requirements are documented in the TDRS; summarized in the
Technology Development Strategy (TDS) , Acquisition Strategy (AS) , and Life-
Cycle Sustainment Plan (LCSP) ; and submitted at each milestone prior to award of the contract for the next life-cycle phase.

 Consider not only the immediate, short-term costs of acquiring the needed technical data and data rights but also the long-term cost savings resulting from the ability to compete production and logistics support activities and reduce TOC.
Understand that the Government can possess either Government Purpose or
Unlimited Rights to use many types of technical data and data rights, at no additional cost, based on the type of technical data and the source of funding used to generate the data (see DoD Open Systems Architecture Contract Guidebook for
Program Managers for more information about data rights).
- Acquire Data


Use explicit contract Statement of Work tasks to require the developer to perform the work that generates the required data. The content, format, and quality requirements should be specified in the contract.
Use current, approved Data Item Descriptions (DID) and Contract Data
Requirements Lists (CDRL) in each contract to order the delivery of the required technical data and computer software.
- Receive, Verify, and Accept Data


Ensure verification of content, format, and quality of all required product-related data received from originators.
Inspect contractually ordered data deliverables to ensure markings are in accordance with the relevant data rights agreements and DFARS clauses, and contain appropriate distribution statements and/or export control statements.
Caution: Acceptance of delivered data not marked consistent with the contract can result in the Government “losing” legitimate rights to technical data and can incur significant legal liability on the Government and the individual Government employees. Regaining those rights generally requires costly and time-consuming legal actions.
- Store, Maintain, and Control Data




Budget for and fund the maintenance and upkeep of product data throughout the life cycle.
An Integrated Data Environment (IDE) or Product Life-cycle Management (PLM) system allows every activity involved with the program to create, store, access, manipulate, and exchange digital data.
To the greatest extent practical, programs should use existing IDE/PLM infrastructure such as repositories operated by Commodity Commands and other organizations. (Program-unique IDEs are discouraged because the high infrastructure cost; further, multiple IDEs inhibit access, sharing, and reuse of data across programs.)
Ensure all changes to the data are made in a timely manner and are documented in the program IDE or PLM system.

- Use and Exchange Data
Plan for and establish methods for access and reuse of product data by all personnel and organizations that perform life-cycle support activities.
Figure 4.3.8.F1. Data Management Activities
In support of the Government’s requirement for a Technical Data Package (TDP), the
Program Manager should also consider all product related data (e.g., technical manuals, repair instructions, and design/analysis data) to:



Allow logistics support activities
Better enable sustainment engineering
Apply, implement and manage product upgrades
Contractually deliverable data should be identified and ordered at the specific “data product” level, e.g., two-dimensional drawings, three-dimensional Computer-Aided
Design (CAD) models, technical manuals, etc. Figure 4.3.8.F2 provides a notional representation of different types of product-related data.
Caution: Program Managers and Systems Engineers should be aware that terms such as
“technical data,” “product data,” and “TDP” are imprecise, not equivalent, and often incorrectly used interchangeably.
Resources for establishing and conducting Technical Data Management activities include but are not limited to:
 DoD 5010.12-M, Procedures for the Acquisition and Management of Technical
Data








Army Data Management Strategy (DMS) Guide and Addendum
Air Force Product Data Acquisition (PDAQ) guidance
Air Force Technical Data and Computer Software Rights Handbook
Navy Technical Manual SL150-AA-PRO-010/DMP – Data Management Program
MIL-HDBK-245, Handbook for the Preparation of Statement of Work
MIL-STD-963, Data Item Descriptions
MIL-STD-31000, Technical Data Packages
Figure 4.3.8.F2. Data Taxonomy
- Data Protection
The Program Manager is responsible for protecting system data, whether the data is stored and managed by the Government or by contractors. The DoD policy with regard to data protection, marking, and release can be found in:




DoDD 5230.25
DoDI 5230.24
DoD 5400.7-R
DoD 5200.1-M

Data containing information subject to restrictions are protected in accordance with the appropriate guidance, contract, or agreement. Guidance on distribution statements, restrictive markings, and restrictions on use, release, or disclosure, of data can be found in the DFARS Part 252.227-7013 and 7014 , and DoDI 5230.24.
When digital data is used, the data should display applicable restriction markings, legends, and distribution statements clearly visible when the data is first opened or accessed. These safeguards not only ensure Government compliance regarding the use of data but also guarantee and safeguard contractor data delivered to the Government, and extend responsibilities of data handling and use to parties who subsequently use the data.
Section 208 of Public Law 107-347 and DoD Privacy Impact Assessment (PIA) guidance requires that PIA be conducted prior to developing or purchasing any DoD information system that collect, maintain, use, or disseminate personally identifiable information about members of the public, federal personnel, DoD contractors and, in some cases, foreign nationals. Available PIA guidance provides procedures for completing and approving PIAs. For further information, see DAG Chapter 7 Acquiring Information
Technology, Including National Security Systems .
All data deliverables should include distribution statements. Processes should be established to protect all data that contain critical technology information, as well as ensure that limited distribution data, intellectual property data, or proprietary data is properly handled throughout the life cycle, whether the data are in hard-copy or digital format.

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering
4.3.7. Configuration Management Process
4.3.7. Configuration Management Process
The Configuration Management process allows technical insight into all levels of the system design and is the principal methodology for establishing and maintaining consistency of a system’s functional, performance, and physical attributes with its requirements, design, and operational information throughout the system's life cycle. Effective configuration management supports the establishment and maintenance of the product baseline, which enables the successful production, delivery, and sustainment of the needed capability to the end user.
Configuration Management activities support:









Traceability of designs to requirements
Proper identification and documentation of system elements, interfaces, and interdependencies
Timely and thorough vetting and disposition
Control and documentation of approved changes to baselines
Proper and timely incorporation of verified changes in all affected items and documentation
Consistent and appropriate provisions in the Engineering Change Proposal (ECP) and related contract actions
Consistency between the product and its supporting documentation
A complete audit trail of design decisions and modifications
Continued assurance of system supportability and interoperability, consistent with approved acquisition and life-cycle sustainment strategies
Configuration Management facilitates the orderly development of a system through establishment of the technical baseline (including the functional, allocated, and product baselines), and their assessment and approval at various technical reviews and audits. A baseline is an agreed upon description of the attributes of a product at a point in time, which serves as a basis for change.
Upon approval, the baseline is placed under formal configuration control.
Through Configuration Management, the program identifies, controls, and tracks changes to system baselines, ensuring changes occur only after thorough assessments of performance, cost, and schedule impacts and associated risks.
The following baselines are critical to executing Configuration Management:
 Functional Baseline: Describes the system’s performance (functional, interoperability, and interface characteristics) and the verification required to


 demonstrate the achievement of those specified characteristics. It is directly traceable to the operational requirements contained in the Initial Capabilities
Document (ICD). The Program Manager establishes Government control of the functional baseline at the System Functional Review (SFR) and verifies it through
Functional Configuration Audits (FCA) leading up to the system-level FCA or the
System Verification Review (SVR). Attributes of the functional baseline include: o
Assessed to be achievable within cost and schedule constraints o o
Documentation of established interfaces between functional segments
Documented performance requirements traced to (draft) CDD o requirements
Reflects design considerations and clear linkage in the systems of systems
(SoS) context o
Documented verification requirements
Allocated Baseline: Describes the functional and interface characteristics for all system elements (allocated and derived from the higher-level product structure hierarchy) and the verification required to demonstrate achievement of those specified characteristics. The allocated baseline for each lower-level system element (hardware and software) is usually established and put under configuration control at the system element Preliminary Design Review (PDR).
This process is repeated for each system element and culminates in the complete allocated baseline at the system-level PDR. The Program Manager then verifies the allocated baseline at the FCA and/or SVR. Attributes of the allocated baseline include: o
All system-level functional performance requirements decomposed (or directly allocated) to lower-level specifications (configuration items (CI) o o o for system elements)
Uniquely identified CIs for all system elements at the lowest level of the specification tree
All interfaces, both internal (between element CIs) and external (between the system under development and other systems), documented in interface control documents
Verification requirements to demonstrate achievement of all specified o functional performance characteristics (element CI to element CI level and at the system level) documented
Design constraints documented and incorporated into the design
Product Baseline: Describes the detailed design for production, fielding/deployment, and operations and support. The product baseline prescribes all necessary physical (form, fit, and function) characteristics and selected functional characteristics designated for production acceptance testing and production test requirements. It is traceable to the system performance requirements contained in the Capability Development Document (CDD). The initial product baseline includes "build-to" specifications for hardware (product, process, material specifications, engineering drawings, and other related data) and software (software module design — "code-to" specifications). The initial system element product baseline is established and placed under configuration control at the system element Critical Design Review (CDR) and verified later at the

Physical Configuration Audit. In accordance with DoDI 5000.02
, the Program
Manager assumes control of the initial product baseline for all Class I configuration changes at the completion of the system-level CDR to the extent that the competitive environment permits. This does not necessarily mean that the
Program Manager takes delivery and acceptance of the Technical Data Package.
Attributes of the product baseline include: o
Requirements Traceability Matrix (RTM) is complete o
The detailed design (hardware and software), including interface descriptions, satisfies the CDD or any available draft Capability o o o o
Production Document (CPD), and pertinent design considerations
Hardware, software and interface documentation are complete
Key product characteristics having the most impact on system performance, assembly, cost, reliability, ESOH, and sustainment have been identified
Traceability from design documentation to system and system element verification requirements and methods is complete
Manufacturing processes that affect the key characteristics have been identified, and capability to meet design tolerances has been determined
Activities and Products
The program office and developer share responsibility for planning, implementing, and overseeing the Configuration Management process and its supporting activities. The distribution of responsibilities between the program office and the developer varies based on the acquisition strategy and the lifecycle phase.
The Program Manager approves the Configuration Management Plan and should ensure adequate resources are allocated for implementing Configuration
Management throughout the life cycle. The Program Manager approves the system baselines, and approves Class I changes to the product baseline after
CDR, usually through a Configuration Control Board (CCB). MIL-HDBK-61A,
“Configuration Management Guidance” defines Class I and II changes:


Class I changes impact the form, fit, function, or interface characteristics of the configuration item
Class II changes are changes to a Government approved technical baseline that do not meet the definition of a Class I change
In performance-based acquisition, these terms apply only to changes that affect
Government-approved (baselined) configuration documentation.
The Systems Engineer ensures Configuration Management planning is complete, and should document details and activities in the program’s Systems Engineering
Plan (SEP) and the supporting Configuration Management Plan (CMP) (as appropriate). The CM process described in the DoD-adopted standard,

ANSI/EIA-649-B-2011 “Configuration Management Standard,” consists of five interrelated functions that, when collectively applied, allow the program to maintain consistency between product configuration information and the product throughout its life cycle. The five CM functions are:





Configuration Management Planning and Management
Configuration Identification
Configuration Change Management
Configuration Status Accounting
Configuration Verification and Audit