1. 1 Agenda for design activity r1. Objective r2. Disclaimer r3. Design context r4. Solutions r5. Design process r6. Other design processes

2. 2 1. Objective rDesign activity rDesign process rCompletion criteria rPseudo-completion criteria rProducts composed of products 1. Objective

3. 3 Design activity rThe design activity produces a vision of the product is to be built and specifies the lower products from which the product is to be constructed rIn other words, the design activity starts with a problem and creates a vision of the solution to that problem rThe design is a description of the parts and how the parts go together rDesign works for physical products, documents, and processes 1. Objective

4. 4 Design process 1. Objective customers create idea define lower specs & I/Fs CRPDRCDR spec & I/Fs other stakeholders developers enterprise users design reviews document design complete design define additional wants list lower products

5. 5 Completion criteria rWorks rMeets requirements rHas consensus that design is done rIs documented to the point that someone else can acquire lower-products, build, test, and sell off the product 1. Objective

6. 6 Pseudo-completion criteria rCritical design review is complete 1. Objective

7. 7 Products composed of products level 1 product level 2 product 1 level 2 product 2 level 3 Product 1 level 3 Product 2 level 4 product 2 Higher-level products Lower-level products level 4 product 1 level 4 product 2 1. Objective

8. 8 2. Disclaimer Design is difficult to describe as a process because details depend upon the nature of the product, and there’s a wide variety of products. Design is difficult to describe as a process because details depend upon the nature of the product, and there’s a wide variety of products. house telephone radio car airplane 2. Disclaimer

9. 9 3. Design context rContext rDesign vs requirements rOther customers rFlow down rStudies 3. Design context

10. 10 Context level N spec level N+1 spec 1 level N+1 spec 2 level N+1 spec M level N design level N+2 spec 1 level N+2 spec 2 level N+2 spec P level N+1 design 2 level N+1 design 1 level N+1 design M Design occurs at each level and produces lower specs. 3. Design context

11. 11 Design vs requirements level N spec level N+1 spec 1 level N+1 spec 2 level N+1 spec M level N design Design at level N becomes requirements at level N+1 Requirements as seen by level N+1 Design as seen by level N 3. Design context

12. 12 Other customers level N spec level N+1 spec 1 level N+1 spec 2 level N+1 spec M level N design In addition to higher-level requirements, pseudo customers guide design In addition to higher-level requirements, pseudo customers guide design other customers 3. Design context

13. 13 Lower specs and interfaces product design product requirements requirement Lower specs and interfaces evolve from design and impose requirements on products at the same level in the hierarchy. Lower specs and interfaces evolve from design and impose requirements on products at the same level in the hierarchy. lower product B requirements requirements lower product A requirements requirements interface requirements 3. Design context

14. 14 Flow down level N design other customers level N+1 s 1 level N+1 spec 2 level N+1 spec M level N+1 Interfaces level N+1 STE contracts Flow down from requirements to design to lower specs, interfaces, and contracts Flow down from requirements to design to lower specs, interfaces, and contracts level N spec 3. Design context

15. 15 Studies design spec lower spec 1 lower spec 2 design study verification Design studies used to expand requirements or to handle requirements verified by analysis need to be captured for use in verification by analysis, verification, and FCA Design studies used to expand requirements or to handle requirements verified by analysis need to be captured for use in verification by analysis, verification, and FCA capture configuration management verification by analysis FCA 3. Design context

16. 16 4. Solutions rDesign as a set of solutions rSolution process rGenerating solutions 4. Solutions

17. 17 design process Design as a set of solutions design lower specs & I/Fs spec & I/Fs reviews solution works meets requirements has consensus that design is done is documented The design process converts inputs into outputs by making a set of solutions The design process converts inputs into outputs by making a set of solutions Completion criteria 4. Solutions

18. 18 Solution process (1 of 7) problem generate solutions choose solution evaluate solution define problem quantify solutions Solutions can be created for problems using any one of several paths Solutions can be created for problems using any one of several paths 4. Solutions implement solution implemented solution knowledge to generate solutions models & analysis knowledge to choose solution criteria models & analysis

19. 19 Solution process (2 of 7) r Problem definition Collect and understand printed information Similar designs and lessons learned, design guides, literature Talk with people who know the problem Customers and consultants Look at problem in person Confirm information Determine what caused the problem Determine if problem should be solved 4. Solutions

20. 20 Solution process (3 of 7) r Generate solutions Ad hoc Analogy or prior experience Research Brainstorming Analysis Graphical modeling Mathematical modeling Physical modeling Prototyping 4. Solutions

21. 21 Solution process (4 of 7) rQuantify solutions Add numerical values to attributes that describe each solution 4. Solutions

22. 22 Solution process (5 of 7) rChoose solution Ad hoc Trade study Define must-have criteria Define want criteria Define adverse consequences and risk- mitigation strategies Perform trade study 4. Solutions

23. 23 Solution process (6 of 7) rImplement solution Plan Execute Gather additional information; e.g. observation and experiments 4. Solutions

24. 24 Solution process (7 of 7) rEvaluate solution Validate by analysis Model 4. Solutions

25. 25 Generating solutions (1 of 3) rDesign is like working a cross-word puzzle A cross-word puzzle can be described as an orderly process of incrementing through the rows and then through the columns In practice, a cross-word puzzle is a lot more random Solutions are not created serially, and they are not created independently Many solutions may proceed in parallel Design is like a cross-word puzzle. No single solution path applies to all of design 4. Solutions

26. 26 Generating solutions (2 of 3) rDesign can be thought of as a process of zig- zagging back and forth between asking what to do and how to do it 4. Solutions

27. 27 Generating solutions (3 of 3) spec & I/Fs design lower specs & I/Fs reviews problem contractor design contractor There’s a customer design in addition to the contractor design There’s a customer design in addition to the contractor design 4. Solutions customer design

28. 28 5. Design process rA. Create idea rB. Define additional wants rC. Define lower products rD. Complete design rE. Create lower specs and I/Fs rF. Hold reviews rG. Document design 5. Design process

29. 29 A. Create idea (1 of 2) rDefinition The portion of the design that gives general direction to the design Not a separate work product (WP) rApproach Use the solution process to generate ideas rCompletion criteria Has obtained enough detail to give general direction 5. Design process

30. 30 A. Create idea (2 of 2) rExample Problem Move a person between two floors of a building Basic ideas Elevator Escalator Chair-lift Hoist Donkey Movable floors Helicopter 5. Design process

31. 31 B. Define additional wants (1 of 6) rDefinition The process of identifying functions and non-functions in addition to ones implied by the product requirements rApproach Use the solution process to define functional and non-functional wants in addition to requirements rCompletion criteria Has obtained consensus among design team that wants are defined 5. Design process

32. 32 B. Define additional wants (2 of 6) Defining additions wants involves looking from different viewpoints Defining additions wants involves looking from different viewpoints satisfy non- functional wants satisfy functional wants 5. Design process satisfy other features satisfy potential requirements functional viewpoint requirements viewpoint make product work make-work viewpoint

33. 33 B. Define additional wants (3 of 6) Satisfying functional wants satisfy functional wants make buildable make verifiable make trainable make usable make supportable make producible make improvable make disposable make maintainable 5. Design process

34. 34 B. Define additional wants (4 of 6) Satisfying non-functional wants satisfy non- functional wants provide quality make profitable make survivable make reliable 5. Design process

35. 35 B. Define additional wants (5 of 6) meet requirements performance electromagnetic radiation workmanship interchangeability safety human factors producibility system security computer resources logistics personnel & training materials, processes, parts transportability environmental conditions availability physical constraints reliability maintainability deployability IFs 5. Design process

36. 36 B. Define additional wants (6 of 6) make product work turn on & off initialize load test reconfigure provide structure provide power heat & cool Satisfying make-work wants 5. Design process

37. 37 C. List lower products (1 of 2) rDefinition The process of listing the lower products to use in the development of the product of interest rApproach Use solution process to partition system rCompletion criteria Has obtained a list of lower products 5. Design process

38. 38 C. List lower products (2 of 2) rChose partitioning criteria Similarity to something done before Customer satisfaction Cost Risk Schedule Performance Reusability and COTS Functional cohesion and uncoupling Other 5. Design process

39. 39 D. Complete design (1 of 4) rDefinition The process of completing design to point some else can build rApproach Use solution process Make system meet requirements Make system meet additional wants Include architecture and other drawings 5. Design process

40. 40 D. Complete design (2 of 4) rCompletion criteria Has completed to the point that someone else can acquire lower- products, build, test, and sell off the product

41. 41 D. Complete design (3 of 4) higher product lower product 2 product of interest lower product 1 lower product N Design of all products, driven by interfaces among the products, proceeds in parallel Design of all products, driven by interfaces among the products, proceeds in parallel Interfaces among products allow designs to proceed in parallel Interfaces among products allow designs to proceed in parallel design 5. Design process

42. 42 D. Complete design (4 of 4) product requirement space lower-product requirement space design space trash Impress customer Improve probability of using COTS May move design to requirements to impress customer. May limit design to improve probability of using COTS May move design to requirements to impress customer. May limit design to improve probability of using COTS 5. Design process

43. 43 E. Define lower specs and I/Fs (1 of 4) rDefinition Lower specs -- The specs defining the parts from which the product is to be made Lower interfaces -- The I/Fs among the parts Interfaces connect products They may be functional or physical They evolve from design and impose requirements on products. Products at the same level in the hierarchy don’t impose requirements on the interfaces at that level unless they are already developed products 5. Design process

44. 44 E. Define lower specs and I/Fs (2 of 4) rApproach Allocate design to lower parts and document rCompletion criteria -- Has defined specs and interfaces defined to point someone else can purchase lower products from an outside vendor 5. Design process

45. 45 E. Define lower specs and I/Fs (3 of4) rValue of lower specs and interfaces Controlling documentation and especially documentation of the lower specs interfaces is one of the strongest influences a product engineer has on the development of a product 5. Design process

46. 46 E. Define lower specs and I/Fs (4 of 4) rInterface development technique Use the results of modeling done to make product work and meet requirements to determine what requirements need to be allocated to each sub-product Define interfaces among sub-products to ensure each sub-product receives information and has physical support to operate rDocumenting interfaces Excel spreadsheet Data bases; e.g. TeamWork 5. Design process

47. 47 F. Hold reviews (1 of 4) rDefinition Reviews of concept, initial design, and final design rApproach Compare against checklist to ensure all design guidelines met rCompletion criteria Checklist satisfied 5. Design process

48. 48 F. Hold reviews (2 of 4) r1. Concept review (CR) Performed when concept is established Objective -- design is feasible and an and list of lower products exists that can be used for management planning and costing Determines Design feasible Design is adequate for management and costing 5. Design process

49. 49 F. Hold reviews (3 of 4) r2. Preliminary design review (PDR) Performed when approach is established Objective -- design headed in right direction Determines Approach will work Designers understand customer & requirements Top-level diagrams available Theory of operation understood Design covers all program phases Risk 5. Design process

50. 50 F. Hold review (4 of 4) r3. Critical design review (CDR) Performed when product is ready for build Objective -- design complete Determines Design covers all program phases Risk Design can be tested Lower products & I/Fs specified and compatible 5. Design process

51. 51 G. Document design (1 of 5) rDefinition The documentation necessary to build to procure the parts, build the product, justify why the design is as it is, and support verification by analysis rApproach Capture configured design as shown in following figures rCompletion criteria Documented to procure, build, justify, and analize 5. Design process

52. 52 G. Document design (2 of 5) design description supporting analysis management including tracing Design is documented as (1) design description, (2) supporting analysis, and (3) management including tracing Design is documented as (1) design description, (2) supporting analysis, and (3) management including tracing 5. Design process design

53. 53 G. Document design (3 of 5) design description The (1) idea and (2) lower specs and interfaces are elements of the design description The (1) idea and (2) lower specs and interfaces are elements of the design description lower specs and interfaces idea 5. Design process

54. 54 G. Document design (4 of 5) rNeed for documentation Design (what) Define the design including the lower specs and interfaces Supporting analysis (why) Provide tutorials for the design Manage requirements Support verification by analysis Support verification Support FCA Management (where) Justify the design 5. Design process

55. 55 G. Document design (5 of 5) rSuggestions Control design by controlling documentation Document and maintain design in format of the tool that produced it Make documentation easy to navigate Avoid letting documentation become obsolete Avoid duplication Document so that someone of similar training can implement 5. Design process

56. 56 6. Other design approaches rDSMC rJames Martin rEIA 632 rJames Garratt rPBDA 6. Other design approaches

57. 57 Systems engineering process DSMC requirements analysis functional analysis and allocation synthesis requirements loop design loop verification process inputs process outputs Defense System Management College (DSMC) system analysis& control 6. Other design approaches

58. 58 design process James Martin requirements analysis functional analysis and allocation synthesis requirements and architecture documentation system analysis and optimization specs, interfaces, design requirements product characteristics Design loop Verification loop Requirements loop 6. Other design approaches

59. 59 user or customer requirements other stakeholder requirements system technical requirements design solution logical solution derived technical requirements assigned requirements specified requirements physical solution EIA 632 TRACE TO ASSIGNED TO DRIVES SOURCE OF SPECIFIED BY BECOME The EIA 632 requirements relationship is similar to the PBDA approach but is more complex. The EIA 632 requirements relationship is similar to the PBDA approach but is more complex. requirements relationship ASSIGNED TO 6. Other design approaches

60. 60 James Garratt identify situation analyze the situation write a brief carry out research write a specification work out possible solutions select a preferred solution plan working drawings and plan ahead construct a prototype test and evaluate the design write a report 6. Other design approaches

61. 61 PBDA rSimple rOnly three management objects rParallel process rAllows parallel product development rAllows multiple customers rCan be used to explain other design methods 6. Other design approaches