2. Systems Engineering Process Models Chris Wallace CPDA D6: Systems Engineering June 2005

3. 2

4. 3

5. 4 ISO 15288 processes

6. 5 5.4.2 Requirements Analysis Process Purpose –.. to transform the stakeholder, requirements-driven view of desired system services into a technical view.. Outcomes –1) the required characteristics, attributes, and functional and behavioural requirements for architectural design of a product solution are specified… –2-4 Activities –1. Define the functional boundary of the system in terms of acceptable organisational policies and procedures with respect to the Requirements Analysis process –2-8 < 2 pages in total

7. 6 ISO 15288 Example Lifecycle

8. 7 Alternative process models Contrasting process models –(links on web site) –ISO 15288 –The CADMIT process (MOD) –Boehm’s Spiral risk-driven model (Future Combat systems) –Agile Modelling and XP (Object-oriented Software)

9. 8

10. 9 Spiral Model and Theory W negotiation techniques are the most critical success factor in improving the outcome of software projects. The USC Center for Software Engineering has been developing a negotiation-based approach to software system requirements engineering, architecture, development, and management. Components of the approach are: –Theory W, a management theory and approach, which says that making winners of the system's key stakeholders is a necessary and sufficient condition for project success. –The WinWin spiral model, which extends the spiral software development model by adding Theory W activities to the front of each cycle. –WinWin, a groupware tool that makes it easier for distributed stakeholders to negotiate mutually satisfactory (win-win) system specifications. the WinWin spiral model is a good match for multimedia applications and is likely to be useful for other applications with similar characteristics--rapidly moving technology, many candidate approaches, little user or developer experience with similar systems, and the need for rapid completion.

11. 10 Some Basic Design ideas Christopher Alexander –Mathematician from Cambridge turned design theorist then community architect and philosopher at Berkeley Engineering approach to deducing a system architecture Representation of design knowledge as Patterns “every design problem begins with an effort to achieve fitness between two entities: the form in question and its context. The form is the solution to the problem; the context defines the problem... The real object of discussion is not the form alone but the ensemble comprising the form and its context” “the form is a part of the world over which we have control, and which we decide to shape while leaving the rest of the world as it is. The context is that part of the world which puts demands on this form.. Fitness is the relation of mutual acceptability between these two..”

12. 11 Form / Context / Ensemble Context (Alexander) Form (Alexander) Context System S1 (Martin) Intervention System S2 (Martin) Ensemble (Alexander) Fitness (Alexander) System of Interest (ISO 15288)

13. Real Mental Formal 3 Realms

14. 13 Context-R Context-M Context-F Form-R Form-M Form-F Real Mental Formal Fitness-R Fitness-F Alexander’s model of design

15. 14 Classic staged process The core design task The basic staged model of development Validation and verification – the V Model Traceability Bridging the gap

16. 15 Fitness-F Requirements Constraints Concept of Operations Use cases and Scenarios Domain Theories Knowledge of materials processes mechanisms existing forms including COTS Architecture Models Context-F Goals Form-F Trade studies Specifications Design

17. 16 Context-R Context-M Context-F Form-R Form-M Form-F Real Mental Formal Staged Development

18. 17 Context-R Context-M Context-F Form-R Form-M Form-F Real Mental Formal Verification Validation Validation and Verification

19. 18 Context-R Context-M Context-F Form-R Form-M Form-F Real Mental Formal Traceability Impact analysisDerivation analysis Choose Fx for Cy because … Design rationale Coverage Analysis

20. 19 Context-R Context-M Stakeholder Requirements Form-R Form-M Architectural Design Real Mental Formal System requirements Intermediate Stages

21. 20 Concurrent models Concurrency arises from –Hierarchical decomposition –Product lifecycle –Multiple contexts and forms

22. 21 Hierarchy Context / Form distinction is relative: Form at one level becomes (part of) the Context for sub-forms ISO 15288

23. 22

24. 23 Form-M Context-R Context-M Form-R Real Mental Formal Form decomposition P-R1P-R2 P-F1P-F2P-F3 P-R3 P-M1P-M2P-M3 Context-FForm-F

25. 24 Context-R Manufacture Test Repair Multiple lifecycle contexts Context-R Disposal Use Training Form-R

26. 25 Multiple Contexts and Forms The context comprises multiple, nested interacting ‘systems’ arbitrarily bounded The form comprises not just system-of-interest but also support systems, training, documentation, servicing tools… Context-Rc Form-R Context-RcContext-R Form-R

27. 26 Design for X 1 Design for assembly Design for disassembly Design for ease of use Design for EMC (ElectroMagnetic Compatibility) Design for installation Design for maintenance Design for validation Design for manufacture Design for quality Design for reliability Design for reuse Design for speed Design for cost Design for environment 1. www.betterproductdesign.net/guide/design4X.htm

28. 27

29. 28 Complications Dynamics –The role of human cognition, social behaviour and culture –Context is not fixed –Fitness is dynamic Form/Context separation is a myth Learning and feedback process models

30. 29 Context-M Context-R Context-M Context-F Form-R Form-M Form-F Real Mental Formal Human cognition in the system

31. 30 Context-R Context-M Context-F Form-R Form-M Form-F Real Mental Formal Context is autonomous and dynamic Context-FForm-F Context-FForm-F

32. 31 Context-R Context-M Context-F Form-R Form-M Form-F Real Mental Formal Fitness is dynamic