1 / 50

Agenda for understand-req activity

Agenda for understand-req activity. 1. Objective 2. Identifying the customer 3. Learning what the customer wants 4. Trade studies 5. Quality functional deployment (QFD) 6. Validating customer requirements 7. Writing requirements 8. Homework. 1. Objective. Understand-requirements activity

katima
Download Presentation

Agenda for understand-req activity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Agenda for understand-req activity • 1. Objective • 2. Identifying the customer • 3. Learning what the customer wants • 4. Trade studies • 5. Quality functional deployment (QFD) • 6. Validating customer requirements • 7. Writing requirements • 8. Homework

  2. 1. Objective • Understand-requirements activity • Understand-requirements tasks • Completion criteria • Pseudo-completion criteria • Customer-understanding flow 1. Objective

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

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

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

  6. Pseudo-completion criteria • Product specification and external interfaces complete • Requirements review (RR) complete 1. Objective

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

  8. 2. Identifying the Customer • Customer • Design context • Design vs requirements • Pseudo customers 2. Identifying the customer

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

  10. Design context Level N Spec Level N Design Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N+1 Design 1 Level N+1 Design 2 Level N+1 Design M Level N+2 Spec 1 Level N+2 Spec 2 Level N+2 Spec P Design occurs at each level and produces lower specs . 2. Identifying the customer

  11. Design vs requirements Level N Spec Design as seen by level N Level N Design Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Requirements as seen by level N+1 Design at level N becomes requirements at level N+1 2. Identifying the customer

  12. Pseudo customers (1 of 2) Level N Spec Level N Design Pseudo customers Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M In addition to higher-level requirements, pseudo customers guide design 2. Identifying the customer

  13. Pseudo customers (2 of 2) • Development process • Design • Build • Test • Support • Maintenance • Enterprise • Product line • Re-usability • Potential customers Example pseudo customers • Other customers • Other stakeholders 2. Identifying the customer

  14. 3. Learning what the customer wants • What the customer wants • Single point of contact for agreement • Reaching agreement 3. Learning what the customer wants

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

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

  17. Reaching agreement • Define functional areas & identify requirements • Prioritize and schedule completion of requirements • Assign points of contact and stakeholders • Write sample requirements that people can review 3. Learning what the customer wants

  18. 4. Trade studies • Use • Example 4. Trade studies

  19. Use • Used to make decisions • Should be have a reason for being done • Common technique is to use weighted ranking • Ideal -- Choose weights before study • Reality -- Choose weights after study • INCOSE Systems Engineering Handbook discusses in detail 4. Trade studies

  20. Example 1 lawn mower

  21. 5. Quality functional deployment (QFD) • QFD • Example • QFD flowdown • QFD limitations 5. Quality functional deployment (QFD)

  22. QFD • A requirements flowdown technique • Deploys voice of the customer • Flows down requirements to design, parts, and manufacturing 5. Quality functional deployment (QFD)

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

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

  25. QFD limitations • Duplicates information in specs • Requires tool 5. Quality functional deployment (QFD)

  26. 6. Validating customer requirements • Definition of VOR • VOR techniques • Requirements pitfall • VOR RAA • Alternate definition of VOR • Example 6. Validating customer requirements

  27. Definition of VOR • VOR is the process of confirming that we’ve solved the customer problem. • Verification ensures that we’ve solved the problem right. Validation ensures that we’ve solved the right problem. 6. Validating customer requirements

  28. VOR techniques • Analysis, modeling, prototyping, experimentation, and survey 6. Validating customer requirements

  29. Requirements pitfall • It’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. VOR RAA • Lies with the customer, but the contractor can assist. • However, in generating requirements for lower products, contractor has RAA for VOR 6. Validating customer requirements

  31. Alternate definition of VOR • Ensuring that technical requirements are consistent and complete with respect to user requirements, higher specifications, and other stakeholders • EIA 632 defines validation in these terms and assigns RAA to the contractor 6. Validating customer requirements

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

  33. 7. Writing requirements • Definition of a requirement • Occurrence of requirements • Guidelines for a good requirement • Tools for writing good requirements • Examples • Notes 7. Writing requirements

  34. Definition of a requirement • Something obligatory or demanded • Statement of some needed thing or characteristic 7. Writing requirements

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

  36. Guidelines for a good requirement • Needed • Capable of being verified • Feasible schedule, cost, and implementation • At correct level in hierarchy • Cannot be misunderstood • Grammatically correct • Does not duplicate information Errors in requirements come mainly from incorrect facts (50%), omissions (30%), inconsistent (15%), ambiguous (2%), misplaced (2%) 7. Writing requirements

  37. Tools for writing good requirements • Requirements elicitation • Modeling • Trade studies 7. Writing requirements

  38. Example 1 -- good requirements • The motor shall weigh less than 10 pounds. • The software shall use less than 75 percent of the computer memory available for software. • The MTBF shall be greater than 1000 hours. 7. Writing requirements

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

  40. Example 2 -- verification (2 of 3) • First possible rewording -- The outside wall shall be brick. • More verifiable • Limits contractor options • Not a customer requirement 7. Writing requirements

  41. Example 2 -- verification (3 of 3) • Second 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 • Uses definition to explain undefined term 7. Writing requirements

  42. Example 3 -- feasible • Not 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. Example 4 -- level Airplane • Airplane shall be capable carrying up to 2000 pounds • Wing airfoil shall be of type Clark Y Wing • 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. 7. Writing requirements

  44. Example 5 -- understanding • Avoid imprecise terms such as • Optimize • Maximize • Accommodate • Etc. • Support • Adequate 7. Writing requirements

  45. Example 6 -- duplication • Capable of a maximum rate of 100 gpm • Capable of a minimum rate of 10 gpm • Run BIT while pumping 10 gallons - 100 gpm • Vs: Run BIT while pumping between min. and max. 7. Writing requirements

  46. Example 7 -- tough requirements • BIT false alarm rate < 3 percent • Computer throughput < 75 percent of capacity • Perform over all altitudes and speeds • Conform with all local, state, and national laws • There shall be no loss of performance • Shall be safe • The display shall look the same • TBDs and TBRs • Statistics 7. Writing requirements

  47. Notes • Perfect requirements can’t always be written • It’s not possible to avoid all calamities • Requirements and design are similar 7. Writing requirements

  48. 8. Homework (1 of 3) • 1. RAA for requirements in the understand- customer activity lie with (a) requirements management, (b) the customer, (c) the contractor, (d) quality assurance • 2. 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. Homework (2 of 3) • 3. 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 • 4. 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. Homework (3 of 3) • 5. 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 • 6. 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

More Related