1. 2. Requirements1 Agenda for understand-req activity r1. Objective r2. Identifying the customer r3. Learning what the customer wants r4. Trade studies r5. Quality functional deployment (QFD) r6. Validating customer requirements r7. Writing requirements r8. Homework

2. 2. Requirements2 1. Objective rUnderstand-requirements activity rUnderstand-requirements tasks rCompletion criteria rPseudo-completion criteria rCustomer-understanding flow 1. Objective

3. 2. Requirements3 Understand-requirements activity rReaches agreement with the customer on the statement of work, specifications, and interfaces that constrain product development 1. Objective

4. 2. Requirements4 Understand-requirements tasks Product requirements review (RR) Assist customer in developing product requirements and interfaces initial contract, spec, & I/Fs final contract, spec, & I/Fs approval 1. Objective

5. 2. Requirements5 Completion criteria rComplete when the customer and the contractor agree on the statement of work, specification, and interfaces that constrain product development 1. Objective

6. 2. Requirements6 Pseudo-completion criteria rProduct specification and external interfaces complete rRequirements review (RR) complete 1. Objective

7. 2. Requirements7 Customer-understanding flow Identifying the customer Learning what the customer wants Validating customer requirements Writing requirements Flowing down and tracing requirements Review requirements Understanding the customer identifies the customer & flows through to managing customer requirements Managing requirements 1. Objective

8. 2. Requirements8 2. Identifying the Customer rCustomer rDesign context rDesign vs requirements rPseudo customers 2. Identifying the customer

9. 2. Requirements9 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. Requirements10 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. Requirements11 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. Requirements12 Pseudo customers (1 of 2) 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 Pseudo customers 2. Identifying the customer

13. 2. Requirements13 Pseudo customers (2 of 2) r Enterprise rProduct line rRe-usability rPotential customers r Development process rDesign rBuild rTest rSupport rMaintenance r Other customers r Other stakeholders Example pseudo customers 2. Identifying the customer

14. 2. Requirements14 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. Requirements15 What the customer wants Customer wants Customer problem Customer preferences Economics Operation Maintenance Upgrade Field test Validation Training Support Disposal Production Politics Schedule Wants flow from problem, environment, and life cycle

16. 2. Requirements16 Single point of contact for agreement Documented agreement Discussion Consensus Customer point of contact Contractor point of contact Customer stakeholdersContractor stakeholders Stakeholders discuss issue. Each team conveys consensus to its POC. POCs have RAA for decisions. Stakeholders discuss issue. Each team conveys consensus to its POC. POCs have RAA for decisions. POC has RAA for decisions 3. Learning what the customer wants

17. 2. Requirements17 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. Requirements18 4. Trade studies rUse rExample 4. Trade studies

19. 2. Requirements19 Use rUsed to make decisions rShould be have a reason for being done rCommon technique is to use weighted ranking l Ideal -- Choose weights before study l Reality -- Choose weights after study rINCOSE Systems Engineering Handbook discusses in detail 4. Trade studies

20. 2. Requirements20 Example 1 lawn mower

21. 2. Requirements21 5. Quality functional deployment (QFD) rQFD rExample rQFD flowdown rQFD limitations 5. Quality functional deployment (QFD)

22. 2. Requirements22 QFD rA requirements flowdown technique rDeploys voice of the customer rFlows down requirements to design, parts, and manufacturing 5. Quality functional deployment (QFD)

23. 2. Requirements23 Example 1 lawn mower - - -- - 5. Quality functional deployment (QFD)

24. 2. Requirements24 QFD flowdown what how much how what how much how what how much how Design Parts Manufacturing 5. Quality functional deployment (QFD)

25. 2. Requirements25 QFD limitations rDuplicates information in specs rRequires tool 5. Quality functional deployment (QFD)

26. 2. Requirements26 6. Validating customer requirements rDefinition of VOR rVOR techniques rRequirements pitfall rVOR RAA rAlternate definition of VOR rExample 6. Validating customer requirements

27. 2. Requirements27 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. 6. Validating customer requirements

28. 2. Requirements28 VOR techniques rAnalysis, modeling, prototyping, experimentation, and survey 6. Validating customer requirements

29. 2. Requirements29 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. 6. Validating customer requirements

30. 2. Requirements30 VOR RAA rLies with the customer, but the contractor can assist. rHowever, in generating requirements for lower products, contractor has RAA for VOR 6. Validating customer requirements

31. 2. Requirements31 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 6. Validating customer requirements

32. 2. Requirements32 Solution provided by customer has correct requirements but doesn’t solve problem Solution provided by customer has correct requirements but doesn’t solve problem 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 problem OK requirements for solution survey Validation shows solution won’t solve problem 6. Validating customer requirements

33. 2. Requirements33 7. Writing requirements rDefinition of a requirement rOccurrence of requirements rGuidelines for a good requirement rTools for writing good requirements rExamples rNotes 7. Writing requirements

34. 2. Requirements34 Definition of a requirement rSomething obligatory or demanded rStatement of some needed thing or characteristic 7. Writing requirements

35. 2. Requirements35 Occurrence of requirements rWriting requirements occurs in both the understand-customer activity and the design activity rThe customer has RAA for requirements in the understand-customer activity even though the contractor may actually write the requirements rThe contractor has RAA for requirements in the design activity 7. Writing requirements

36. 2. Requirements36 Errors in requirements come mainly from incorrect facts (50%), omissions (30%), inconsistent (15%), ambiguous (2%), misplaced (2%) Errors in requirements come mainly from incorrect facts (50%), omissions (30%), inconsistent (15%), ambiguous (2%), misplaced (2%) 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 7. Writing requirements

37. 2. Requirements37 Tools for writing good requirements rRequirements elicitation rModeling rTrade studies 7. Writing requirements

38. 2. Requirements38 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. 7. Writing requirements

39. 2. Requirements39 Example 2 -- verification (1 of 3) rCustomer want -- The outside wall shall be a material that requires low maintenance 7. Writing requirements

40. 2. Requirements40 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 7. Writing requirements

41. 2. Requirements41 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 7. Writing requirements

42. 2. Requirements42 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 7. Writing requirements

43. 2. Requirements43 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. Wing airfoil type is generally a result of design and should appear in the lower product spec and not in the higher product spec. 7. Writing requirements

44. 2. Requirements44 Example 5 -- understanding rAvoid imprecise terms such as l Optimize l Maximize l Accommodate l Etc. l Support l Adequate 7. Writing requirements

45. 2. Requirements45 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. 7. Writing requirements

46. 2. Requirements46 Example 7 -- tough requirements rBIT false alarm rate < 3 percent rComputer throughput < 75 percent of capacity rPerform over all altitudes and speeds rConform with all local, state, and national laws rThere shall be no loss of performance rShall be safe rThe display shall look the same rTBDs and TBRs rStatistics 7. Writing requirements

47. 2. Requirements47 Notes rPerfect requirements can’t always be written rIt’s not possible to avoid all calamities rRequirements and design are similar 7. Writing requirements

48. 2. Requirements48 8. Homework (1 of 3) r1. RAA for requirements in the understand- customer activity lie with (a) requirements management, (b) the customer, (c) the contractor, (d) quality assurance r2. The understand-customer activity reaches agreement with the customer on which type of interfaces: (a) interfaces external to the product, (b) interfaces internal to the product,(c) all interfaces, (d) interfaces that constrain product development 8. Homework

49. 2. Requirements49 Homework (2 of 3) r3. The customer is (a) is always one entity, (b) may be more than one entity, (c) always the product at the next-higher level, (d) undefined r4. A good practice in reaching agreement with the customer is to have agreements made by (a) management, (b) contracts, (c) a single- point of contact for customer and a single- point of contact for contractor, (d) individual stakeholders 8. Homework

50. 2. Requirements50 Homework (3 of 3) r5. Trade studies should (a) always be done, (b) always use the method defined in the INCOSE Systems Engineering Handbook, (c) be done only if needed, (d) always include QFD considerations r6. For the requirement “Performance shall be met when speed greater than 200 mph and speed less that 400 mph,” performance must be met at (a) requirement unclear, (b) 200 mph and 400 mph, (c) any one point in the speed range, (d) all points in the speed range. 8. Homework