U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

  1. Home
  2. Communities of Practice
  3. Systems Engineering
CommentCommunity

Systems Engineering

This Community serves as a collaborative space to provide resources for systems engineering (SE) practitioners. These resources support program planning and design activities as well as implementation of SE processes. In addition this Community offers a variety of ways for the SE to network with other SE practitioners, to access current community contributions and discussions on SE tips and best practices, and to share expert knowledge related to SE.

Members

Views

Pinned Content

COMMUNITY / Systems Engineering
Systems Engineering Planning
COMMUNITY / Systems Engineering
Systems Engineering Process
COMMUNITY / Systems Engineering
Design Considerations

Community Contacts

COMMUNITY / Systems Engineering
Mitchell Woods - Community Leader
COMMUNITY / Systems Engineering
Walt Tomczykowski - Community Leader
COMMUNITY / Systems Engineering
Monique Ofori - Community Leader
COMMUNITY / Systems Engineering
Patrick Dallosta - Community Leader
COMMUNITY / Systems Engineering
John Snoderly - Community Leader

Feed / Systems Engineering

Resource / Systems Engineering
SE Processes
View Resource

Systems Engineering Processes

The SE processes are used by contractor and Government organizations to provide a framework and methodology to plan, manage and implement technical activities throughout the acquisition life cycle. SE planning and execution should focus on applying the processes and tools in a rigorous, integrated, and disciplined manner to achieve a system solution that balances performance, cost, schedule, and risk. 

The eight technical management processes, applicable to all acquisition pathways, provide a consistent framework for managing technical activities and identifying the technical information and events critical to the success of the program. Technical information includes controlled unclassified information (CUI) as well as classified and unclassified Critical Technical Information (CTI) about DoD sponsored research, technology, programs, and systems being acquired. The eight technical processes ensure the system design and the delivered capability reflect the requirements that the stakeholders have expressed. The 16 SE processes are applicable to all the AAF pathways to some degree. The PM and SE will determine which processes to use for their program. 

Whereas the technical management processes provide insight of, and control over, the technical development of a system throughout its life cycle, the technical processes are used to design, develop and analyze the system, system elements and enabling system elements required for integration, test, production, deployment, support, operation and disposal. The eight technical processes provide a framework for ensuring and maintaining traceability between stakeholder requirements, systems design and the eventual delivered capability.

For more information refer to Section 4 of the Systems Engineering Guidebook.

Technical Management Processes ​Technical Processes
​Technical Planning ​Stakeholder Requirements Definition
​Decision Analysis ​Requirements Analysis
​Technical Assessment ​Architecture Design
​Requirements Management ​Implementation
​Risk Management ​Integration
​Configuration Management ​Verification
​Technical Data Management ​Validation
​Interface Management ​Transition

CREATED:
September 1, 2023
BY:
LAST MODIFIED:
November 21, 2023
BY:
DOCUMENT ID:
CONTRIBUTION TYPE:
CONTENT TYPE:
Resource / Systems Engineering
SE Planning
View Resource

Systems Engineering Planning

Systems Engineering planning, as documented in the Systems Engineering Plan (SEP), formulates the approach to conduct, manage and control all the technical activities to deliver a desired capability. SE Planning begins with the identification and decomposition of user needs and concepts, and progresses through development, delivery and sustainment of the final product. The Systems Engineering Guidebook provides overarching guidance on the systems engineering discipline, its activities and processes, and its practice in defense acquisition programs. This topical area contains information on SE Planning for DoD acquisitions. 

CREATED:
September 1, 2023
BY:
LAST MODIFIED:
September 18, 2023
BY:
DOCUMENT ID:
CONTRIBUTION TYPE:
CONTENT TYPE:
Resource / Systems Engineering
Process
View Resource


Systems Engineering Process

This section is also a placeholder for text describing why a user would come to this site. What is it about? Explain here with a brief summary of SE Processes, this page and what is below.....


​Decision Analysis

Technical Planning

Technical Assessment

Requirements Management

Risk Management

Configuration Management

Technical Data Management

Interface Management


"These icons are placeholders for whatever images and lists you want to link to"

​ ​
Multi Media 
 Share an Idea/ Discussion
 Document Library

Decision Analysis 

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Technical Planning

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Technical Assessment

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Requirements Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.   

Risk Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Configuration Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Technical Data Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulat
CREATED:
September 1, 2023
BY:
LAST MODIFIED:
September 18, 2023
BY:
DOCUMENT ID:
CONTRIBUTION TYPE:
CONTENT TYPE:
Resource / Systems Engineering
Design Considerations
View Resource

Design Considerations

The PM, Systems Engineer, and Lead Software Engineer should address and document design considerations, including all statutory and regulatory requirements in order to:

  • Translate the end-user desired capabilities into a structured system of interrelated design specifications that support delivery of required operational capability.
  • Enable trade-offs among the design considerations in support of achieving desired mission effectiveness within cost and schedule constraints.
  • Incorporate design considerations into the set of system requirements, as some are mandated by laws, regulations, or treaties, while others are mandated by the domain or DoD Component or Agency; these mandates should be incorporated during the Requirements Analysis process to achieve balance across all system requirements.

The DoD has put additional emphasis on the four Specialty Engineering design considerations as well as Value Engineering identified in the tiles below resulting in development of additional policy (DoDI 5000.88) and additional guidance. Select the tiles below and please refer to Section 5 of the Systems Engineering Guidebook for more information.

Additional Design Considerations:

Accessibility (Section 508 Compliance)

Affordability - Systems Engineering Trade-Off Analyses

Anti-Counterfeiting

Commercial-Off-the-Shelf

Corrosion Prevention and Control

Critical Safety Items

Demilitarization and Disposal

Diminishing Manufacturing Sources and Material Shortages

Insensitive Munitions

Intelligence (Life-Cycle Mission Data Plan)

Interoperability and Dependencies

Item Unique Identification

Modular Design

Operational Energy

Packaging, Handling, Storage, and Transportation

Spectrum Management

Standardization

Supportability

Survivability

System Security Engineering

CREATED:
September 1, 2023
BY:
LAST MODIFIED:
September 18, 2023
BY:
DOCUMENT ID:
CONTRIBUTION TYPE:
CONTENT TYPE:

Discussions / Systems Engineering

DoD SEP Outline v4.1 Now Posted to SE&A Site
0 Replies
View Discussion
QUESTION SCENARIO
QUESTION

​DoD SEP Outline v4.1, 26 Apr 23, is now posted to the SE&A Engineering References for Program Office site in both Word and PDF formats. Links:

Word format

PDF format

SCENARIO
Updates to DTRAM, IMP/IMS Guide, and SEP Outline published in Apr-May 2023
1 Replies
View Discussion
QUESTION SCENARIO
QUESTION

​OUSD(R&E) SE&A has published updates to the following guidance documents in the past month:

DoD SEP Outline v4.1 adds a new Section 3.7 on Corrosion Prevention and Control (CPC). The sections after that were renumbered accordingly. v4.1 was released 26 Apr 23 but not yet posted on the SE&A website.

Defense Technical Risk Assessment Methodology (DTRAM) v6.4 adds emphasis on CPC by adding criteria 7.2.C5 to the Manufacturing parent criteria area and criteria 8.2.C4 to the RAM & Sustainment parent criteria area.

The Integrated Master Plan (IMP) and Integrated Master Schedule (IMS) Preparation and Use Guide update to the 2005 version was released in late May 2023. It, too, is not yet posted on the SE&A site but will be in the future.

SCENARIO
Goulet, Joseph… September 25, 2023 - 12:35pm

SE&A's updated IMP/IMS guide and SEP Outline have been posted to SE&A's "Policy and Guidance" site at [https://www.cto.mil/sea/pg/]. Also, SE&A just posted the updated RIO Guide (Sep 2023)

Human Systems Integration (HSI) is a key enabler to Systems Engineering processes
0 Replies
View Discussion
QUESTION SCENARIO
QUESTION

​Integrating human performance considerations into the defense acquisition system can present substantial challenges for Human Systems Integration (HSI) practitioners and stakeholders. The DAU HSI Community of Practice (CoP) provides a unique resource in this pursuit, offering a convenient platform to share knowledge aimed at achieving effective and relevant HSI practice across government, industry, and academia. Learn more about HSI as a Specialty Engineering discipline described within DODI 5000.88 for incorporating human needs during system design at the following resources:

DAU HSI COP

OUSD(R&E) HSI website:


SCENARIO

Events / Systems Engineering

No content available.

Announcements / Systems Engineering

Community Announcement / Systems Engineering
DoD Engineering Recruitment Tool (Brochure) - Now Available for Use
View Announcement

​SE CoP Members - In coordination with the Engineering Career Field Functional Integrated Product Team (FIPT) and OSD Graphics Division, a new DoD engineering recruitment tool has been developed to help attract new engineering talent to DoD’s workforce, and increase DoD’s recognition as one of the best places to work as an engineer.  The Defense Services and Agencies can use this brochure to augment their current recruiting and marketing material/messaging.  Included are examples which showcase how you can make a difference as a DoD engineer; descriptions of the unique work being done throughout the Department, and what you can look forward to as a DoD engineer. Also included are figures displaying the wide geographic distribution and variety of engineers employed by DoD.

Image removed.DoD Engineering Recruitment Tool (Brochure).pdf


Resources / Systems Engineering

Community Resource / Systems Engineering
SE Processes

Systems Engineering Processes

The SE processes are used by contractor and Government organizations to provide a framework and methodology to plan, manage and implement technical activities throughout the acquisition life cycle. SE planning and execution should focus on applying the processes and tools in a rigorous, integrated, and disciplined manner to achieve a system solution that balances performance, cost, schedule, and risk. 

The eight technical management processes, applicable to all acquisition pathways, provide a consistent framework for managing technical activities and identifying the technical information and events critical to the success of the program. Technical information includes controlled unclassified information (CUI) as well as classified and unclassified Critical Technical Information (CTI) about DoD sponsored research, technology, programs, and systems being acquired. The eight technical processes ensure the system design and the delivered capability reflect the requirements that the stakeholders have expressed. The 16 SE processes are applicable to all the AAF pathways to some degree. The PM and SE will determine which processes to use for their program. 

Whereas the technical management processes provide insight of, and control over, the technical development of a system throughout its life cycle, the technical processes are used to design, develop and analyze the system, system elements and enabling system elements required for integration, test, production, deployment, support, operation and disposal. The eight technical processes provide a framework for ensuring and maintaining traceability between stakeholder requirements, systems design and the eventual delivered capability.

For more information refer to Section 4 of the Systems Engineering Guidebook.

Technical Management Processes ​Technical Processes
​Technical Planning ​Stakeholder Requirements Definition
​Decision Analysis ​Requirements Analysis
​Technical Assessment ​Architecture Design
​Requirements Management ​Implementation
​Risk Management ​Integration
​Configuration Management ​Verification
​Technical Data Management ​Validation
​Interface Management ​Transition

CREATED:
September 1, 2023
BY:
Rhyne, Darren
LAST MODIFIED:
November 21, 2023
BY:
Rhyne, Darren
View Resource
Community Resource / Systems Engineering
SE Planning

Systems Engineering Planning

Systems Engineering planning, as documented in the Systems Engineering Plan (SEP), formulates the approach to conduct, manage and control all the technical activities to deliver a desired capability. SE Planning begins with the identification and decomposition of user needs and concepts, and progresses through development, delivery and sustainment of the final product. The Systems Engineering Guidebook provides overarching guidance on the systems engineering discipline, its activities and processes, and its practice in defense acquisition programs. This topical area contains information on SE Planning for DoD acquisitions. 

CREATED:
September 1, 2023
BY:
Content Author No Reply
LAST MODIFIED:
September 18, 2023
BY:
Content Author No Reply
View Resource
Community Resource / Systems Engineering
Process


Systems Engineering Process

This section is also a placeholder for text describing why a user would come to this site. What is it about? Explain here with a brief summary of SE Processes, this page and what is below.....


​Decision Analysis

Technical Planning

Technical Assessment

Requirements Management

Risk Management

Configuration Management

Technical Data Management

Interface Management


"These icons are placeholders for whatever images and lists you want to link to"

​ ​
Multi Media 
 Share an Idea/ Discussion
 Document Library

Decision Analysis 

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Technical Planning

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Technical Assessment

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Requirements Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.   

Risk Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Configuration Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulations, videos, chats, SMEs

Outputs: Tangible products that result from the work

Outcomes: Expected results.

Technical Data Management

Context: this is the "when", "where", and "why" regarding the subject process

Activities: specific tasks that are performed under this process

Tools: the 'tools' available to support the tasks, instructional guides, checklists, templates, workflow learning tools

Policy and Guidance: statutory, policy, regulatory guidance directly supporting the task need.

Supporting Knowledge: DAU courses, simulat
CREATED:
September 1, 2023
BY:
Content Author No Reply
LAST MODIFIED:
September 18, 2023
BY:
Content Author No Reply
View Resource
Community Resource / Systems Engineering
Design Considerations

Design Considerations

The PM, Systems Engineer, and Lead Software Engineer should address and document design considerations, including all statutory and regulatory requirements in order to:

  • Translate the end-user desired capabilities into a structured system of interrelated design specifications that support delivery of required operational capability.
  • Enable trade-offs among the design considerations in support of achieving desired mission effectiveness within cost and schedule constraints.
  • Incorporate design considerations into the set of system requirements, as some are mandated by laws, regulations, or treaties, while others are mandated by the domain or DoD Component or Agency; these mandates should be incorporated during the Requirements Analysis process to achieve balance across all system requirements.

The DoD has put additional emphasis on the four Specialty Engineering design considerations as well as Value Engineering identified in the tiles below resulting in development of additional policy (DoDI 5000.88) and additional guidance. Select the tiles below and please refer to Section 5 of the Systems Engineering Guidebook for more information.

Additional Design Considerations:

Accessibility (Section 508 Compliance)

Affordability - Systems Engineering Trade-Off Analyses

Anti-Counterfeiting

Commercial-Off-the-Shelf

Corrosion Prevention and Control

Critical Safety Items

Demilitarization and Disposal

Diminishing Manufacturing Sources and Material Shortages

Insensitive Munitions

Intelligence (Life-Cycle Mission Data Plan)

Interoperability and Dependencies

Item Unique Identification

Modular Design

Operational Energy

Packaging, Handling, Storage, and Transportation

Spectrum Management

Standardization

Supportability

Survivability

System Security Engineering

CREATED:
September 1, 2023
BY:
Content Author No Reply
LAST MODIFIED:
September 18, 2023
BY:
Content Author No Reply
View Resource
Community Resource / Systems Engineering
Technical Reviews and Audits

​

For DoD systems development, a properly tailored series of technical reviews and audits provide key points throughout the system development to evaluate significant achievements and assess technical maturity and risk. DoDI 5000.85, Major Capability Acquisition, and the Adaptive Acquisition Framework Document Identification Tool (AAFDIT) identify the statutory and regulatory requirements for acquisition programs. Regardless of acquisition pathway, the PM, Systems Engineer, and Lead Software Engineer work to properly align the applicable technical reviews to support knowledge-based milestone decisions that streamline the acquisition life cycle and save precious taxpayer dollars. Technical reviews and audits allow the PM, Systems Engineer, and Lead Software Engineer to jointly define and control the program’s technical effort by establishing the success criteria for each review and audit. A well-defined program facilitates effective monitoring and control through increasingly mature points.

For Technical Review and Audits policy requirements, refer to DoDI 5000.88, Engineering of Defense Systems. For general technical review and audit guidance, select the review or audit below or refer to Section 3 of the SE Guidebook. For AAF pathway specific guidance refer to the Engineering of Defense System Guidebook.

Alternative Systems Review

System Requirements Review

System Functional Review

Preliminary Design Review

Critical Design Review

System Verification Review/Functional Configuration Audit

Production Readiness Review

Physical Configuration Audit

CREATED:
September 1, 2023
BY:
Content Author No Reply
LAST MODIFIED:
September 1, 2023
BY:
Content Author No Reply
View Resource
Community Resource / Systems Engineering
Communities

​Related Acquisition Career Field Communities

Related Specialty Topics Communities

CREATED:
September 1, 2023
BY:
Content Author No Reply
LAST MODIFIED:
September 1, 2023
BY:
Content Author No Reply
View Resource
Community Resource / Systems Engineering
Transition Process

The Transition Process is the method to move any system element to the next level in the physical architecture. Transition activities vary based on life-cycle phase, program scale, and system complexity. For the end-item system, it is the process to install and field the system to the user in the operational environment. The end-item system may need to be integrated with other systems in the operational environment honoring the defined external interfaces. In this case, the Transition Process needs to be performed in conjunction with the Integration Process and Interface Management Process for a smooth transition. This sub-topical area contains information on the Transition Process found in the DAG Chapter 3 Section 4.2.8.

CREATED:
September 1, 2023
BY:
Content Author No Reply
LAST MODIFIED:
September 1, 2023
BY:
Content Author No Reply
View Resource
Community Resource / Systems Engineering
Supportability

Supportability 

Supportability refers to the inherent characteristics of the system and the enabling system elements that allow effective and efficient sustainment (including maintenance and other support functions) throughout the system’s life cycle. By addressing supportability as part of the system design, the PM, through the Systems Engineer and Product Support Manager (PSM), ensures the system reaches Initial Operational Capability (IOC) with the required enabling system elements in place. The benefits to the program are: 

  • Cost savings 
  • Fielding of a more affordable logistics infrastructure 
  • Improved Materiel and Operational Availability 
  • Reduced footprint 

Supportability analysis is an iterative activity conducted during the system’s development and is used by the PM and PSM to define the system’s support strategy. It includes sustainment-related should-cost management and risk and opportunity management efforts across the life cycle. Supportability analysis begins in stakeholder requirements definition, as part of the Analysis of Alternatives, and continues through the design, T&E, production, and deployment activities and phases of the system. The supportability analysis and the resultant product support package mature in parallel with the evolution of the design, and should be documented in an integrated data or decision environment, preferably a digital ecosystem. For more information on Supportability as a design consideration, see the Systems Engineering Guidebook, Section 5.21. 

 

CREATED:
September 1, 2023
BY:
Content Author No Reply
LAST MODIFIED:
September 1, 2023
BY:
Content Author No Reply
View Resource

Documents / Systems Engineering

Software Design Description SDD Data Item Description DID
Document Type:
Page Link
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

The Software Design Description (SDD) describes the design of a Computer Software Configuration Item (CSCI).  It describes the CSCI-wide design decisions, the CSCI architectural design, and the detailed design needed to implement the software.  The SDD, with its associated Interface Design Descriptions and Database Design Descriptions, is used as the basis for implementing the software.  It provides the acquirer visibility into the design and provides information needed for software support. The SDD DID (DI-IPSC-81435) can be found on the DoD DLA ASSIST website at http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=205915. BOV

Software Design Description SDD Data Item Description DID
MIL-STD-881, Work Breakdown Structures for Defense Materiel Items
Document Type:
Document
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

This Standard presents direction for effectively preparing, understanding, and presenting a Work Breakdown Structure (WBS). It provides the framework for Department of Defense (DoD) Program Managers to define their program's WBS and also to defense contractors in their application and extension of the contract's WBS.  A Work Breakdown Structure (WBS) provides a consistent and visible framework for defense materiel items and contracts within a program. The MIL-STD-881 can be found on the DoD DLA ASSIST website at http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=36026>. BOV

MIL-STD-881 Work Breakdown Structures for Defense Materiel Items 737377.doc
NAVAIR Specific SE Technical Reviews and Audits
Document Type:
Document
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

NAVAIR 4.1 Systems Engineering develops and grows the Systems Engineering capability of NAVAIR-through engineering policy, and substantive technical engagement throughout the life cycle of acquisition programs. Delivering a robust Systems Engineering capability across NAVAIR requires attention to Policy, People, and Practice. The NAVAIR Division developed the following Systems Engineering Technical Reviews and Audits policy, guidance, and checklist tool, specific to NAVAIR implementation.  NAVAIR Instruction 4355.19E SETR Process - https://teamworkflow.navair.navy.mil/cyberdocs/portalFiles/EDM_docs_view.asp?altentry=y&doc=465833&app=Directives NAVAIR SETR Process Handbook - https://nserc.nswc.navy.mil/navair/NAVAIRSE/SESharedDocuments/SETR%20Process%20Handbook%20v1.0.pdf NAVAIR SETR Checklist website - https://nserc.nswc.navy.mil/navair/NAVAIRSE/checklist/SitePages/home.aspx DISCLAIMER: This content is developed and maintained by NAVAIR SE Division 4.1 and is not endorsed by DASD(SE) for DoD-wide use. DISCLAIMER: This content is developed and maintained by NAVAIR SE Division 4.1 and is not endorsed by DASD(SE) for DoD-wide use.

NAVAIR Specific SE Technical Reviews and Audits 721973.doc
United States Code
Document Type:
Page Link
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

TBD TBD

United States Code
Systems Engineering Leading Indicators Guide
Document Type:
Page Link
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

Note: This contribution item is for reference only and is not endorsed by DASD(SE). This Systems Engineering Leading Indicators Guide is the result of a project initiated by the Lean Aerospace Initiative (LAI) Consortium in cooperation with the International Council on Systems Engineering (INCOSE), Practical Software and Systems Measurement (PSM), and Systems Engineering Advancement Research Initiative (SEARI). Leading measurement and systems engineering experts from government, industry, and academia volunteered their time to work on this initiative. This document is issued by INCOSE as document number INCOSE-TP-2005-001-03. A leading indicator is a measure for evaluating the effectiveness of a how a specific activity is applied on a program in a manner that provides information about impacts that are likely to affect the system performance objectives. A leading indicator may be an individual measure, or collection of measures, that are predictive of future system performance before the performance is realized. Leading indicators aid leadership in delivering value to customers and end users, while assisting in taking interventions and actions to avoid rework and wasted effort.

Systems Engineering Leading Indicators Guide
Software Transition Plan STrP Data Item Description DID
Document Type:
Document
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

The Software Transition Plan (STrP) identified the hardware, software, and other resources needed for life cycle support of deliverable software and describes the developer's plans for transitioning deliverable items to the support agency.  The STrP is developed if the software support concept calls for transition of responsibility from the developer to a separate support agency.  The STrP may also be used by the acquirer for updating the Computer Resources Life Cycle Management Plan.  This Data Item Description (DID) is used when the developer is tasked to develop and record plans for transitioning deliverable items to the support activity. The STrP DID (DI-IPSC-81429) can be found on the DoD DLA ASSIST website at http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=205908>. BOV

Software Transition Plan STrP Data Item Description DID 737394.doc
Schematic Block Diagrams Data Item Description DID
Document Type:
Page Link
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

Schematic Block Diagrams are used as the basis for displaying functional and technical requirements and interfaces.  As such, they support the design synthesis, integration, and interface compatibility functions. The Schematic Block Diagrams DID (DI-GDRQ-81223) can be found on the DoD DLA ASSIST website at http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=205262. BOV

Schematic Block Diagrams Data Item Description DID
NAVAIR Specific SE Policy, Guidance, and Tools
Document Type:
Page Link
Modified: Changed by Content Author No Reply on September 1, 2023
Summary

NAVAIR 4.1 Systems Engineering develops and grows the Systems Engineering capability of NAVAIR-through engineering policy, and substantive technical engagement throughout the life cycle of acquisition programs. Delivering a robust Systems Engineering capability across NAVAIR requires attention to Policy, People, and Practice. The NAVAIR SE website provided systems engineering policy, guidance,  training, and resources for NAVAIR systems engineers to support their mission. In addition, the website provides an online SETR checklist tool specific to NAVAIR policy and best practices.  NAVAIR SE Website: https://nserc.nswc.navy.mil/navair/NAVAIRSE/SitePages/Home.aspx    DISCLAIMER: The NAVAIR SE Website is developed and maintained by NAVAIR 4.1 Systems Engineering and is not endorsed by DASD(SE) for DoD-wide use.

NAVAIR Specific SE Policy, Guidance, and Tools
To participate in this community, you must be registered. Join Now