1. SE Review Lesson 01 Systems engineering can also be viewed as a “V”
Design – is the left leg. It is a top-down process. It starts with definition of system level requirements, proceeds to item level, and finally to detailed design requirements, reviewed at the CDR.
Fabricate, Integrate, and Test – right leg. A bottom-up process that starts with the build up of components and assemblies, to configuration items, and finally to the system level.
Note the technical review that are normal to the process and to evaluating progress as the effort proceeds.
Lesson 01

2. DoD Acquisition Policy
DoD Directive
“Acquisition programs shall be managed through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. A modular, open-systems approach shall be employed.”

3. SE in the System Life Cycle Defense Acquisition Guidebook Chapter 4, Section 4.3
By phase consideration of SE activities
Purpose of SE in the phase
Support
Inputs to the SE process
Key SE activities during the phase
Technical reviews during the phase
Outputs of the phase’s SE process
Full life cycle coverage from Concept Refinement through Operations and Support

4. 8 5 3 Technical Management Processes Technical Processes
Technical Planning
Risk Management 8
Interface Management
Requirements Management
Technical Assessment
Configuration Management
Decision Analysis
Data Management
TECHNICAL PROCESSES
Technical Processes
Stakeholder Requirements Validation 5 3
Transition
Requirements Analysis Process
Validation
Technical Management Processes are used to manage the technical development of the system, including its supporting or enabling products. They include: Technical Planning, Technical Assessment and Decision Analysis and a set of processes collectively referred to as Technical Control Processes. These include: Requirements Management, Interface Management, Risk Management, Configuration Management, and Technical Data Management.
Architecture Design Process
Verification
Implementation
Integration
The Defense Acquisition Guidebook Systems Engineering Process Model consists of 3 Design Processes,
5 Realization Processes, and 8 Technical Management Processes

5. Stakeholder Requirements Validation
Starts with user (operational) requirements
Is an iterative process
Determines requirement clarity, understandability, achievability with state of art, and validation strategy
Results in proper balance between performance, schedule, and affordable cost
Requirements Development Questions
What are the reasons behind the system development?
What are the customer expectations?
Who are the users and how do they intend to use the product?
What do the users expect of the product?
What are their levels of expertise?
What environmental characteristics does the system have to comply with?
What are existing and planned interfaces?
What functions will the system perform, expressed in customer language?
What are the constraints - hardware, software, economic, procedural - that the system must comply with?
What laws or regulations will constrain the system design or its operation?
What will be the final form of the product - model, prototype, mass production?

6. Requirements Analysis Process
Each system, sub-system, and lower-level function and performance requirement is analyzed.
Recursive process allocating a requirement from higher level to next level
Provides enough detail to continue design process at next level
Results in traceable requirements
Product is a description of the system in functional terms

7. Architecture Design Process
A trade and Synthesis process that combines and structures components to represent a feasible configuration with the lowest acceptable risk.
Design must be consistent with functional analysis and allocation
Must do what has to be done
Must do it as well as required
Design is traceable to the Logical elements
Technical data packages, standards

8. Requirements Flowdown
ConOps / ICD
• UGV will be capable of operations world wide...
CDD / SYSTEM SPEC
• UGV weight NTE 2,400 lb...
• On Road/Off Road speeds NLT 35
and 20 kts respectively...
• System will be supportable by
existing logistics system...
ARMOR
SPEC
ENGINE
SPEC
Dec 08/Matt and Bill Devlin – make this slide specific to IPOD software. Down load, play and store music. Needs interfaces to do that.
• Empty gross
weight NTE
2,000 lb...
• Absorb shock
...15 fps rate of
descent...
• ...airlift...
• Weight NTE 800 lb...
• MTTR NTE 1.5 hours in the
field.
ITEM SPECS

9. Important Design Considerations “The Fishbone”

10. Systems Engineering Design Processes
Customer Needs
Tech Base
Prior SEP Output
Pgm Decision Req’ts
Budget
Requirements
Development
Do what? Functions
How well? Performance
Environment? Interfaces
Req’ts Loop
Test and Evaluation
F F F F N
R X X
R X
R X X
RN X X
CDD Req’ts Spec Req’ts
Implied Req’ts
Questions for Requirers
PATROL
CRUISE TO
POSITION
SENTRY
ATTACK
DESCEND
REPO
TIMELINE
Logical Analysis
ID Functions
Decompose Function
Allocate Req’ts
HW HW SW SW N
F X X
F X X
F X
FN X X
Design Loop
Design Solution
(2 min.) (60 min., (1 min.)
50 km range)
MOVE
CRUISE
STOP
(67 min., 50 km range)
START
HI / LO
Decision Database
ARMOR
ENGINE
COMMUNI-
CATIONS
UGV
Specifications
Process
Material
System
Item Perf
Item Detail
Baselines
Functional (System)
Allocated (Perf)
Product (Detail)

11. Capability Needs to System Designs
• ICD, CDD
• Concept of Operations
• Scenarios
• Support Concepts SE
PROCESS
Specifications
• Functional Requirements
• Performance Requirements
• Physical Requirements
• Interface Requirements SE
PROCESS
Design Descriptions
• Detailed technical descriptions
(drawings, wiring diagrams, etc)

12. Implementation
Implementation is the process that actually yields the lowest level system elements in the system hierarchy
Elements can be made, bought, or reused
Making it involves the hardware fabrication processes of forming, removing, joining, and finishing; or the software processes of coding, etc.
If implementation involves a production process, a manufacturing system is required to be developed

13. Integration
Integration is the process of incorporating the lower-level system elements into a higher-level system element in the physical architecture
An assembled system element, also developed with the technical and technical management processes, may include fixtures for hardware or compilers for software
Integration also refers to the incorporation of the final system into its operational environment and defined external interfaces

14. Verification
The Verification Process confirms that the system element meets the design-to or build-to specifications
It answers the question "Did you build it right?"
It tests the system elements against their defined requirements ("build-to" specifications)
Verification is carried out during contractor testing and government developmental testing.

15. Validation
The Validation Process answers the question of "Did you build the right thing?"
It tests the performance of systems within their intended operational environment, with anticipated operators and users
In the early stages of the system life cycle, validation may involve prototypes, simulations, or mock-ups of the system and a model or simulation of the system's intended operational environment
Validation is carried out as part of government operational testing

16. Transition
Transition is the process applied to move the system element to the next level in the physical architecture or, for the end-item system, to the user
This process may include installation at the operator or user site

17. 8 5 3 Technical Management Processes Technical Processes
Technical Planning
Risk Management 8
Interface Management
Requirements Management
Technical Assessment
Configuration Management
Decision Analysis
Data Management
TECHNICAL PROCESSES
Technical Processes
Stakeholder Requirements Validation 5 3
Transition
Requirements Analysis Process
Validation
Technical Management Processes are used to manage the technical development of the system, including its supporting or enabling products. They include: Technical Planning, Technical Assessment and Decision Analysis and a set of processes collectively referred to as Technical Control Processes. These include: Requirements Management, Interface Management, Risk Management, Configuration Management, and Technical Data Management.
Architecture Design Process
Verification
Implementation
Integration
The Defense Acquisition Guidebook Systems Engineering Process Model consists of 3 Design Processes,
5 Realization Processes, and 8 Technical Management Processes

18. Risk Components Root Cause (future tense / yet to happen):
If eliminated or corrected would prevent a potential consequence from occurring.
Probability (likelihood):
Assessed with the formulation of the “Future Root Cause”
Consequence (effect):
Impact of that future occurrence.
Reference: Risk Management Guide for DOD Acquisition August 2006

19. Risk Management Process
Identification
Risk
Analysis
Risk
Tracking
Risk
Mitigation
Planning
Reference: Risk Management Guide for DOD Acquisition August 2006, Chapter 2.2, page 4, Figure 1. DoD Risk Management Process.
Risk
Mitigation
Plan Implementation
A Process, Not an Event

20. Risk Reporting Matrix Risk Title (P, S, or C) Risk Causal Factor
Mitigation Approach
Reference: Risk Management Guide for DOD Acquisition August 2006, Chapter 4.2, page 11, Figure 2. Risk Reporting Matrix.

21. Levels of Likelihood Criteria
Reference: Risk Management Guide for DOD Acquisition August 2006, Chapter 4.2, page 12, Figure 3. Levels of Likelihood Criteria.

22. Levels & Types of Consequence Criteria
Level Technical Performance Schedule Cost
Minimal or no consequence to technical performance
Minimal or no impact
Minimal or no impact 1
Minor reduction in technical performance or supportability, can be tolerated with little or no impact to program
Able to meet key dates
Slip <__months
Budget or UPC increase
<__ (1% Budget) 2
Minor sched slip. Able to meet key M/S with no sched float
Slip <__months
Budget or UPC increase
<__ (5% Budget)
Moderate reduction in technical performance or supportability with limited impact on program objectives 3
Significant degradation in technical performance or major shortfall in supportability; may jeopardize program success
Program Critical path affected
Slip <__months
Budget or UPC increase
<__ (10% Budget) 4 4
Severe degradation in technical performance; Cannot meet KPP or key technical/supportability threshold; will jeopardize program success
Cannot meet program key M/S
Slip >__months
Exceeds APB threshold
>__ (10% Budget) 5

23. Risk Mitigation Planning Risk Handling
Four Fundamental Strategies
Avoidance
Control
Assumption
Transfer
Handling also requires Risk Monitoring activities:
Test and evaluation
Earned Value reporting
Technical Performance Measures
Program Metrics
Network Scheduling (PERT, CPM, etc)
Technical Reviews (entrance / exit criteria)
Risk Handling Strategies: Notice that they spell ACAT (or CAAT). Avoidance
Change requirements
Fewer “Non-negotiable” requirements
Honest requirements scrub
Change specifications
Trade space - fewer specific parameters
Ranges of acceptability
Change design concepts
Open systems
Risk Handling Strategies: Control
Multiple developments
Back-up designs
Prototypes
Incremental development/open systems
Test-analyze-fix
Design of Experiments/Robust Design
Modeling and Simulation
Walk-through reviews
Risk Handling Strategies: Transfer
Re-allocation
Software-hardware allocations
Government-contractor tasks
Contracting techniques
Contract types
Warranties
Risk Handling Strategies: Assumption
Ensure management $ reserves adequate
Ensure that other resources (human, facilities, etc) are reserved

24. Risk Handling Using Entrance Criteria
REQUIREMENT
INDIVIDUAL TASKS REQUIRED
LEAD TIME DAYS
EVENT
REQUIREMENT
Requirements Stable
System Functional Analysis Complete
Performance Allocated to Functions
Performance meets System Reqmts.
Performance Traces to Reqmts.
Performance Measurable
Performance Within Risk Parameter
MIL-STD 961E Compliant
Item Performance Specifications by PDR
PDR
Risk Handling Strategies: Avoidance
Change requirements
Fewer “Non-negotiable” requirements
Honest requirements scrub
Change specifications
Trade space - fewer specific parameters
Ranges of acceptability
Change design concepts
Open systems
Risk Handling Strategies: Control
Multiple developments
Back-up designs
Prototypes
Incremental development/open systems
Test-analyze-fix
Design of Experiments/Robust Design
Modeling and Simulation
Walk-through reviews
Risk Handling Strategies: Transfer
Re-allocation
Software-hardware allocations
Government-contractor tasks
Contracting techniques
Contract types
Warranties
Risk Handling Strategies: Assumption
Ensure management $ reserves adequate
Ensure that other resources (human, facilities, etc) are reserved
Ref: DAG Chapter , PDR

25. Technical Planning (related to the SEP focus areas)
Program Requirements
Understanding of User Requirements?
Understanding of Program Requirements?
Understanding of Technology, Risks, Maturity?
Understanding of Technology Cost & Schedule?
Understanding of Technology Critical Path?
Technical Staff & Organization
Program Technical Authority Oversight?
Lead SE role & authority?
Technical Activity Integration with IPTs?
IPT organizations, resourcing, staffing, metrics?
Government/Contractor IPT Integration?
Technology Maturation & Technical Planning
Responsibility for Capability Reqmts & System Specification?
Technical Baseline Definition & Management for TD (note: TDS)?
TDS Reqmts Traceability & Verification?
Mapping User Material Recommendations & Key Boundary Conditions?
How Technical Maturity & Risk Assessed?

26. Technical Planning (related to the SEP focus areas)
Technical Review Planning
TR Entrance & Exit Criteria Support Technical Risk?
Responsibility for TRs?
TR Independent Chairs?
TR Detail for Attendees, Statutory/Regulatory/Certification Needs?
Identify SMEs & Participants for every Review?
Integration with Overall Program
Integration of Technical Critical Path, IMP & IMS?
Technical Metrics Used (e.g. TRs & CPM)
Technical Approach Supports Risks?
Technical Approach Support of T&E and Support Strategies?
Technical Approach Support of Contract Strategies?

27. REQUIREMENTS MANAGEMENT
TECHNICAL
PLANNING
RISK MANAGEMENT
DECISION ANALYSIS
SCHEDULE
CONFIGURATION MANAGEMENT
INTERFACE MANAGEMENT
DATA MANAGEMENT
TECHNICAL
ASSESSMENT
STATUTORY
REGULATORY
COST
REQUIREMENTS MANAGEMENT

28. Acq. Strategy = Technical + Business
FY-1
FY-2
FY-3
FY-4
FY-5
SYSTEM DEV & DEMO
PROD & DEPLOYMENT
OPS & SPT
Milestones
& Phases
Concept
Refinement
Technology
Development
System Integration System Demo
LRIP Full Rate Prod
Concept
Decision A B
DRR C
FRP
Decision
Review
IOC
SE Processes
Expertise /
Skill Sets
Technical Reviews
Technical Baselines
Technical
Data
Testing
Development
Operational
DT&E
LRIP
Option
FRP
EOA OA IOT&E
Deliveries
Prototypes
EDMs
LRIP Production
Version /24/06

29. Technical Planning Thread (based on risk factor)
REQUIREMENT
INDIVIDUAL TASKS REQUIRED
LEAD TIME DAYS
EVENT
REQUIREMENT
Requirements Stable
Prototype Available
Relevant Test Environment Identified
Test Plan Approved
Conduct Test and Evaluation
Analyze TRL 6 Attainment
TRL 6 by SRR
SRR
Risk Handling Strategies: Avoidance
Change requirements
Fewer “Non-negotiable” requirements
Honest requirements scrub
Change specifications
Trade space - fewer specific parameters
Ranges of acceptability
Change design concepts
Open systems
Risk Handling Strategies: Control
Multiple developments
Back-up designs
Prototypes
Incremental development/open systems
Test-analyze-fix
Design of Experiments/Robust Design
Modeling and Simulation
Walk-through reviews
Risk Handling Strategies: Transfer
Re-allocation
Software-hardware allocations
Government-contractor tasks
Contracting techniques
Contract types
Warranties
Risk Handling Strategies: Assumption
Ensure management $ reserves adequate
Ensure that other resources (human, facilities, etc) are reserved
Law: SEC REQUIREMENT FOR CERTIFICATION BEFORE MDAP MAY PROCEED TO M/S B. (Chap. 139, Title 10 USC)
Sec. 2366a…
(a) Certification- ….
(1) the technology in the program has been demonstrated in a relevant environment;
TRL 6 Definition: Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology's demonstrated readiness. Examples include testing a prototype in a high-fidelity laboratory environment or in simulated operational environment.
Ref: DAG Chapter , TRL

30. Technical Planning Thread (based on risk factor)
REQUIREMENT
INDIVIDUAL TASKS REQUIRED
LEAD TIME DAYS
EVENT
REQUIREMENT
Requirements Stable
Prototype Available
Relevant Test Environment Identified
Test Plan Approved
Conduct Test and Evaluation
Analyze TRL 7 Attainment
TRL 7 by PDR
PDR
Risk Handling Strategies: Avoidance
Change requirements
Fewer “Non-negotiable” requirements
Honest requirements scrub
Change specifications
Trade space - fewer specific parameters
Ranges of acceptability
Change design concepts
Open systems
Risk Handling Strategies: Control
Multiple developments
Back-up designs
Prototypes
Incremental development/open systems
Test-analyze-fix
Design of Experiments/Robust Design
Modeling and Simulation
Walk-through reviews
Risk Handling Strategies: Transfer
Re-allocation
Software-hardware allocations
Government-contractor tasks
Contracting techniques
Contract types
Warranties
Risk Handling Strategies: Assumption
Ensure management $ reserves adequate
Ensure that other resources (human, facilities, etc) are reserved
Entry Criteria:
Can be Produced: AUPC/Uniformity/Performance
LORA Verified
Interfaces Verified
Performance Verified/Performance Growth Acceptable
Design Consideration Analyses Complete & Acceptable
CPM Current & Accurate
TRL 7 Definition: Prototype near, or at, planned operational system. Represents a major step up from TRL 6, requiring demonstration of an actual system prototype in an operational environment such as an aircraft, vehicle, or space. Examples include testing the prototype in a test bed aircraft.
Ref: DAG Chapter , TRL

31. Technical Assessment
Assessment (analysis and normative evaluation) of a particular technical device, system, or procedure with regard to a defined set of criteria, goals or objectives (e.g. technical security assessment according to the standards of the Orange Book).

32. Requirements Management
Requirements Traceability
Requirements Documentation
Requirements Rationale

33. Decision Analysis
Structured way of thinking about how the action taken in a current decision would lead to a result. In doing this, one distinguishes three features of the situation: the decision to be made, the chance and impact of known or unknown events that can affect the result, and the result itself.
Often graphed as a decision tree to display the array of choices and outcomes as nodes and branches.

34. Interface Management
Interface management control measures ensure that all internal and external interface requirement changes are properly documented in accordance with the configuration management plan and communicated to all affected configuration items.

35. Data Management
The discipline which embraces the verification, coordination, validation, integration, and control of data requirements; planning for the timely and economical acquisition of data; and management of data assets after receipt. This discipline also includes monitoring distribution of data required under contract and storage, retrieval, and disposal of these data.

36. Configuration Management
Configuration Identification:
Configuration Items
Configuration Documentation
Configuration Baselines
Program Unique Specifications
Configuration Control:
Engineering Change Proposals (ECPs)
Request for Deviations (RFDs)
Configuration Control Boards (CCBs)
Functions:
Identification
Control
Status Accounting
Audits
Configuration Status Accounting
• Collecting and recording data
• Disseminating information
Configuration Reviews/Audits
• Systems Verification Review (SVR)
• Physical Configuration Audit (PCA)

37. Takeaways (1 of 2)
DoD acquisition policy defines the SE processes and requires the use of Technical Management Processes.
Good technical processes get people moving in the right direction… Good technical planning gets them doing the right things.
Risk management permeates every aspect of systems engineering management.
The only risks you can not mitigate are the ones you do not see…..

38. Takeaways (2 of 2)
Technical reviews play a key role in assessment of technical maturity, risk reduction, and readiness to proceed to the next level of development.
Technical reviews are the “gates” through which risks must pass to get into the next phase…… Control what risks you allow through or you may end up being controlled by them.