1. 5. Design1 Agenda for design activity r1. Tracing requirements r2. Managing requirements r3. Requirements management tools r4. Homework

2. 5. Design2 1. Tracing requirements rTypes of tracing rComplexity of tracing rReasons for tracing rObservations rSuggestions 1. Tracing requirements

3. 5. Design3 Types of tracing (1 of 2) Req Straight through Expansion Focus CreationEnd Design Req Five types of tracing 1. Tracing requirements

4. 5. Design4 Types of tracing (2 of 2) Weight Weight AWeight B Spreadsheet CalculationGraphingNo hazardous material Straight through Expansion FocusCreation End Design Bedroom on east side Instrumentation Design No hazardous material Building supplies Missile An example of each type

5. 5. Design5 Complexity of tracing (1 of 2) Spec rOften used in tracing and tracing Simple tracing flows from spec to spec and doesn’t include tracing to design. It’s the more common practice Simple tracing flows from spec to spec and doesn’t include tracing to design. It’s the more common practice 1. Tracing requirements

6. 5. Design6 Complexity of tracing (2 of 2) Speccontract Stakeholders Design Speccontract Stakeholders Design Speccontract Stakeholders Design I/F Flow through design is more complex and is a less common practice. However, it produces less problems Flow through design is more complex and is a less common practice. However, it produces less problems Design of the higher product Note: Flow within a rectangle or ellipse not shown rMore complex but provides truer tracing picture 1. Tracing requirements

7. 5. Design7 Reasons for tracing (1 of 5) rReason 1: tracing -- Where did requirement get implemented? Less precise linkage criteria than tracing for verification/validation Often done by doing tracing first 1. Tracing requirements

8. 5. Design8 Reasons for tracing (2 of 5) rReason 2: tracing for verification/validation -- What lower requirements are used in verifying/validating higher requirements? Simplest and most repeatable 1. Tracing requirements

9. 5. Design9 Reasons for tracing (3 of 5) rReason 3: tracing for origin -- Where did each requirement come from; why does it exist? more linkages to explain how design creates requirements 1. Tracing requirements

10. 5. Design10 Reasons for tracing (4 of 5) rReason 4: tracing for change impact -- If one requirement changes, what other requirements must change? More linkages to reflect impacts of requirements on each other 1. Tracing requirements

11. 5. Design11 Reasons for tracing (5 of 5) rThe four different reasons for tracing can result in four different sets of linkages 1. Tracing requirements

12. 5. Design12 Observations (1 of 4) rTracing is a best practice Supports verification and validation Makes sure requirements are implemented Prevents unnecessary requirements Shows how changing one requirement changes others Meets customer expectation 1. Tracing requirements

13. 5. Design13 Observations (2 of 4) rTracing is expensive Tracing is complex and expensive; $benefit/$cost > 1? Many believe cost far out weighs the benefit; takes time, diverts resources, degrades engineers, and drives tools Lack of training & rules make trace not repeatable or dependable 1. Tracing requirements

14. 5. Design14 Observations (3 of 4) rThe following rules-of-thumb can cause trouble All requirements must come from somewhere All requirements must go somewhere All requirements shall trace in one direction Tracing shall be from spec to spec and not within a spec Tracing shall not be from spec to design There shall be one “shall” per requirement All requirements shall be individually traced 1. Tracing requirements

15. 5. Design15 Observations (4 of 4) rDesign is an essential part of flowdown and trace rDesign is difficult to capture in requirements management tools rFew people use trace to understand the effect of a requirement change on other requirements 1. Tracing requirements

16. 5. Design16 Suggestion (1 of 3) rSet customer expectations rNegotiate with customer to minimize effort for design and verification rDocument agreements -- in the spec if possible using clarifications, definitions, and examples 1. Tracing requirements

17. 5. Design17 Suggestion (2 of 3) rChoose a type of tracing such as tracing to confirm verification and validation rProvide rules and training rProvide for independent confirmation of tracing 1. Tracing requirements

18. 5. Design18 Suggestion (3 of 3) Req Expansion Focus Design Req Expansion Focus Flow expansion and focus through design -- not directly 1. Tracing requirements

19. 5. Design19 2. Managing requirements rRequirements attributes rData interface attributes rPhysical interface attributes rDocumenting requirements rManaging requirements change 2. Managing requirements

20. 5. Design20 Requirements attributes (1 of 2) rRequirement -- text rTitle -- short text rNumerical identifier -- added by management tool rProduct unique identifier (PUI) -- added by engineers rVerification method -- how requirement verified 2. Managing requirements

21. 5. Design21 Requirements attributes (2 of 2) rOwner -- person responsible for success rStakeholders -- people with an interest rChange history -- change dates rFlowdown/traces -- flowdown and trace links rRationale -- why requirement is the way it is 2. Managing requirements

22. 5. Design22 Data interface attributes rData item rCriteria rTiming rUnits and enumeration rFormat rRanges rAccuracy 2. Managing requirements

23. 5. Design23 Physical interface attributes (1 of 2) rElectrical Signals Power EMI/EMC Grounding 2. Managing requirements

24. 5. Design24 Physical interface attributes (2 of 2) rMechanical Dimensions Mounting Alignment Weight Heating Cooling 2. Managing requirements

25. 5. Design25 Documenting requirements rMedia Paper Office computer tools Data base rFormat Contractor chosen Commercial standard MIL-STD-490A MIL-STD-490B 2. Managing requirements

26. 5. Design26 Managing requirements change rOften handled through configuration management rTechniques Data base Change pages Red-line changes 2. Managing requirements

27. 5. Design27 3. Requirements management tools rINCOSE tools survey rINCOSE tool-selection criteria rTools surveyed by INCOSE rSelection considerations for ease of use rSelection considerations for compatibility rSelection criteria for satisfaction 3. Requirements management tools

28. 5. Design28 INCOSE tools survey rComparison made by National Council on Systems Engineering (INCOSE) rInternet address: http\\www.incose.org/workgrps/tools/req_su rv.htm 3. Requirements management tools

29. 5. Design29 INCOSE tool-selection criteria (1 of 2) r1. Capturing requirements identification r2. Capturing system element structure r3. Requirements flowdown r4. Traceability analysis r5. Configuration management r6. Documents and other output media 3. Requirements management tools

30. 5. Design30 INCOSE tool-selection criteria (2 of 2) r7. Groupware r8. Interfaces to other tools r9. System environment r10. User interfaces r11. Standards r12. Support and maintenance r13. Other features 3. Requirements management tools

31. 5. Design31 Tools surveyed by INCOSE (1 of 2) rCadence -- Bones rBoeing North American, Inc. -- CASETS rVitech -- CORE rMesa Systems Guild -- Cradle/SEE rZycad -- DOORS rTeknowledge -- ProductTrack rImage That -- Extend rAscent Logic -- RDD-100 rIntegrated Chipware Inc. -- RTM rTD Technologies -- SLATE 3. Requirements management tools

32. 5. Design32 Tools surveyed by INCOSE (2 of 2) rCadence -- SPW rCompliance Automation -- VITAL LINK rTeledyne Brown Engineering -- XTie-RT rNu Thena Systems -- Foresight rMathWorks -- MATLAB, Simulink, Stateflow, Real-Time Workshop rRational (Requisite) -- RequisitePro V2.0 rStatemate -- Magnum 3. Requirements management tools

33. 5. Design33 Considerations for ease of use rUsing rLearning rPutting information into the tool rExtracting information from the tool rKnowing what information is in the tool rNavigating among information rGrouping information for comparison and reports rAssuring quality such as spell checking 3. Requirements management tools

34. 5. Design34 Considerations for compatibility rComputer and operating system being used on the project rWay team members work 3. Requirements management tools

35. 5. Design35 Considerations for satisfaction rGain understanding of the tool before committing to use tool rAvoid choices based on demo by sales person 3. Requirements management tools

36. 5. Design36 4. Homework rDiagram rCustomer wants rTimepiece spec rTimepiece contract rDesign rClock spec rAC adapter spec rProblem 4. Homework

37. 5. Design37 Diagram Customer wants C1, C2, C3 Timepiece spec S1 Timepiece contract X1 Timepiece design D1, D2, D3, D4, D5 Clock spec T1 Adapter spec U1, U2 4. Homework

38. 5. Design38 Customer wants rC1: I want a timepiece that I can look at and determine time accurate to one minute per day since the last setting rC2: Cost, size, weight, mechanism, style, power, and everything else are of no consequence rC3: I will give a flat $100 for the timepiece regardless of design 4. Homework

39. 5. Design39 Timepiece spec rS1: The timepiece shall display time accurate to one minute per day since the last setting 4. Homework

40. 5. Design40 Timepiece contract rX1: Customer will pay $100 for timepiece meeting timepiece spec 4. Homework

41. 5. Design41 Design (1 of 2) rD1: I’ll design the timepiece using existing components. rD2: I want to make a lot of profit rD3: The Dilmore catalogue shows that its least expensive clock is the model 100 for $4. It is resettable to correct the time, is accurate to one minute per day since the last setting, but requires an AC adapter 4. Homework

42. 5. Design42 Design (2 of 2) rD4: The Hazel catalog shows the model 200 as its least expensive AC adapter compatible with the Dilmore model 100 clock, and the adapter costs $1. rD5: The model 200 AC adapter comes in either black or beige at no extra cost. In my opinion, beige is more attractive in the customer’s environment 4. Homework

43. 5. Design43 Clock spec rT1: Clock shall be a Dilmore model 100 clock 4. Homework

44. 5. Design44 AC adapter spec rU1: AC adapter shall be a Hazel model 200 AC adapter rU2: AC adapter shall be beige 4. Homework

45. 5. Design45 Problem (1 of 4) r1. What items need to be successfully implemented to verify item D5? -- a. T1, U1, & U2; b. U1 & U2; c. U1; d. U2 r2. For tracing purposes, what items implement item X1? -- a. D3; b. D4, c. D3 & D4; d. D3, D4, & D5 4. Homework

46. 5. Design46 Problem (2 of 4) r3. For tracing purposes, where did the requirements for item D4 come from? -- a. D3; b. D1, D2, & D3; c. D1, D2, D3, & X1; d. S1, D1, D2, & D3 r 4. For tracing purposes, what items implement item C2? -- a. none of the listed items, b. S1 & X1, c. D1, D2, & D3; d. T1, U1, & U2 4. Homework

47. 5. Design47 Problem (3 of 4) r5. What items need to be successfully implemented to verify item S1? -- a. C1; b. D3; c. D2 & D3; d. D3, D4, & D5 r6. For tracing purposes, where does item D1 come from? -- a. none of the listed items; b. S1; c. X1; d. S1 & X1 4. Homework

48. 5. Design48 Problem (4 of 4) r7. For tracing purposes, where does item U2 come from? -- a. none of the listed items; b. D5; c. D4; d. S1 r8. If item D3 were to change to no longer require an AC adapter, which items would change? -- a. no items would change; b. D4; c. D4 & U1; d. D4, D5, U1, & U2 4. Homework