1. Marcos Esterman, Associate Professor Industrial and Systems Engineering Department Rochester Institute of Technology marcos.esterman@rit.edu Multidisciplinary Senior Design I Problem Definition: Interviewing the Customer & Refining the Needs

2. Agenda Critique of Needs Elicitation Process Needs Refinement

3. CUSTOMER INTERVIEWS

4. PROCESS CRITIQUE

5. Critique Questions & Process

6. NEEDS REFINEMENT & ANALYSIS

7. Begin with the end state: Engineering Requirements Table

8. Begin with the end state: Needs and ER Relationship Matrix

9. Requirements - Terminology TermDefinitionComments Customer Requirements Voice of the Customer (VOC) what the customer wants or needs to be able to do May not be aware they need it! desired attributes of the solution in the language of the customer not an exact reproduction Solution independent Often called Customer Needs Engineering Requirements Voice of the Engineer (VOE) technical needs of the system design highest level is translated from VOC Often called Specifications

10. The House of Quality ER Interactions Engineering Requirements Customer Requirements Benchmarking Customer Requirements ER Targets CR’s vs. EM’s ER Benchmarking 10 Focus for MSD Dries Fast Easy to Hold Looks Good

11. Engineering Requirements Guidance to Design & Engineer the Product  It is another level of “What” the product has to do Dependent variables  Can be quantified  Can be measured  Should be ordinal Some metrics may not be “quantifiable”  Psychometrics  Binary  List Need to Include Industry Standard Tests  UL, FDA, IEEE, etc. 11

12. Engineering Requirements Properties  (1) Abstract (what, not how)  (2) Verifiable (testable)  (3) Unambiguous (single meaning)  (4) Traceable (to customer requirements)  (5) Realistic or Justified Requirements “flow-down”  customer => system => subsystem => component Requirements ”traceability”  component => subsystem => system => customer

13. Constraints Special Type of Engineering Requirement  a design decision imposed by stakeholder or the environment that impacts or limits the design.  typically cannot be measured until the entire system is integrated (for example, the weight of the system)  can violate the abstractness property if there is a justifiable need to constrain the solution for example, we own the IP on a particular solution

14. Types of Engineering Requirements Performance  Takes less that 1 second to measure vital signs Functionality (energy, material, or information transformations)  Measure Oxygen Content of the Blood Operational  Electromagnetic Emissions will be held to less than 1000 Hz Economic  The UMC will be less that $100 Environmental, health & safety  All materials used will be RoHS compliant Manufacturability  Final assembly of the PEV will take no more 90 seconds Maintainability  Requires no intervention from the user to maintain Reliability  Mean Time to Failure is Greater than 1000 hours of use Usability  Takes less than 30 seconds to secure PEV on patient

15. Relationship between CUSTOMER REQUIREMENTS and ENGINEERING METRICS.  Take Readings Fast vs. Takes less that 1 second to measure vital signs Fundamental Question  “If the EM is successfully achieved, will the customer need be satisfied and to what degree”? Assessment in Cells  “9” Strongly Correlated  “3” Correlated  “1” Somewhat Correlated  “0” Not Correlated Relationship Matrix K. Ishii, 2004 15

16. Typical HoQ - PEV HoQ QFD and ER List.xlsx 16 K. Ishii, 2004

17. Relationship Evaluation: Tips for Success Maintain a high hurdle for significance  Less than 50% of the cells should be populated Usually involves much discussion to build team consensus  Do not allow the matrix to exceed 30 x 30  Rank order customer needs Set a time limit then stop  Take a poll at the beginning of each cell If there is consensus, move on Sanity Check  Does the relationship make sense?  Is it supported by field data? Clausing, D., Total Quality Development,: A Step-By-Step Guide to World Class Concurrent Engineering, ASME Press, NY 1994, pp. 133 - 134 17

18. Process Check Are there any empty columns or rows?  Empty row Customer need not being addressed  Empty column Superfluous EM Missing customer need Column with too many relationships  EM probably defined too broadly Iterate between VOCs, EMs & Relationships until consensus built Clausing, D., Total Quality Development,: A Step-By-Step Guide to World Class Concurrent Engineering, ASME Press, NY 1994, pp. 135 18

19. Engineering Requirement Benchmarking Perform competitive technical tests  Recall, ERs should be quantitative & measurable Teardown and analyze competitive products  Continuous & periodic Establishes “Best-in-Class” & why Benefits  Needs competitors satisfy  Concept generation seed  Feature design seed  Setting EMs 19

20. Engineering Requirement Targets Quantitatively describe information about product/engineering metrics.  Cubic feet per minute.  Db noise level Targets = Ideal Customer Satisfaction  If possible, tolerances should be captured Ways to express EMs  At least X  At Most X  Between X & Y  Exactly X  Discrete Values K. Ishii, 2004 20

21. The Dynamic Nature of ERs Clausing, D., Total Quality Development,: A Step-By-Step Guide to World Class Concurrent Engineering, ASME Press, NY 1994, pp. 100 EM Concepts Design EM Concepts Design Rigid Freeze Progressive Freeze Do-it Once & Do-it Right Complete, but not Frozen 21

22. Setting the Final Values Develop Technical Models  Analytical  Physical Develop Cost Models Trade-offs where Necessary  E.G. Cost vs. Performance  Conjoint Analysis Specification Flow-down 22

23. Next Steps Most important requirements have been identified  Do they make sense If not, investigate If so, these become the critical parameters to track through development and assign resources to System Decomposition  Remember ‘Abstract & General” -> ‘Concrete & Detailed’  At this point all you have done is defined a new problem at a lower-level of abstraction i.e. Sub-systems now need to be defined and solutions found for them 23

24. Review of Team’s ER List