1. 2. Requirements 1 Agenda for Understand Req Activity r1. Objective r2. Identifying the customer r3. Learning what the customer wants r4. Validating customer requirements r5. Writing requirements r6. Flowing down and tracing requirements r7. Managing requirements r8. Homework

2. 2. Requirements 2 Customer-Understanding Flow Identifying the customer Learning what the customer wants Validating customer requirements Writing requirements Flowing down and tracing requirements Managing requirements Understanding the customer is a process that starts with identifying the customer and flows through to documenting and managing the customer requirements

3. 2. Requirements 3 1. Objective rUnderstand-requirements activity rProduct-based activities rProducts used to control rCompletion criteria 1. Objective

4. 2. Requirements 4 Understand-Requirements Activity q Reaches agreement with the customer on the statement of work, specifications, and interfaces that constraint product development 1. Objective

5. 2. Requirements 5 Understand-Requirements Tasks Product requirements review Assist customer in developing product requirements and interfaces initial SOW, spec, & I/Fs final SOW, spec, & I/Fs approval 1. Objective

6. 2. Requirements 6 Completion Criteria rComplete when the customer and the contractor agree on the statement of work, specification, and interfaces that constrain product development 1. Objective

7. 2. Requirements 7 Pseudo Completion Criteria rProduct specification and external interfaces complete rSystem Requirements Review (SRR) complete 1. Objective

8. 2. Requirements 8 2. Identifying the Customer rCustomer rDesign context rDesign Vs requirements rPseudo customers 2. Identifying the customer

9. 2. Requirements 9 Customer rWho is the customer? l The person who’s paying for the product; e.g., contracting agency or product engineering for the next higher product l Users of the product l Pseudo customers 2. Identifying the customer

10. 2. Requirements 10 Design 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. 2. Identifying the customer

11. 2. Requirements 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 2. Identifying the customer

12. 2. Requirements 12 Pseudo Customers Guiding Design Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design Pseudo customers guide design in addition to higher-level requirements. Pseudo Customers 2. Identifying the customer

13. 2. Requirements 13 Example -- Pseudo Customers r Enterprise rProduct line rRe-usability rPotential customers r Development process rDesign rBuild rTest rSupport rMaintenance r Other customersr Other stakeholders Pseudo customers 2. Identifying the customer

14. 2. Requirements 14 3. Learning What the Customer Wants rWhat the customer wants rSingle point of contact for agreement rReaching agreement 3. Learning what the customer wants

15. 2. Requirements 15 What the Customer Wants Customer wants Customer problem Customer preferences Economics Operation Maintenance Upgrade Field test Validation Training Support Disposal Production Politics Schedule Customer wants flow from problem, environment, and life cycle 3. Learning what the customer wants

16. 2. Requirements 16 Single Point of Contact for Agreement Documented agreement Discussion Consensus Customer point of contact Contractor point of contact Customer stakeholdersContractor stakeholders Customer and contractor stakeholders discuss issue. Each team conveys consensus to its point of contact. Points of contacts have RAA for decisions. They agree on issue and document agreement. POC has RAA for decisions 3. Learning what the customer wants

17. 2. Requirements 17 Reaching Agreement rDefine functional areas & identify requirements rPrioritize and schedule completion of requirements rAssign points of contact and stakeholders rWrite sample requirements that people can review 3. Learning what the customer wants

18. 2. Requirements 18 4. Validating Customer Requirements rValidation of requirement (VOR) rExample 1 -- process development 4. Validating customer requirements

19. 2. Requirements 19 Definition of VOR rVOR is the process of confirming that we’ve solved the customer problem. rVerification ensures that we’ve solved the problem right. Validation ensures that we’ve solved the right problem. 4. Validating customer requirements

20. 2. Requirements 20 VOR Techniques rAnalysis, modeling, prototyping, experimentation, and survey 4. Validating customer requirements

21. 2. Requirements 21 Requirements Pitfall rIt’s possible to have a correct set of requirements for the solution we’ve chosen, but the solution we’ve chosen may not solve the customer problem. 4. Validating customer requirements

22. 2. Requirements 22 VOR RAA rLies with the customer, but the contractor can assist. 4. Validating customer requirements

23. 2. Requirements 23 Alternate Definition of VOR rEnsuring that technical requirements are consistent and complete with respect to user requirements, higher specifications, and other stakeholders rEIA 632 defines validation in these terms and assigns RAA to the contractor 4. Validating customer requirements

24. 2. Requirements 24 Example 1 -- Process Development Customer believes engineering is inefficient Generates requirements for new engineering process Survey asks how engineering will respond to process Engineering will not use because cost exceeds value Solution provided by customer has correct requirements but doesn’t solve problem problem OK requirements for solution survey Validation shows solution won’t solve problem 4. Validating customer requirements

25. 2. Requirements 25 5. Writing Requirements rDefinition of a requirement rGuidelines for a good requirement rExamples 5. Writing requirements

26. 2. Requirements 26 Definition of a Requirement rSomething obligatory or demanded rStatement of some needed thing or characteristic 5. Writing requirements

27. 2. Requirements 27 Guidelines for a Good Requirement rNeeded rCapable of being verified rFeasible schedule, cost, and implementation rAt correct level in hierarchy rCannot be misunderstood rGrammatically correct rDoes not duplicate information 5. Writing requirements

28. 2. Requirements 28 Example 1 -- Good Requirements rThe motor shall weigh less than 10 pounds. rThe software shall use less than 75 percent of the computer memory available for software. rThe MTBF shall be greater than 1000 hours. 5. Writing requirements

29. 2. Requirements 29 Example 2 -- Verification (1 of 3) rCustomer want -- The outside wall shall be a material that requires low maintenance 5. Writing requirements

30. 2. Requirements 30 Example 2 -- Verification (2 of 3) rFirst possible rewording -- The outside wall shall be brick. l More verifiable l Limits contractor options l Not a customer requirement 5. Writing requirements

31. 2. Requirements 31 Example 2 -- Verification (3 of 3) rSecond possible rewording -- The outside wall shall be one that requires low maintenance. Low maintenance material is one of the following: brick, stone, concrete, stucco, aluminum, vinyl, or material of similar durability; it is not one of the following: wood, fabric, cardboard, paper or material of similar durability l Uses definition to explain undefined term 5. Writing requirements

32. 2. Requirements 32 Example 3 -- Feasible rNot feasible requirement -- The assembly shall be made of pure aluminum having a density of less than 50 pounds per cubic foot 5. Writing requirements

33. 2. Requirements 33 Example 4 -- Level r Airplane shall be capable carrying up to 2000 pounds r Wing airfoil shall be of type Clark Y Airplane Wing p Wing airfoil shall be of type Clark Y Wing airfoil type is generally a result of design and should appear in the lower product spec and not in the higher product spec. 5. Writing requirements

34. 2. Requirements 34 Example 5 -- Understanding rAvoid imprecise terms such as l Optimize l Maximize l Accommodate l Etc. l Support l Adequate 5. Writing requirements

35. 2. Requirements 35 Example 6 -- Duplication rCapable of a maximum rate of 100 gpm rCapable of a minimum rate of 10 gpm rRun BIT while pumping 10 gallons - 100 gpm rVs: Run BIT while pumping between min. and max. 5. Writing requirements

36. 2. Requirements 36 Example 7 -- Tough Requirements rBIT false alarm rate < 3 percent rComputer throughput < 75 percent of capacity rPerform over all altitudes and speeds 5. Writing requirements

37. 2. Requirements 37 6. Flowing down and tracing requirements rTypes of flowdown rDirection rOrigins and destinations rNeed rObservations and suggestions 6. Flowing down and tracing requirements

38. 2. Requirements 38 Types of Flowdown Req Straight throughExpansion Focus 6. Flowing down and tracing requirements

39. 2. Requirements 39 Direction -- Simplified Flow Spec rOften used in flowdown and tracing 6. Flowing down and tracing requirements

40. 2. Requirements 40 Direction -- Complex Flow SpecSOW Stakeholders Design SpecSOW Stakeholders Design SpecSOW Stakeholders Design I/F Note: Flow within rectangle or ellipse not shown rNot often used in flowdown and tracing 6. Flowing down and tracing requirements

41. 2. Requirements 41 Direction -- Flow through Design SpecSOW Stakeholders Design SpecSOW Stakeholders Design SpecSOW Stakeholders Design I/F Since the lower specs, interfaces, and SOW plus the ellipse labeled “design” are all part of design of the higher product, it can be said that all requirements flow through design. Design of the higher product Note: Flow within a rectangle or ellipse not shown 6. Flowing down and tracing requirements

42. 2. Requirements 42 Direction -- Notation Spec Design Spec Although all requirements flow through design, it is common to flowdown requirements that flow straight through directly from spec to spec Spec Straight-throughExpanded or Focused Vs 6. Flowing down and tracing requirements

43. 2. Requirements 43 Origins and Destinations -- Types Req Straight through ExpansionFocusCreationEnd Design Req 6. Flowing down and tracing requirements

44. 2. Requirements 44 Example 1 -- Illustrations 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 6. Flowing down and tracing requirements

45. 2. Requirements 45 Need -- Types (1 of 5) r1. Flowdown -- Where did requirement get implemented? l Less precise linkage criteria than tracing for verification/validation l Often done by doing tracing first 6. Flowing down and tracing requirements

46. 2. Requirements 46 Need -- Types (2 of 5) r2. Tracing for verification/validation -- What lower requirements are used in verifying/validating higher requirements? l Simplest and most repeatable 6. Flowing down and tracing requirements

47. 2. Requirements 47 Need -- Types (3 of 5) r3. Tracing for origin -- Where did each requirement come from; why does it exist? l more linkages to explain how design creates requirements 6. Flowing down and tracing requirements

48. 2. Requirements 48 Need -- Types (4 of 5) r4. Tracing for change impact -- If one requirement changes, what other requirements must change? l More linkages to reflect impacts of requirements on each other 6. Flowing down and tracing requirements

49. 2. Requirements 49 Need -- Types (5 of 5) rFour types result in different sets of linkages 6. Flowing down and tracing requirements

50. 2. Requirements 50 Observations (1 of 3) rTracing is complex and expensive rLack of training & rules make trace not repeatable or dependable rMany believe cost far out weighs the benefit rCustomer may expect flowdown and tracing 6. Flowing down and tracing requirements

51. 2. Requirements 51 Observations (2 of 3) rRules of thumb can cause trouble l All requirements must come from somewhere l All requirements must go somewhere 6. Flowing down and tracing requirements

52. 2. Requirements 52 Observations (3 of 3) rDesign is an essential part of flow down 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 6. Flowing down and tracing requirements

53. 2. Requirements 53 Suggestion 1 rNegotiate with customer to minimize effort 6. Flowing down and tracing requirements

54. 2. Requirements 54 Suggestion 2 rProvide rules and training 6. Flowing down and tracing requirements

55. 2. Requirements 55 Suggestion 3 Req Expansion Focus Design Req Expansion Focus Flow expansion and focus through design -- not directly 6. Flowing down and tracing requirements

56. 2. Requirements 56 7. Managing Requirements rRequirements attributes rInterface requirements rRequirements change rRequirements management tools 7. Managing requirements

57. 2. Requirements 57 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 7. Managing requirements

58. 2. Requirements 58 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 7. Managing requirements

59. 2. Requirements 59 Interface Requirements -- Data Example rData item rCriteria rTiming rUnits and enumeration rFormat rRanges rAccuracy 7. Managing requirements

60. 2. Requirements 60 Interface Requirements -- Physical Example rElectrical l Signals l Power l EMI/EMC l Grounding rMechanical l Dimensions l Mounting l Alignment l Weight l Heating l Cooling 7. Managing requirements

61. 2. Requirements 61 Requirements Documentation rMedia l Paper l Office computer tools l Data base rFormat l Contractor chosen l Commercial standard l MIL-STD-490A l MIL-STD-490B 7. Managing requirements

62. 2. Requirements 62 Requirements Change rOften handled through configuration management rTechniques l Data base l Change pages l Red-line changes 7. Managing requirements

63. 2. Requirements 63 Requirements Management Tools rINCOSE tools survey rConsiderations in choosing tools rSuggestions on tool selection 7. Managing requirements

64. 2. Requirements 64 INCOSE -- Tools Survey rComparison made by National Council on Systems Engineering (INCOSE) rInternet address: http\\www.incose.org/workgrps/tools/req_surv.htm 7. Managing requirements

65. 2. Requirements 65 INCOSE -- Criteria ( 1 of 3) r1. Capturing requirements identification r2. Capturing system element structure r3. Requirements flowdown r4. Traceability analysis 7. Managing requirements

66. 2. Requirements 66 INCOSE -- Criteria ( 2 of 3) r5. Configuration management r6. Documents and other output media r7. Groupware r8. Interfaces to other tools r9. System environment 7. Managing requirements

67. 2. Requirements 67 INCOSE -- Criteria ( 3 of 3) r10. User interfaces r11. Standards r12. Support and maintenance r13. Other features 7. Managing requirements

68. 2. Requirements 68 INCOSE -- Tools Surveyed (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 7. Managing requirements

69. 2. Requirements 69 INCOSE -- Tools Surveyed (1 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 7. Managing requirements

70. 2. Requirements 70 Considerations for Ease rUse 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 rQuality assurance such as spell checking 7. Managing requirements

71. 2. Requirements 71 Considerations for Compatability rComputer and operating system being used on the project rWay team members work 7. Managing requirements

72. 2. Requirements 72 Considerations for Satisfaction rGain understanding of the tool before committing to use tool rAvoid choices based on demo by sales person 7. Managing requirements

73. 2. Requirements 73 8. Homework rDiagram rCustomer wants rTimepiece spec rTimepiece SOW rDesign rClock spec rAC adapter spec rProblem 8. Homework

74. 2. Requirements 74 Diagram Customer wants C1, C2, C3 Timepiece spec S1 Timepiece SOW X1 Timepiece design D1, D2, D3, D4, D5 Clock spec T1 Adapter spec U1, U2 8. Homework

75. 2. Requirements 75 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 8. Homework

76. 2. Requirements 76 Timepiece Spec rS1: The timepiece shall display time accurate to one minute per day since the last setting 8. Homework

77. 2. Requirements 77 Timepiece SOW rX1: Customer will pay $100 for timepiece meeting timepiece spec 8. Homework

78. 2. Requirements 78 Design 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 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 8. Homework

79. 2. Requirements 79 Clock Spec rT1: Clock shall be a Dilmore model 100 clock 8. Homework

80. 2. Requirements 80 AC Adapter Spec rU1: AC adapter shall be a Hazel model 200 AC adapter rU2: AC adapter shall be beige 8. Homework

81. 2. Requirements 81 Homework Problem (1 of 2) 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 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 8. Homework

82. 2. Requirements 82 Homework Problem (2 of 2) 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 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 8. Homework