SIAP SE TEM 00720.ppt-1 IEEE Standard for Application & Management of the Systems Engineering Process Robert L. Hobart Deputy Commander, C4I Integration

SIAP SE TEM 00720.ppt-1

IEEE Standard for Application & IEEE Standard for Application & Management of the Management of the

Systems Engineering ProcessSystems Engineering Process

IEEE Standard for Application & IEEE Standard for Application & Management of the Management of the

Systems Engineering ProcessSystems Engineering ProcessRobert L. Hobart

Deputy Commander, C4I Integration(703) 784-0700

[email protected] Oct 2001


Evolution of StandardsEvolution of StandardsEvolution of StandardsEvolution of Standards

MILSTD499

MIL STD1521

MIL STD490A

MIL STD2167A

IEEE1220 - 1998

MIL STD961D

IEEE12207

COLD WAR 2000ACQUISITION

REFORM


IEEE 1220 - 1998IEEE 1220 - 1998IEEE 1220 - 1998IEEE 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


IEEE 1220 - 1998 (cont’d)IEEE 1220 - 1998 (cont’d)IEEE 1220 - 1998 (cont’d)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



Systems Engineering DefinedSystems Engineering DefinedSystems Engineering DefinedSystems 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


Discipline and ControlDiscipline and ControlDiscipline and ControlDiscipline and Control

SystemDefinition

Production

Customer

Support

PreliminaryDesign

DetailedDesign

Fabrication,Assembly,

Integration, andTest (FAIT)

SystemDefinition

SYSTEMBASELINE

BUILD-TOBASELINE

ACRSDR

DESIGN-TOBASELINE

ReviseEng & Tech

Plans forDetailedDesign

UpdateSystemBaseline

IdentifyInterfaces

ResolveComponent

Risks

PrepareIntegrated

DataPackage

SRRPDR

TRRFCA

PAR/PCADDR

ACR = Alternative Concept ReviewSDR = System Definition ReviewSRR = Software Requirements ReviewPDR = Preliminary Design ReviewDDR = Detailed Design ReviewTRR = Test Readiness ReviewFCA = Functional Configuration AuditPAR = Production Approval ReviewPCA = Physical Configuration Audit

SoftwareRequirements

Definition Phase

TestPlanningPhase

SoftwareVerification& Validation

PlanningPhase

ReviseEng & Tech

Plans forFAIT

Production & Deployment,

CustomerSupport

CompleteSpecifications

UpdateSystem

andDesign-ToBaselines

CompletePreliminaryDrawings for Each

Subsystem

CompleteSpecifications

CompleteComponentDefinition

(HW & SW)


Specification TreeSpecification TreeSpecification TreeSpecification Tree

Subsystemspecification




Assemblyspecification



Componentspecification




Productspecification

Operationalprocedures

Manpower,personnel, and trainingspecification

Operationalarchitecture

System

Systemsarchitecture



Human/SystemInterface Specification



Systems Engineering ProcessSystems Engineering ProcessSystems Engineering ProcessSystems Engineering Process

RequirementsAnalysis

RequirementsVerification

FunctionalAnalysis

FunctionalVerification

Synthesis

Requirements tradestudies and

assessments

Functional tradestudies and

assessments

Design tradestudies and

assessments

PROCESSINPUTS

DesignVerification

Verified physical architecture

Physical architecture

Verified functional architecture

Functional architecture

Validated requirements baseline

Requirements baseline

Design solutionrequirements and

alternatives

Design solutiontrade-offs and

impacts

Decomposition/allocationtrade-offs and impacts

Decomposition and requirement allocation

alternatives

Requirementtrade-offs and

impacts

Requirementand constraint

conflicts

PROCESS OUTPUTS

System

Analysis

Control



Requirements AnalysisRequirements AnalysisRequirements AnalysisRequirements Analysis

Define CustomerExpectations

Define ExternalConstraints

Define SystemBoundaries

Define Life CycleProcess

Concepts

To:Requirements Validation

DefinePerformanceRequirements

Define Modes ofOperations

Define DesignCharacteristics

Define HumanFactors

To:Functional ContextAnalysis (6.3.1)

To:Systems Analysis

Establish RequirementsBaseline

OperationalView

FunctionalView

DesignView

DefineOperationalScenarios

Define Measuresof Effectivness

Define Projectand Enterprise

Constraints

RequirementsAnalysis

From:• Systems Analysis• Control

From:• Requirements Validation• Functional Verification• Design Verification

Define Interfaces

DefineFunctional

Requirements

Define TechnicalPerformance

Measures

Define UtilizationEnvironments



Requirements ValidationRequirements ValidationRequirements ValidationRequirements Validation

RequirementsValidation

From:Requirements Analysis

To:• Control• Functional Analysis

Compare ToEnterprise and

Project Constraints

Compare ToExternal

Constraints

Compare ToCustomer

Expectations

Identify Variancesand Conflicts

To:Requirements Analysis

Establish ValidatedRequirements Baseline



Functional AnalysisFunctional AnalysisFunctional AnalysisFunctional Analysis

Functional Analysis

DefineFunctionalInterfaces

From:• Functional Verification• Design Verification

From:• Synthesis• Control

AllocatePerformanceRequirements

AnalyzeFunctionalBehaviors

Functional Context Analysis

Functional Decomposition DefineSubfunctions

DefineSubfunctions

States and Modes

DefineSafety Monitoring

Functions

DefineFunctionalTimelines

To:• Functional Verification• Control

From:Requirements Validation

Establish Functional Architecture

Define Data andControl Flows

Define FunctionalFailure Modes

and Effects

From:Requirements Analysis



Functional VerificationFunctional VerificationFunctional VerificationFunctional Verification

To:• Control• Synthesis

Functional Verification

From:• Functional Analysis (Functional Architecture

Requirements Baseline

Define VerificationProcedures

Conduct VerificationEvaluation

Verify Functionaland Performance

Measures

Verify Satisfactionof Constraints

Verify ArchitectureCompleteness

To:• Functional Analysis• Requirements Analysis

Verified FunctionalArchitecture

Identify Variancesand Conflicts



SynthesisSynthesisSynthesisSynthesisFrom:Functional Analysis

To: Design Verification

To:• Functional Verification• Design Verification• Control

Synthesis

Assess TechnologyRequirements

Assess Safety andEnvironmental Hazards

Assess Life CycleQuality Factors

Develop Models andFabricate Prototypes

Assess DesignCapacity to Evolve

IdentifyStandardizationOpportunities

Identify Make or BuyAlternatives

Assess Failure Modes,Effects, and Criticality

Assess TestabilityNeeds

Final Design

Define Design andPerformance

Characteristics

Define PhysicalInterfaces

Produce IntegratedData Package

Establish DesignArchitecture

To:Control

Initiate EvolutionaryDevelopment

To:Systems Analysis

Identify DesignSolution Alternatives

Group and AllocateFunctions

Identify Off-the-ShelfAvailability



Design VerificationDesign VerificationDesign VerificationDesign Verification

Design Verification

Select VerificationApproach

Define VerificationProcedures

Conduct VerificationEvaluation

Verify Functional andPerformance Measures

Identify Variance andConflicts

Establish Specifications andConfiguration Baselines

Develop Product BreakdownStructure(s)

From:Synthesis

Establish VerificationEnvironment

Define Inspection,Analysis, Demonstration,

or Test Requirements

— Requirements Baseline— Functional Architecture

Verify ArchitectureCompleteness

Verify Satisfactionof Constraints

To: — Requirements Analysis — Synthesis

To:Control

Verified DesignArchitecture

Verified Design Architecturesof Life Cycle Processes

VerifiedSystem Architecture

6.6.2

6.6.1.2

6.6.1

6.6

6.6.1.1 6.6.1.3

6.6.2.26.6.2.1 6.6.2.3

6.6.3

To:Control

6.6.46.6.5

6.6.6 6.6.7

6.6.8



ControlControlControlControl

To:Next Application of SystemsEngineering Process

Control

InterfaceManagement

From:• Requirements Analysis• Requirements Validation• Functional Analysis• Functional Verification• Synthesis• Design Verification• Systems Analysis

Technical Management

Performance-Based ProgressMeasurements

DataManagement

RiskManagement

ConfigurationManagement

Track Productand Process

Metrics

Track SystemAnalysis and

Verification/Test Data

Track PerformanceAgainst Technical

Plans

TrackRequirements

and DesignChanges

TrackPerformance

Against ProjectPlans

Update Specificationsand Configuration

Baselines

UpdateTechnical Plans

Integrated Database

To:• Requirements Analysis• Requirements Validation• Functional Analysis• Functional Verification• Synthesis• Design Verification• Systems Analysis

UpdateRequirement

Views andArchitectures

UpdateEngineering

Plans



Technical ReviewsTechnical ReviewsTechnical ReviewsTechnical 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



Technical Review ProcessTechnical Review ProcessTechnical Review ProcessTechnical Review Process

AfterDuringBefore

Plan

• Identify participants

• Assign roles andtasks

• Establish guidelinesand procedures

• Establish and useentry criteria

• Establish exitcriteria based on theevent-drivenschedule

Pre-review

• Individual andteam reviews

• Examine data

• Analyze data

• Track anddocumentanalysis

Resolve

• Assign responsibility

Follow-up

• Track actionitems andissues

• Track actionitem completiontrends

• Document anddistribute resultsof reviewand action itemcompletions

Review

• Individual andteam reviews

• Facilitate andpace meeting

• Examine reviewdata andanalyses-record andclassify findings

• Address keyissues identifiedby pre-reviewactivity

• Assess severityof problems

• Identify actionitems

Familiarize

• Have overviewmeeting

DSMC, Systems Engineering Fundamentals, 1999


Technical Review ComparisonTechnical Review ComparisonTechnical Review ComparisonTechnical 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 ConfigurationReview (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

Alternative Concept Review(ACR)

System Definition Review (SDR)

Subsystem, System PDR

Component, Subsystem, System DetailDesign Review (DDR)

Component, Subsystem, System TRR

Component, Subsystem,System Production Approval

Reviews (PAR)

Component, Subsystem,System FCA

Component, Subsystem,System PCA



Phasing of Technical ReviewsPhasing of Technical ReviewsPhasing of Technical ReviewsPhasing of Technical Reviews

Specifications

Major TechnicalReviews & Audits

MIL-STD-1521B SRR SSR PDR CDR TRR FCA PCA

SDREIA/IS-632 Reviews ASR SRR SFR SSR PDR CDR TRR SVR/ PCA

FCAsIEEE P1220 Reviews ACR SDefR PDR DDR TRR FCAs PCAs

PARs

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

Configuration

Baselines

Program-Unique

Specifications



Alternative Concept Review (ACR)Alternative Concept Review (ACR)Alternative Concept Review (ACR)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



System Definition Review (SDR)System Definition Review (SDR)System Definition Review (SDR)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.



Preliminary Design Review (PDR)Preliminary Design Review (PDR)Preliminary Design Review (PDR)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



Detailed Design Review (DDR)Detailed Design Review (DDR)Detailed Design Review (DDR)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



Test Readiness ReviewTest Readiness ReviewTest Readiness ReviewTest 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



Production Approval Review (PAR)Production Approval Review (PAR)Production Approval Review (PAR)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.



Functional Configuration AuditFunctional Configuration AuditFunctional Configuration AuditFunctional 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



Physical Configuration AuditPhysical Configuration AuditPhysical Configuration AuditPhysical 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



Back-up SlidesBack-up SlidesBack-up SlidesBack-up Slides


Systems Engineering ProcessSystems Engineering ProcessSystems Engineering ProcessSystems Engineering Process

PROCESS OUTPUT• Integrated Decision Data Base . . Decision Support Data . . System Functional Physical Architectures . . Specifications & Baseline• Baseline System Solution

Requirements Analysis• Analyze Missions & Environments• Identify Functional Requirements• Define/Refine Performance & Design Constraint Requirements

Requirements Loop

Systems Analysis& Control

Design Loop

Verification

• Select Preferred Alternatives• Trade-Off Studies• Effectiveness Analysis• Risk Management• Configuration Management• Interface Management• Data Management• Performance-Based• Progress Measurement . . SEMS . . TPM . . Technical Reviews

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

Synthesis• Transform Architecture (Functional to Physical)• Define Alternative Product Concepts• Define/Refine Physical Interfaces (Internal/External)• Define Alternative Product & Process Solutions

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


Acquisition Process Acquisition Process

Product Baseline. .

MS 0

Phase 0 Phase I Phase II Phase III

MS I MS II MS III

Functional Baseline

Allocated Baseline

Technical Management Plan (TMP) Update Update Update

ASR SRR SFR SSR PDR CDR TRR FCA PCA

ENGINEERING CHANGEREVIEWS

OperationalRequirement

Document(ORD)


Document(ORD)


Document(ORD)

SystemThreat

Assessment

SystemThreat

Assessment

SystemThreat

Assessment

MissionNeed

Statement

Concept System SubsystemsDeficiencyCorrection

Mods/ProductImprovements

System Performance Specification

Item Performance Specification

Item Detail Specification

Reassess Threat Reassess Threat Reassess Threat

Preplanned Product Improvement (P3I)

DraftGovernment

Approves

.Developmental

. Conceptual Performance Baseline




Requirements Loop


Design Loop



Verification





Requirements Loop


Design Loop



Verification





Requirements Loop


Design Loop



Verification





Requirements Loop


Design Loop



Verification





Requirements Loop


Design Loop



Verification



Functional Baseline (System)Functional Baseline (System)Functional Baseline (System)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


Allocated Baseline (Design-To)Allocated Baseline (Design-To)Allocated Baseline (Design-To)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


Product Baseline (Build-To)Product Baseline (Build-To)Product Baseline (Build-To)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


OPERATIONALNEEDS AND

REQUIREMENTS

OPERATIONALNEEDS AND

REQUIREMENTS

FEEDBACK (to in

clude P

Ms a

nd Oper

ators)

REVIS

E OR R

EFOCUS AS R

EQUIRED

3. IDENTIFY ATTRIBUTESTO SUPPORT OBJECTIVES

3. IDENTIFY ATTRIBUTESTO SUPPORT OBJECTIVES

TOP LEVELPERFORMANCEREQUIREMENTS

2. DEFINESYSTEM

BOUNDARIES

2. DEFINESYSTEM

BOUNDARIES

DESIGN REFERENCE

MISSION

4. ESTABLISH FUNCTIONAL

BASELINE

4. ESTABLISH FUNCTIONAL

BASELINE

FUNCTIONALBASELINE

1. DEFINE ENVIRONMENT

1. DEFINE ENVIRONMENT

SYSTEM DESCRIPTIONINTERFACES

SYSTEM ANALYSIS

WARFIGHTER

CONCURRENCE

PM SELECTALTERNATIVE

Partially Concurrent Not SequentialIterative

5. CONDUCTSYSTEM

RQMTS. REVIEW

5. CONDUCTSYSTEM

RQMTS. REVIEW

Products of th

e Syste

ms Engineer

ing Process

Common ProcessCommon Process

WARFIGHTERCONCURRENCE

GEO-ECONOMICALTERNATIVES

AFFORDABILITYBOUNDARIES

ID KEY COST ATTRIBUTESAND RELATIONSHIPS

CONDUCT LCC ANDCAIV TRADE-OFFS

Updated: 5 August 1997

ORD ATTRIBUTES


Discipline and ControlDiscipline and ControlDiscipline and ControlDiscipline and Control

SystemRqmts

DefinitionPhase

InterfaceDefinition

Phase

SoftwareRqmts

DefinitionPhase

SoftwareTop-Level

DesignPhase

SoftwareTest

PlanningPhase

DetailedSoftwareDesignPhase

Code DebugPhase

SoftwareIntegration

TestPhase

CSCITest

Phase

DeploymentPhase

A-SPEC

SRRSFR

MS I

B1,B2-SPECS

IRS

MS II

SSR

C, D, E-SPECSPCA/FCA

MS III

SoftwareTop-Level

DesignDocument

SoftwareTestPlan

PDR

C-SPEC(Prelim)

CDR

SoftwareDetailedDesign

Document SoftwareTest Procedures

TRR

ALLOCATEDBASELINE

PRODUCTBASELINE

FUNCTIONALBASELINE


Production Review Production Review Production Review 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

Documents

SIAP SE TEM 00720.ppt-1 IEEE Standard for Application & Management of the Systems Engineering Process Robert L. Hobart Deputy Commander, C4I Integration