2. Design1 Agenda for design activity r1. Objective r2. Disclaimer r3. Solutions r4. Design process r5. Other design processes

2. Design2 1. Objective rDesign activity rDesign tasks rCompletion criteria rPseudo-completion criteria 1. Objective

2. Design3 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

2. Design4 Design process 1. Objective customers Create idea Define lower specs & I/Fs CRPDRCDR spec & I/Fs other stakeholders developers enterprise users design lower specs & I/Fs reviews Document design Complete design Define additional wants List lower products

2. Design5 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

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

2. Design7 PBDA block diagram 1. Manage 2. Understand req 3. Design 4. Acquire 5. Build 6. Verify 7. Sell off External: higher product teams External: lower product teams contracts, specs, interfaces specs, I/Fs contracts lower specs & I/Fs design lower contracts, specs, interfaces status lower product, test results, test spec agree lower test results lower products build proc product test proc test results test spec people facilities, tools, capital, communications, library schedule, budget, risks, TPPs, issues, AIs, problems plans, timeline, changes, legal control, status agree status MR RR CRPDRCDR TRRVR FCAPCA

2. Design8 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

2. Design9 3. Solutions rDesign as a set of solutions rSolution process rGenerating solutions 3. Solutions

2. Design10 Design as a set of solutions design lower specs & I/Fs spec & I/Fs reviews design process 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 3. Solutions

2. Design11 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 3. Solutions implement solution implemented solution knowledge to generate solutions models & analysis knowledge to choose solution criteria models & analysis

2. Design12 Solution process (2 of 7) r Problem definition l Collect and understand printed information Similar designs and lessons learned Design guides Literature l Talk with people who know the problem Customers Consultants l Look at problem in person l Confirm information l Determine what caused the problem l Determine if problem should be solved 3. Solutions

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

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

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

2. Design16 Solution process (6 of 7) rImplement solution l Plan l Execute l Gather additional information; e.g. observation and experiments 3. Solutions

2. Design17 Solution process (7 of 7) rEvaluate solution l Validate by analysis l Model 3. Solutions

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

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

2. Design20 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 3. Solutions customer design

2. Design21 4. 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 4. Design process

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

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

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

2. Design25 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 4. Design process satisfy other features satisfy potential requirements functional viewpoint requirements viewpoint make product work make-work viewpoint

2. Design26 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 4. Design process

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

2. Design28 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 4. Design process

2. Design29 B. Define additional wants (6 of 6) make product work turn on & offinitializeload test reconfigure provide structure provide powerheat & cool Satisfying make-work wants 4. Design process

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

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

2. Design32 D. Complete design (1 of 3) rDefinition l The process of completing design to point some else can build rApproach l Use solution process l Make system meet requirements l Make system meet additional wants l Include architecture and other drawings rCompletion criteria l Has completed to the point that someone else can acquire lower-products, build, test, and sell off the product 4. Design process

2. Design33 D. Complete design (2 of 3) 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 4. Design process

2. Design34 D. Complete design (3 of 3) 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 4. Design process

2. Design35 E. Define lower specs and I/Fs (1 of 6) rDefinition l Lower specs -- The specs defining the parts from which the product is to be made l 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 4. Design process

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

2. Design37 E. Define lower specs and I/Fs (3 of 6) rValue of lower specs and interfaces l 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 4. Design process

2. Design38 E. Define lower specs and I/Fs (4 of 6) 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 4. Design process

2. Design39 Flow down E. Define lower specs and I/Fs (5 of 6) Level N Design Level N Spec Pseudo customers Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N+1 Interfaces Level N+1 Test Equip 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 4. Design process

2. Design40 E. Define lower specs and I/Fs (6 of 6) rInterface development technique l 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 l Define interfaces among sub-products to ensure each sub-product receives information and has physical support to operate rDocumenting interfaces l Excel spreadsheet l Data bases; e.g. TeamWork 4. Design process

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

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

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

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

2. Design45 G. Document design (1 of 6) rDefinition l 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 l Capture configured design as shown in following figures rCompletion criteria l Documented to procure the parts, build the product, justify why the design is as it is, and support analysis 4. Design process

2. Design46 design G. Document design (2 of 6) 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 4. Design process

2. Design47 G. Document design (3 of 6) 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 4. Design process

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

2. Design49 G. Document design (5 of 6) 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 4. Design process

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

2. Design51 5. Other design approaches rDSMC rJames Martin rEIA 632 rJames Garratt rPBDA 5. Other design approaches

2. Design52 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) 5. Other design approaches System analysis& control

2. Design53 design process James Martin requirements analysis functional analysis and allocation synthesis requirements and architecture documentation system analysis and optimizationspecs, interfaces, design requirements product characteristics Design loop Verification loop Requirements loop 5. Other design approaches

2. Design54 User or customer requirements Other stakeholder requirements System technical requirements Design solution Logical solution Assigned requirements Specified requirements Physical solution EIA 632 Derived technical requirements 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. A. Requirements relationship ASSIGNED TO 5. Other design approaches

2. Design55 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 5. Other design approaches

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