1 / 62

Agenda for understand-req activity

Agenda for understand-req activity. 1. Objective 2. Identifying the customer 3. Learning what the customer wants 4. Tools 5. Validating customer requirements 6. Writing requirements 7. Homework. 1. Objective. Understand-requirements activity Understand-requirements tasks

colin-gates
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. Tools • 5. Validating customer requirements • 6. Writing requirements • 7. Homework

  2. 1. Objective • Understand-requirements activity • Understand-requirements tasks • Completion criteria • Pseudo-completion criteria • Understanding-requirements flow • Other requirements concepts 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 final contract, spec, & I/Fs Assist customer in developing product requirements and interfaces initial contract, spec, & I/Fs Product requirements review (RR) 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. Understanding-requirements flow Learning what the customer wants Identifying the customer Validating customer requirements Writing requirements Managing requirements Review requirements Understanding requirements identifies the customer & flows through to managing customer requirements 1. Objective

  8. Other requirements concepts (1 of 2) • 1. Understand requirements vs requirements management • The understand-requirements activity is not the same as requirements management • The understand-requirements focuses on identifying who the customers are and what they want. • Requirements management focuses on generating and maintaining quality requirements of all types regardless of what activity generates them 1. Objective

  9. Other requirements concepts (2 of 2 • Understand requirements vs requirements analysis • Requirements analysis is approximately the same as understanding requirements • Understand requirements does not include designing although it may use the results of design • Definition of requirements is a little looser and sometimes includes high-level definition of design 1. Objective

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

  11. Customer • Customers for the product • 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 • Note that there may be more than one of each type of customer for each product 2. Identifying the customer

  12. 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

  13. 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

  14. 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

  15. 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

  16. 3. Learning what customers want • What the customers want • Eliciting wants from the customers • Single point of contact for agreement • Reaching agreement 3. Learning what the customer wants

  17. What the customers want (1 of 3) 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

  18. What the customer wants (2 of 3) • IEEE P1220 tasks • 1. Customer expectations • 2. Project and enterprise constraints • 3. External constraints • 4. Operational scenarios • 5. Measure of effectiveness (MOEs) • 6. System boundaries • 7. Interfaces • 8. Utilization environments 15 tasks from IEEE P 1220

  19. What the customer wants (3 of 3) • IEEE P 1220 tasks (continued) • 9. Life cycle • 10. Functional requirements • 11. Performance requirements • 12. Modes of operation • 13. Technical performance measures • 14. Physical characteristics • 15. Human systems integration 15 tasks from IEEE P 1220 (continued)

  20. Eliciting wants from customers • Tools • Quality functional deployment • Trade studies • Published materials -- RFPs, RFIs, RFQs, trade journals and bulletins • Techniques • Customer-contractor partnerships • Engineer-to-engineer contacts • Alliances and teaming • Techniques taught in customer elicitation courses 3. Learning what the customer wants

  21. 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

  22. 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

  23. 4. Tools • Trade studies • Quality functional deployment (QFD) • Caution 4. Tools

  24. Trade studies (1 of 2) • Used to make decisions • Many types of trade studies • A common technique is to use weighted ranking -- discussed in INCOSE Systems Engineering Handbook • Ideal -- Choose weights before study • Reality -- Choose weights after study 4. Tools

  25. Trade studies (2 of 2)

  26. QFD (1 of 5) • A requirements elicitation and flowdown technique • Deploys voice of the customer • Flows down requirements to design, parts, and manufacturing 4. Tools

  27. QFD (2 of 5) - - - - - 4. Tools

  28. QFD (3 of 5)

  29. how what how much how what how much how what how much QFD (4 of 5) Design Parts Manufacturing 4. Tools

  30. QFD (5 of 5) • Shortcomings • Duplicates information in specifications • Requires tool 4. Tools

  31. Caution • Tools should be used because they’re needed • They shouldn’t be used just because they’re available or because we feel obligated to use the tools 4. Tools

  32. 5. Validating customer requirements • Definition of VOR • VOR techniques • Requirements pitfall • VOR RAA • Alternate definition of VOR • Example • Cautions 5. Validating customer requirements

  33. Definition of VOR (1 of 2) • 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. Validation vs verification 5. Validating customer requirements

  34. Definition of VOR (2 of 2) • 1. Ensure customer requirements are correct • Done early • Integral part of understanding requirements • 2. Ensure customer approach solves problem • Done early • 3. Ensure that product solved the problem • Done on delivered product • Meets requirements but doesn’t solve problem Three types of validation

  35. VOR techniques • Analysis, modeling, prototyping, experimentation, and survey 5. Validating customer requirements

  36. 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. 5. Validating customer requirements

  37. VOR RAA • Lies with the customer, but the contractor can assist. • However, in generating requirements for lower products, contractor has RAA for VOR 5. Validating customer requirements

  38. Alternate definition of VOR • Ensuring that technical requirements are consistent and complete with respect to user requirements, higher specifications, and other stakeholders 5. Validating customer requirements

  39. 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 5. Validating customer requirements

  40. Cautions (1 of 3) wrong problem right problem customer choice our choice common approach when contractors want to sell their product spec Exercise care in telling customer that, in our opinion, they’ve solved the wrong problem 5. Validating customer requirements

  41. Cautions (2 of 3) real problem problem virtual problem customer solution spec Exercise care to not confuse customer solution with customer problem 5. Validating customer requirements

  42. Cautions (3 of 3) problem what validation is supposed to do customer solution our solution common approach when contractors want to sell their product spec Exercise care in telling customer that, in our opinion, they’ve solved the problem wrong 5. Validating customer requirements

  43. 6. Writing requirements • Definition of a requirement • Occurrence of requirements • Guidelines for a good requirement • Examples for each guideline • Tools for writing good requirements • Notes 6. Writing requirements

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

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

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

  47. Example for each guideline • Example 1 -- needed • Example 2 -- verification • Example 3 -- feasible • Example 4 -- level • Example 5 -- understanding • Example 6 -- duplication • Example 7 -- grammar and spelling • Example 8 -- tough requirements 6. Writing requirements

  48. Example 1 -- needed • 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. 6. Writing requirements

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

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

More Related