1. 2-SE1 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. 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

3. 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

4. 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

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

6. 2-SE6 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.

7. 2-SE7 System/External Systems/Context External Systems Diagram Captures this Viewpoint

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

9. 2-SE9 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

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

11. 2-SE11 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 As in, a short “problem statement”!

12. 2-SE12 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

13. 2-SE13 Functions of Integration and Qualification Process Second half of Vee Model – Four steps 1.Conduct early validation 2.Conduct integration and verification testing 3.Conduct system validation testing 4.Conduct system acceptance testing

14. 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-SE14

15. 2-SE15 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

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

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

18. 2-SE18 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

19. 2-SE19 Elevator System ESD Figure 2.3 – IDEF0 modeling

20. 2-SE20 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.

21. 2-SE21 External Systems & Context Figure 2.1

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

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

24. 2-SE24 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.

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

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

27. 2-SE27 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

28. 2-SE28 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

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

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

31. 2-SE31 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.

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

33. 2-SE33 The Big Picture

34. 2-SE34 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.

35. Let’s keep it simple Microsoft Word, Excel, Visio 2-SE35

36. 2-SE36 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).

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

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

39. 2-SE39 External Systems & Context Figure 2.1

40. 2-SE40 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.

41. 2-SE41 Pattern Based Systems Engineering - PBSE

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

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

44. 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-SE44

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

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

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

48. 2-SE48 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?”

49. 2-SE49 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.

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

51. 2-SE51 The SE Design Strategy

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

53. 2-SE53 IDEF0 Page Structure Page Number(s)Page Content A - 1Ancestor or external system diagram A - 0Context or system function diagram (contains A0) A0Level 0 diagram with first tier functions specified A1, A2,...Level 1 diagrams with second tier functions specified A11, A12,..., A21,... Level 2 diagrams with third tier functions specified...… Figure 3.5; Table 3.2

54. Wasson Decomposition Notations 2-SE54

55. 2-SE55 The IDEF0 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.

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

57. 2-SE57 IDEF0 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.

58. 2-SE58 IDEF0 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

59. 2-SE59 Arrow Semantics Figure 3.3

60. 2-SE60 Feedback Semantics of Functions Figure 3.4

61. 2-SE61 IDEF0 Functional Decomposition Figure 3.6

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

63. 2-SE63 Elevator System Function Top level system function

64. 2-SE64 Elevator Functional Decomposition First level decomposition

65. 2-SE65 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.

66. 2-SE66 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.

67. 2-SE67