1. Session 10 Dr. Dan C. Surber, ESEP
ME Fall Introduction to Systems Engineering
Session 10
Dr. Dan C. Surber, ESEP
© Copyright 2013

2. Master Compliance Matrix
Maps the decomposed requirements and functions to their allocations in the physical architecture and across to their verification events & status.
Assumes traceability & baseline configuration control are implemented.
Maps requirements to verification methods to test cases to test procedures.

3. MCM Example System Level Subsystem Level Product (CI) Level PUI Insp
Anal
Demo
Test
M/S
QbS
System Level
PUI
Insp
Anal
Demo
Test
M/S
QbS
Subsystem Level
PUI
Insp
Anal
Demo
Test
M/S
QbS
Product (CI) Level

4. Test Plan, Case, Procedure
TEMP
Test Plan laid out the “big picture”
Test cases
describe HOW capabilities & requirements are proven, under what conditions
5 “W”s
Who
What
When
Where
Why
And ‘H’ow
Test Procedure
Step by step methodology to Pass/Fail the requirements
Use the verification methods prescribed by the RVM
Software
SYSTEM
Data
Facilities
Tools &
STE
Training &
Tech Data
System
Specification
Subsystem
Specification
Product
Specification
Config Item
Specification
SYS
module
SuS-1
SuS-2
SuS-3
SuS-4
Prod-1
Prod-2
Prod-3
Comp-2
Comp-1
Test Case Description Documents
Component
Specification
Test Case 002
Test Case 003
Test Case 001
Test
Procedure-01
Test
Procedure-01
Test
Procedure-01
Test
Procedure-02
Test
Procedure-02
Test
Procedure-02

5. Test Procedure Requirements that are verified
Steps to follow, given that the “setup” conditions described in the Test CASE are done
Note the steps where PASS/FAIL criteria are assessed
Ensure data files are captured, labeled, controlled
Follow post-test data reduction & analysis

6. Definitions VALIDATION1 VERIFICATION VALIDATION2
Are these the right requirements?
Set scope & bound the problem
Operational Suitability & Effectiveness
VERIFICATION
Does the design satisfy the requirements on the basis of the methods used & results?
I, A, D, T, QbyS
Did we build it right?
VALIDATION2
Did we build the right system?
Assessed under operational conditions by trained users and maintainers with tools & tech data.

7. Functional Analysis Requirements Analysis Functional Analysis Mission
Interface
Analysis
Requirements
Development
Functional
Flow
Analysis
Mission
Event
Timelines
Interface
Decomposition
Requirements
Allocation To
Functions
Mission
Phases
Interface
Allocation
Reqmt-Functn
Allocation To
Architecture
Repeat @
Lower
Architecture

8. Requirements to Design
Analysis
Functional
Analysis
Mission
Analysis
Interface
Analysis
Requirements
Development
Functional
Flow
Analysis
Mission
Event
Timelines
Interface
Decomposition
Requirements
Allocation To
Functions
Mission
Phases
Interface
Allocation
Reqmt-Functn
Allocation To
Architecture
Repeat @
Lower
Architecture

9. Requirements Analysis
RA = understanding the sources of requirements
Market & regulatory constraints
Mission threads for the system
Environments encountered by the system
System specification may list sources
Standards
Specifications
System requirements
Interfaces
Design Constraints
Functional Analysis

10. Requirements Allocation
Weight Allocation
FBD & Mission Event Timelines
Total System
WEIGHT
< 5 K lbs.
FFBD & Mission Profile (1 – n)
Data Flow & Control Flow
Product #1
WEIGHT
< 1.5 K lbs.
Product #2
WEIGHT
< 2 K lbs.
Product #3
WEIGHT
< 1.5 K lbs.
Interface
Analysis
&
Decomposition
Architecture
Decomposition
Reliability Analysis & Allocation
Life Cycle Cost Analysis
Other Specialty
Engineering
Analyses
Design-to-Cost Cost Allocation

11. Requirements Development
Examine System Level Requirements
Gaps & Conflicts
Direct Flow down, derived flow down
Expand functional analysis
Develop budget allocations
Performance
Error
Constraints (weight, cost, Ao, reliability)

12. Requirements Tracing System Level = “Parent” Subsystem Level = “Child”
Product (Configuration Item) = “Grand child”
Component (portion of a CI) = “Great grand child”
Assy, subassy, or part = “Great, great grand child”

13. Requirements Allocation & Traceability
Comp-1
module
System Spec
SuS-1
module
Comp-2
module
Subsystem Spec
Subsystem Spec
SuS-2
module
Comp-2
module
Subsystem Spec
Subsystem Spec
SYS
module
SuS-3
module
Prod-1
module
Product Spec
Product Spec
SuS-4
module
Prod-2
module
Product Spec
Prod-3
module
Component Spec
Component Spec
Component Spec

14. Budgets Performance requirements may need budgets
Direct allocations of physical property may be solely allocated to an entity
Derived requirements stem from analysis & trades needed to satisfy higher levels
Budgets are “rolled up” to their summary level: system, subsystem, product, or CI

15. Interface Analysis Context diagram N2 matrix Data flow diagram
Figure 3.12
Figures A.2, A.3 and A.4
Schematic block diagram
Architecture Block Diagram

16. CONTEXT DIAGRAM Environ. System A System of Interest Support Mission
SOI
Users
System B

17. N2 Diagram Example

18. N2 Diagram F1 Measure Voltage F2 Convert Voltage to Degree
F3 Pass Reading to Output
F4 Report Data F1
-> F2 F2
-> F3 F3
-> F4 F4 F3 F4

19. Schematic Block Diagram
ENVIRONMENTS
External #2
External #32
External #1
Component 1 2
Subsystem 1
Subsystem 2
Segment 1
Component 1 2
Subsystem 1
Segment 2
System of Interest

20. Architecture Block Diagram (ABD)
Software
SYSTEM
Data
Facilities
Tools &
STE
Training &
Tech Data
Hardware
What goes underneath each of these boxes – and WHY?

21. Commercial Tools DOORS SLATE CORE by VITECH CRADLE by 3SL
TEAMCENTER by UGS/SIEMENS
Integrated Project Lifecycle Management (PLM) suite
UML 2.0 based OOA & OOD tools
SysML extended UML modeling tools
Search “system modeling software”