1 / 24

Multidisciplinary Senior Design I

Multidisciplinary Senior Design I. Problem Definition: Interviewing the Customer & Refining the Needs. Agenda. Critique of Needs Elicitation Process Needs Refinement. Customer interviews. Process Critique. Critique Questions & Process. Needs Refinement & Analysis.

marvin
Télécharger la présentation

Multidisciplinary Senior Design I

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

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

  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.

  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 RoHScompliant • 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 Matrix • 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 K. Ishii, 2004

  16. Typical HoQ- PEV HoQ • QFD and ER List.xlsx 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

  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

  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

  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

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

  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

  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

  24. Review of Team’s ER List

More Related