IEEE Standard for Application & Management of the Systems Engineering Process

1. IEEE Standard for Application & Management of the Systems Engineering Process Robert L. Hobart Deputy Commander, C4I Integration (703) 784-0700 HobartRL@mcsc.usmc.mil 23 Oct 2001

2. Evolution of Standards MILSTD 499 MIL STD 1521 MIL STD 490A MIL STD 2167A ACQUISITION REFORM 2000 COLD WAR IEEE 1220 - 1998 MIL STD 961D IEEE 12207

3. IEEE 1220 - 1998 • Defines the interdisciplinary tasks that are required throughout a system’s life cycle to transform customer needs, requirements, and constraints into a system solution. • Intent is to guide the development of systems or commercial, government, military, and space applications. • Specifies the requirements for the systems engineering process and its application throughout the product life cycle. IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

4. IEEE 1220 - 1998 (cont’d) • Describes an integrated approach to product development, which represents the total technical effort for • Understanding the environments and related conditions for which product will be utilized/designed; • Defining product requirements in terms of functional requirements, quality factors, usability, producibility, supportability, safety, and environmental impacts; • Defining life cycle processes for manufacturing, test, distribution, support, training, and disposal IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

5. Systems Engineering Defined • Interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system people, product, and process solutions that satisfy customer needs. • Systems engineering encompasses: • Technical efforts related to the development, manufacturing, verification, deployment, operations, support, disposal of, and user training for, system products and processes • Definition and management of the system configuration • Translation of the system definition into work breakdown structures • Development of information for management decision making EIA Interim Standard, Systems Engineering 1994

6. Discipline and Control Complete ComponentDefinition(HW & SW) SYSTEM BASELINE DESIGN-TO BASELINE BUILD-TOBASELINE Software Verification & Validation PlanningPhase Software Requirements Definition Phase Test Planning Phase Complete Specifications IdentifyInterfaces CompleteSpecifications Production & Deployment,CustomerSupport Complete Preliminary Drawings for Each Subsystem Update System andDesign-ToBaselines Revise Eng & TechPlans forDetailedDesign Prepare IntegratedDataPackage Revise Eng & TechPlans forFAIT Resolve ComponentRisks Update SystemBaseline System Definition ACR = Alternative Concept Review SDR = System Definition Review SRR = Software Requirements Review PDR = Preliminary Design Review DDR = Detailed Design Review TRR = Test Readiness Review FCA = Functional Configuration Audit PAR = Production Approval Review PCA = Physical Configuration Audit TRRFCAPAR/PCA ACR SDR SRR PDR DDR Production Customer Support Fabrication,Assembly,Integration, andTest (FAIT) SystemDefinition Detailed Design Preliminary Design

7. Specification Tree IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

8. Systems Engineering Process PROCESS INPUTS Requirement and constraint conflicts Requirements Analysis Requirement trade-offs and impacts Requirements baseline Requirements trade studies and assessments Requirements Verification Decomposition and requirement allocation alternatives Validated requirements baseline System Functional Analysis Decomposition/allocation trade-offs and impacts Functional trade studies and assessments Functional architecture Functional Verification Design solution requirements and alternatives Verified functional architecture Analysis Synthesis Design solution trade-offs and impacts Physical architecture Design trade studies and assessments Design Verification Verified physical architecture Control PROCESS OUTPUTS IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

9. Requirements Analysis IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

10. Requirements Validation IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

11. Functional Analysis IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

12. Functional Verification IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

13. Synthesis IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

14. Design Verification IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

15. Control IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

16. Technical Reviews • Conduct Technical Reviews and audits for the purpose of assessing technical progress. • Design reviews should be conducted at the completion of each application of the SE process and accomplish the following: • Assess system requirements and allocations • Assess design maturity • Present risks associated with continued development • Assess life cycle processes and infrastructure • Identify resources required for continued development • Determine whether to proceed IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

17. Technical Review Process DSMC, Systems Engineering Fundamentals, 1999

18. Technical Review Comparison MIL-STD-1521B EIA IS-632 IEEE P1220 Alternative Systems Review (ASR) System Req’t Review (SRR) System Functional Review (SFR) SSR Preliminary Design Review (PDR) Critical Design Review (CDR) TRR Functional Configuration Audit (FCA) System Verification Review (SVR) - Replaced FQR & PRR System Physical Configuration Review (PCA) Alternative Concept Review (ACR) System Definition Review (SDR) Subsystem, System PDR Component, Subsystem, System Detail Design Review (DDR) Component, Subsystem, System TRR Component, Subsystem, System Production Approval Reviews (PAR) Component, Subsystem, System FCA Component, Subsystem, System PCA System Req’t Review (SRR) System Design Review(SDR) Software Spec Review (SSR) Preliminary Design Review (PDR) Critical Design Review (CDR) Test Readiness Review (TRR) Production Readiness Reviews (PRR) Formal Qualification Review (FQR) Functional Configuration Audit (FCA) - Replaced by MIL-STD-973 Physical Configuration Review (PCA) - Replaced by MIL-STD-973 DSMC, Systems Engineering Fundamentals, 1999

19. Phasing of Technical Reviews System Specification (formerly the A spec) Item Performance Spec (formerly the B spec) Item Detail (C), Process (D) and Material (E) Specification Functional (System) Baseline Allocated (Design-To) Baseline Product (Build-To) Baseline Specifications Major Technical Reviews & Audits         MIL-STD-1521BSRR SSR PDR CDR TRR FCA PCA SDR EIA/IS-632 ReviewsASR SRR SFR SSR PDR CDR TRR SVR/ PCA FCAs IEEE P1220 ReviewsACR SDefR PDR DDR TRR FCAs PCAs PARs Program-Unique Specifications Configuration Baselines DSMC, Systems Engineering Fundamentals, 1999

20. Alternative Concept Review (ACR) • Conducted to ensure that: • Allocations reasonable and sound • Capability of concept to satisfy customer requirements • Completion of system and product interface specifications and preliminary system specification • Establishment of the system baseline • Assessed risks associated with concept • Adequacy and completeness of systems analysis data to substantiate decisions made in defining concept IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

21. System Definition Review (SDR) • Conducted to ensure that: • Sufficient maturity to meet Systems Engineering Management Schedule (SEMS) criteria • System-level risks have been adequately addressed • Trade-study data are adequate to substantiate that requirements are achievable • Decisions made in arriving at the system definition configuration are well supported by analysis, test, and/or other technical data. IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

22. Preliminary Design Review (PDR) • Conducted to ensure sufficient progress is being made toward completion of: • Item performance specifications • Draft Item Detail, Process, and Material specifications • Design data-defining major subsystems, equipment, software, and other systems elements • Analyses, reports, “-ility” analyses, trade studies, logistics support analysis data, and design documentation • TPM data and analysis • Engineering breadboards, laboratory models, test models, mockups, prototypes used to support the design, and • Supplier data describing specific components IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

23. Detailed Design Review (DDR) • Conducted to ensure that: • Each detailed component definition is sufficiently mature to meet MOE/MOP criteria • Component specifications are reasonable and provide sound concept • Component and related LC risks have been assessed and mitigated to support Fabrication, Assembly, Integration, and Test (FAIT) • Trade-study data are adequate to substantiate that detailed component requirements are achievable • Decisions made are well supported by analysis and technical data IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

24. Test Readiness Review • Conducted to assure that: • Test procedures comply with test plans and descriptions, demonstrate adequacy to accomplish test requirements, and satisfy specification qualification requirements • Pretest predictions and informal test results indicate testing will confirm satisfaction of specification requirements • New or modified test support equipment, facilities, and procedural manuals, are available • Required specification, baseline, and other supporting documentation are complete IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

25. Production Approval Review (PAR) • Conducted to confirm that: • Issues for components, assemblies, subsystems, products, and LC processes and services are resolved • Test procedures were completed and accurate • System and products were confirmed ready for test • Tests were conducted IAW established procedures • An audit trail from design reviews is established with changes substantiated, and all products meet specification requirements • Risk handling procedures are satisfactory for production • Evolutionary development requirements and plans have been refined • Planning is complete and procedures, resources, and other requisite people, products, and processes are available to initiate production, etc. IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

26. Functional Configuration Audit • Conducted to verify that: • Products have achieved requirements • Products have satisfied the characteristics as specified in specifications, interface specifications, and other baseline documentation • Test plans and procedures were complied with IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

27. Physical Configuration Audit • Conducted to ensure that: • System, subsystem, configuration item detailed design satisfy user requirements • All system, subsystem, configuration items have been baselined • All system elements conform to the technical documentation that defines the Product (Build-To) baseline • Changes to previous baselines have been completed • Testing deficiencies have been resolved and implemented • System processes are current and can be executed IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

28. Back-up Slides

29. Systems Engineering Process • PROCESS INPUT • Customer Needs/ • Objectives/ • Requirements • . . Mission/ • Operations • . . Measures of • Effectiveness • . . Environments • . . Constraints • Technology Base • Prior Output Data • Program Decision • Requirements • Requirements From • Tailored Standards • and Specifications Systems Analysis & Control • Requirements Analysis • Analyze Missions & Environments • Identify Functional Requirements • Define/Refine Performance & Design • Constraint Requirements • Select Preferred • Alternatives • Trade-Off Studies • Effectiveness Analysis • Risk Management • Configuration • Management • Interface Management • Data Management • Performance-Based • Progress Measurement • . . SEMS • . . TPM • . . Technical Reviews Requirements Loop • Functional Analysis/Allocation • Decomposition is Lower-Level Functions • Allocate Performance & Other Limiting • Requirements is Lower-Level Functions • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture Design Loop • Synthesis • Transform Architecture (Functional to Physical) • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions Verification • PROCESS OUTPUT • Integrated Decision Data Base • . . Decision Support Data • . . System Functional • Physical Architectures • . . Specifications & Baseline • Baseline System Solution

30. Acquisition Process Phase 0 Phase I Phase II Phase III MS III MS 0 MS I MS II . Government Approves Draft . Conceptual Performance Baseline Functional Baseline . . Allocated Baseline Developmental Product Baseline Deficiency Correction Mods/Product Improvements System Concept Subsystems • PROCESS INPUT • Customer Needs/ • Objectives/ • Requirements • . . Mission/ • Operations • . . Measures of • Effectiveness • . . Environments • . . Constraints • Technology Base • Prior Output Data • Program Decision • Requirements • Requirements From • Tailored Standards • and Specifications • PROCESS INPUT • Customer Needs/ • Objectives/ • Requirements • . . Mission/ • Operations • . . Measures of • Effectiveness • . . Environments • . . Constraints • Technology Base • Prior Output Data • Program Decision • Requirements • Requirements From • Tailored Standards • and Specifications • PROCESS INPUT • Customer Needs/ • Objectives/ • Requirements • . . Mission/ • Operations • . . Measures of • Effectiveness • . . Environments • . . Constraints • Technology Base • Prior Output Data • Program Decision • Requirements • Requirements From • Tailored Standards • and Specifications • PROCESS INPUT • Customer Needs/ • Objectives/ • Requirements • . . Mission/ • Operations • . . Measures of • Effectiveness • . . Environments • . . Constraints • Technology Base • Prior Output Data • Program Decision • Requirements • Requirements From • Tailored Standards • and Specifications • PROCESS INPUT • Customer Needs/ • Objectives/ • Requirements • . . Mission/ • Operations • . . Measures of • Effectiveness • . . Environments • . . Constraints • Technology Base • Prior Output Data • Program Decision • Requirements • Requirements From • Tailored Standards • and Specifications • Functional Analysis/Allocation • Decomposition is Lower-Level Functions • Allocate Performance & Other Limiting • Requirements is Lower-Level Functions • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture • Functional Analysis/Allocation • Decomposition is Lower-Level Functions • Allocate Performance & Other Limiting • Requirements is Lower-Level Functions • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture • Functional Analysis/Allocation • Decomposition is Lower-Level Functions • Allocate Performance & Other Limiting • Requirements is Lower-Level Functions • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture Systems Analysis & Control Systems Analysis & Control Systems Analysis & Control • Functional Analysis/Allocation • Decomposition is Lower-Level Functions • Allocate Performance & Other Limiting • Requirements is Lower-Level Functions • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture • Functional Analysis/Allocation • Decomposition is Lower-Level Functions • Allocate Performance & Other Limiting • Requirements is Lower-Level Functions • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture Systems Analysis & Control Systems Analysis & Control • Requirements Analysis • Analyze Missions & Environments • Identify Functional Requirements • Define/Refine Performance & Design • Constraint Requirements • Requirements Analysis • Analyze Missions & Environments • Identify Functional Requirements • Define/Refine Performance & Design • Constraint Requirements • Requirements Analysis • Analyze Missions & Environments • Identify Functional Requirements • Define/Refine Performance & Design • Constraint Requirements • Select Preferred • Alternatives • Trade-Off Studies • Effectiveness Analysis • Risk Management • Configuration • Management • Interface Management • Data Management • Performance-Based • Progress Measurement • . . SEMS • . . TPM • . . Technical Reviews • Select Preferred • Alternatives • Trade-Off Studies • Effectiveness Analysis • Risk Management • Configuration • Management • Interface Management • Data Management • Performance-Based • Progress Measurement • . . SEMS • . . TPM • . . Technical Reviews • Select Preferred • Alternatives • Trade-Off Studies • Effectiveness Analysis • Risk Management • Configuration • Management • Interface Management • Data Management • Performance-Based • Progress Measurement • . . SEMS • . . TPM • . . Technical Reviews • Requirements Analysis • Analyze Missions & Environments • Identify Functional Requirements • Define/Refine Performance & Design • Constraint Requirements • Requirements Analysis • Analyze Missions & Environments • Identify Functional Requirements • Define/Refine Performance & Design • Constraint Requirements • Select Preferred • Alternatives • Trade-Off Studies • Effectiveness Analysis • Risk Management • Configuration • Management • Interface Management • Data Management • Performance-Based • Progress Measurement • . . SEMS • . . TPM • . . Technical Reviews • Select Preferred • Alternatives • Trade-Off Studies • Effectiveness Analysis • Risk Management • Configuration • Management • Interface Management • Data Management • Performance-Based • Progress Measurement • . . SEMS • . . TPM • . . Technical Reviews Requirements Loop Requirements Loop Requirements Loop Requirements Loop Requirements Loop • Synthesis • Transform Architecture (Functional to Physical) • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions • Synthesis • Transform Architecture (Functional to Physical) • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions • Synthesis • Transform Architecture (Functional to Physical) • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions • Synthesis • Transform Architecture (Functional to Physical) • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions • Synthesis • Transform Architecture (Functional to Physical) • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions Design Loop Design Loop Design Loop Design Loop Design Loop Verification Verification Verification Verification Verification • PROCESS OUTPUT • Integrated Decision Data Base • . . Decision Support Data • . . System Functional • Physical Architectures • . . Specifications & Baseline • Baseline System Solution • PROCESS OUTPUT • Integrated Decision Data Base • . . Decision Support Data • . . System Functional • Physical Architectures • . . Specifications & Baseline • Baseline System Solution • PROCESS OUTPUT • Integrated Decision Data Base • . . Decision Support Data • . . System Functional • Physical Architectures • . . Specifications & Baseline • Baseline System Solution • PROCESS OUTPUT • Integrated Decision Data Base • . . Decision Support Data • . . System Functional • Physical Architectures • . . Specifications & Baseline • Baseline System Solution • PROCESS OUTPUT • Integrated Decision Data Base • . . Decision Support Data • . . System Functional • Physical Architectures • . . Specifications & Baseline • Baseline System Solution Update Update Update Technical ManagementPlan (TMP) Preplanned Product Improvement (P3I) ASR SRR SFR SSR PDR CDR TRR FCA PCA ENGINEERING CHANGE REVIEWS Operational Requirement Document (ORD) Operational Requirement Document (ORD) Operational Requirement Document (ORD) System Threat Assessment System Threat Assessment System Threat Assessment Mission Need Statement System Performance Specification Item Performance Specification Item Detail Specification Reassess Threat Reassess Threat Reassess Threat

31. Functional Baseline (System) • Describes a system’s or item’s functional performance, interoperability, and interface requirements. • Includes: • System interface specification • Product interface specifications • System specification • Product specifications • Integrated database that captures the design, data, models, metrics, changes, design rationale, and other pertinent information on decisions or calculations made to system requirements

32. Allocated Baseline (Design-To) • Describes a subsystem functional, performance, interoperability, and interface requirements that are allocated from those of the system or a higher level sub-system • Includes: • Assembly and component interface specifications • Subsystem specifications • Assembly specifications • Integrated database that captures the design, data, models and tools used, metrics, changes, design rationale, and other pertinent information on decisions or clarification made to subsystem requirements

33. Product Baseline (Build-To) • Describes all the necessary functional, performance, and physical requirements of the subsystem; the functional and physical requirements designated for production acceptance testing • Includes: • Component interface specifications • Component specifications • Integrated database that captures the design, data, models and tools used, metrics, changes, design rationale, and other pertinent information on decisions or clarification made to component requirements • Product baseline may consist of the actual equipment and software

34. Common Process DESIGN REFERENCE MISSION Partially Concurrent Not Sequential Iterative CONDUCT LCC AND CAIV TRADE-OFFS FUNCTIONAL BASELINE 5. CONDUCT SYSTEM RQMTS. REVIEW Products of the Systems Engineering Process TOP LEVEL PERFORMANCE REQUIREMENTS ID KEY COST ATTRIBUTES AND RELATIONSHIPS 4. ESTABLISH FUNCTIONAL BASELINE AFFORDABILITY BOUNDARIES SYSTEM DESCRIPTION INTERFACES SYSTEM ANALYSIS PM SELECT ALTERNATIVE 3. IDENTIFY ATTRIBUTES TO SUPPORT OBJECTIVES ORD ATTRIBUTES GEO-ECONOMIC ALTERNATIVES 2. DEFINE SYSTEM BOUNDARIES WARFIGHTER CONCURRENCE WARFIGHTER CONCURRENCE FEEDBACK (to include PMs and Operators) REVISE OR REFOCUS AS REQUIRED 1. DEFINE ENVIRONMENT OPERATIONAL NEEDS AND REQUIREMENTS Updated: 5 August 1997

35. Discipline and Control FUNCTIONAL BASELINE ALLOCATED BASELINE PRODUCT BASELINE Software Top-Level Design Phase Detailed Software Design Phase Software Integration Test Phase Interface Definition Phase Deployment Phase System Rqmts Definition Phase Software Test Planning Phase Software Rqmts Definition Phase Code Debug Phase CSCI Test Phase Software Detailed Design Document Software Top-Level Design Document Software Test Procedures TRR A-SPEC C, D, E-SPECS PCA/FCA B1,B2-SPECS Software Test Plan C-SPEC (Prelim) SRR SFR IRS SSR CDR PDR MS I MS II MS III

36. Production Review • Conducted to confirm that: • Issues for the components, assemblies, subsystems, products, and life-cycle processes and services are resolved • Test procedures for components, assemblies, subsystems, and products were completed and were accurate • The system and products were confirmed ready for test • Tests were conducted IAW established procedures • Audit trail is established with changes substantiated and all requirements met • Risk management procedures satisfactory for production • Evolutionary development requirements and plans have been defined/refined • Planning is complete and procedures, resources, and other requisite people, products, and processes are available to initiate production, distribution, operations, support, training, disposal, and evolutionary development