The Engineering Design of Systems Models and Methods

The Engineering Design of Systems: Models and Methods Buede Chapter 2 – Slide 5+ Overview of the Systems Engineering Design Process Buede Chapter 3 – Slide 38+ Modeling and Process Modeling 2 -SE 1

Traditional “System” Model at Start of High-level Design • Step 1 – It’s a “cloud” – Which does stuff for external users or systems: – We talk about its role in regard to that outside world. – What does it “do”? 2 -SE 2

Then we carve-up the cloud • What top-down design would make all that happen? • How would those parts of the cloud have to interact? 2 -SE 3

At some point, bottom-up design starts to seep in • Then it takes over for real, saying what the components “have to be”… 2 -SE 4

Buede’s Big Picture Functional Architecture Operational Architecture Physical Architecture Derived Requirements and Flowdown State Transition Diagram Interfaces Risk Analysis and Documentation 2 -SE 5

Ch. 2 - Key Systems Terms see figure 2. 1 • System – set of components acting together (SOI – system of interest) • System’s External systems – set of entities that interact via the external interfaces. • System’s Context – set of entities that can impact but not be impacted by the system. 2 -SE 6

System/External Systems/Context External Systems Diagram Captures this Viewpoint 2 -SE 8

Some Key Concepts • System’s inputs come from external systems or context. • All of system’s outputs flow to external systems. Play a role in establishing requirements 2 -SE 9

Buede’s Observation • The design process, as presented, is not a ‘formal’ process. – Success and correctness cannot be proven or guaranteed. 2 -SE 10

Six Main Steps of Design Process 1. Define the system level design problem. a. Develop operational concept b. Define system boundary and external systems diagram c. Develop system objectives hierarchy d. Develop, analyze, and refine requirements e. Ensure requirements feasibility f. Define test system requirements g. Obtain approval of system documentation 2 -SE As in, a short “problem statement”! 11

Six Main Steps of Design Process 1. Define the system level design problem. 2. Develop the system functional architecture 3. Develop the system physical architecture 4. Develop the system operational architecture 5. Develop the interface architecture 6. Define the qualification system 2 -SE 12

This may appear to be a linear, sequential process…. . • But it’s not. • Consider qualification early on, look ahead, look back, revise and refine. 2 -SE 14

More Concepts and Terminology (Section 2. 3) • ‘Operational Concept’ 1. Vision of the system – general terms 2. Mission requirements, How used 3. Set of operating scenarios 2 -SE 15

Elevator Operational Concept See hand-out 1. Vision • Product and market background 2. Mission • Performance objectives 3. Operational Phase Scenarios • Text and ‘input/output trace’ summaries of scenarios 2 -SE 16

Operating Scenario • In Systematica – ‘Functional Interactions’ between systems. – A collection of ‘Interactions’ becomes a ‘Feature’. – ‘Interactions’ happen in a state of the State Diagram. See Elevator Handout Input/Output Trace 2 -SE 17

External Systems Diagram (ESD) • Defines the ‘boundary’ of our system • Where it starts and ends • Consistent with Operational Concept • Developed from the Operating Scenarios • Figure 2. 2 – Elevator Example. Sometimes called : Domain or Context diagram 2 -SE 18

Elevator System ESD Figure 2. 3 – IDEF 0 modeling 2 -SE 19

Elevator Example Comments • Two slightly different versions of it – One in book & author’s PPT slides. – One better and more detailed provided as a case study. 2 -SE 20

External Systems & Context 2 -SE Figure 2. 1 21

Create a Graphical Model for the ESD • Integrated Definition for Functional Modeling – IDEF 0. • Detailed in Chapter 3. – Boxes – functions, verb phrases – ICOM – inputs, controls, output, mechanisms. 2 -SE 22

Objectives Hierarchy • Hierarchical representation of major performance, cost, and schedule attributes. • Define stakeholder satisfaction. 2 -SE 23

Requirements • Define operational requirements – what we want the system to accept, do, and be. • Several approaches to Requirements – Ch. 6 • “Old school” - Carefully constructed written statements. • “Agile” – User stories, etc. 2 -SE 24

Levels of Requirements Stakeholder Requirements Use our engineering skills and talents to create, develop, design Figure 6. 1 “CI’s” are “System Configuration Items” 25

Two levels of Requirements: Originating and System • Originating • System – Translation of originating into engineering terms. • (Shareholder) – Stakeholders agree with these. – Weight, speed, distance. – Written in English. 2 -SE 26

Four Categories of Requirements • Input/Output – Inputs, outputs, external interfaces, functional requirements. – Really important for describing system behavior • Technology and System Wide – ‘Technology’ in the system – ‘Ilities’ of the system – Cost, schedule 2 -SE 27

Categories of Requirements • Trade-off Requirements – Performance, cost – Cost/performance – Algorithms to enable • System Qualification – How to obtain test data – Data used for design = real system – Data used for real system = originating reqs. – Data used for real system = stakeholders wants 2 -SE 28

Function • Process that changes inputs into outputs. • Describes ‘what’ not ‘how’ Noun Verb Noun • Top level – single function • Sub-functions below 2 -SE 29

Interfaces are critical • Connection resource • ‘Hook together’ components and external systems. • Interfaces have inputs, outputs, perform functions. • May be software, hardware, mechanical, electrical, etc. 2 -SE 30

Qualification Verify/Validate/Accept • Qualification – means ‘test’ and an umbrella term for V&V • Verification – was system built right. • Validation – was right system built (meets scenarios and requirements). • Acceptance – stakeholders feel system meets their needs, acceptable. 2 -SE 31

The Big Picture Functional Architecture Operational Architecture Physical Architecture Derived Requirements and Flowdown State Transition Diagram Interfaces Risk Analysis and Documentation 2 -SE 32

The Big Picture 2 -SE 33

This seems complicated – what about software tools ? • Buede suggests CORE Software • Many systems engineering software tools available. • Issues – learning curve, power, detail, flexibility, terminology, automation, etc. 2 -SE 34

Let’s keep it simple • Microsoft Word, Excel, Visio 2 -SE 35

Visio or similar software? • Multipurpose drawing/flowcharting package. • Shape oriented concept. • A good tool for engineers. • You should be able to get Visio (for MS) on Rose’s Banner site (= MSDNAA). 2 -SE 36

Visio Demonstration? • Overview of basic features. • Shape stencils • Drag and drop shapes • Edit shape properties • Text • Tools : Alignment, Group, Rotate, etc. • Pages 2 -SE 37

Ch. 3 – Modeling and IDEF 0 • Models are abstractions of reality…. • Modeling languages – – Semantics – symbols, signs. – Syntax – rules for combining symbols. • Process models – input/function/output. • IDEF 0 and others in Ch. 12. 2 -SE 38

External Systems & Context 2 -SE Figure 2. 1 39

MBSE • We will be learning ‘Model Based Systems Engineering’ (MBSE) • Building graphical models to depict system structure and behavior. • Far less dependent on volumes of written requirements. 2 -SE 40

Pattern Based Systems Engineering - PBSE 2 -SE 41

Models • Models are an abstraction…. • The essence of a model is the set of questions that the model can answer for us. 2 -SE 42

The Truth About Models • Models are – – Incomplete, – Inaccurate, – Simplified, – Etc. All models are wrong, but some are useful. (George Box) 2 -SE 43

Software’s love/hate thing with models • To agile people – just one more thing not to do if you don’t have to • To organizations with a well-defined way to convert requirements to models, etc. – the only way to go! (E. g. , the Rational process. ) • To organizations without that, doing one more routine project – something we wish we could try! • To organizations who are now facing a new kind of project – a dream / something new to try, if we have time! 2 -SE 44

Types of Models • Physical – Mock-ups, – Scale models, – Prototypes, – Breadboards. • Questions: how much, visualization, scenario testing. 2 -SE 45

Types of Models - 2 • Quantitative – Analytic, – Empirical, – Simulation – Static/dynamic, deterministic/stochastic. • Questions: How much, often, good, etc. 2 -SE 46

Types of Models - 3 • Qualitative – Symbolic, – Text, – Graphic • Questions : what needs to be done, what order, etc. 2 -SE 47

Types of Models - 4 • Mental – Abstractions of thought. – Highly useful, but hard to communicate. – We use in interaction design – • “What’s the user think this is? ” 2 -SE 48

Potential Uses of Models 1. Create, specify, communicate, and test a shared vision. 2. Estimation and prediction of qualitative measures. 3. Selection of one option over another. Buede text emphasizes qualitative modeling. 2 -SE 49

The SE Design Strategy • The ‘Onion’ concept • Primarily top-down • High level of Abstraction – Proceeding to • More and more detail and definition • Decomposition or 2 -SE modular approach 50

The SE Design Strategy 2 -SE 51

IDEF 0 Modeling • Section 3. 3 – visit www. idef. com – Lots of examples • Function box – Verb phrase, number. • Flow of material or data or information. • A-0 is the ‘ESD/context diagram’. • A 0 is the top level function. • Decomposition 2 -SE 52

IDEF 0 Page Structure Page Number(s) A-1 A-0 A 1, A 2, . . . A 11, A 12, . . . , A 21, . . . Figure 3. 5; Table 3. 2 Page Content Ancestor or external system diagram Context or system function diagram (contains A 0) Level 0 diagram with first tier functions specified Level 1 diagrams with second tier functions specified Level 2 diagrams with third tier functions specified 2 -SE … 53

Wasson Decomposition Notations 2 -SE 54

The IDEF 0 Model • Answers definitive questions about the transformation of inputs into outputs by the system • Establishes the boundary of the system on the context page. • Has one viewpoint; the viewpoint is the vantage or perspective from which the system is observed. • Can create a coordinated set of diagrams, using both a graphical language and natural language. 2 -SE 55

IDEF 0 – 2 • ICOM – inputs, controls, outputs, mechanisms. C • Not a sequence of activities – (a I functional model, not a behavioral one). 2 -SE O M 56

IDEF 0 Rules & Guidelines • Rules – Conservation of inputs, controls, outputs & mechanisms – Every function has a control and output • Input vs. Control – which is it? – Inputs – transformed or consumed. – Controls – information, conditions, or instructions that guide the functional process. 2 -SE 57

IDEF 0 Rules & Guidelines • Guidelines – 3 to 6 functions per page arranged diagonally – Control-oriented functions placed at top left – Major output functions placed on bottom right – Arcs & functions are decomposable – Feedback is defined by arcs moving from bottom right to top left 2 -SE 58

Feedback Semantics of Functions Figure 3. 4 2 -SE 60

IDEF 0 Functional Decomposition 2 -SE Figure 3. 6 61

Elevator External Systems Diagram From the Elevator Case Write Up 2 -SE 62 Slightly different from book figures….

Elevator System Function 2 -SE Top level system function 63

Elevator Functional Decomposition 2 -SE First level decomposition 64

Getting the ESD Right • The ESD must capture the fundamental functional activity of the system being modeled. • It’s how “the system as a cloud” interacts with the external world. 2 -SE 65

Problems • Develop an external systems diagram for an ATM machine (scenario on next page) • Class exercise? Or after class… – Develop a scenario or two and an ‘external systems diagram’ for a common system. – Develop a scenario or two and an ‘external systems diagram’ for your design problem. 2 -SE 66

2 -SE 67