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

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.

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

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

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

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.

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

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

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

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

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)

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”

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

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

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

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

N2 Diagram Example

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

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

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

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”