Marcos Esterman, Associate ProfessorIndustrial and Systems Engineering DepartmentRochester Institute of Technologymarcos.esterman@rit.edu

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

Begin with the end state: Engineering Requirements Table

Engineering Requirement Measure Target Value Acceptable ValueBreathing Rate Breaths/MinFlow Volume Range LitersPeak Flow Rate Liters/minFlow Volume Set Point Accuracy % of desired valueAir Assist Sensitivity cm H20Blood Oxygen Level % Blood Operation Temperature Range CSystem Volume Envelope cm3Weight kg90% of User find Visually Appealing Binary Aesthetic TestSuccessfully Passes Usability Testing (TBD) Binary or More FormalPrototype Cost $$Unit Manufacturing Cost $$Individual list of data to be Measured BinaryData Transfer Reliability to XXX device(s) Bits Lost/Total Bits Desired to be TransferredAir Contaminants Parts per MillionAdheres to and Passes UL/FDA Testing BinaryIntegrates Patent Principles Binary

Binary

Begin with the end state: Needs and ER Relationship Matrix

Need Priority Brea

thin

g Ra

te

Flow

Vol

ume

Rang

e

Peak

Flo

w R

ate

Flow

Vol

ume

Set P

oint

Acc

urac

y

Air A

ssist

Sen

sitivi

ty

Bloo

d O

xyge

n Le

vel

Ope

ratio

n Te

mpe

ratu

re R

ange

Syst

em V

olum

e En

velo

pe

Wei

ght

90%

of U

ser fi

nd V

isual

ly A

ppea

ling

Succ

essf

ully

Pas

ses U

sabi

lity

Testi

ng (T

BD)

Prot

otyp

e Co

st

Uni

t Man

ufac

turin

g Co

st

Indi

vidu

al li

st o

f dat

a to

be

Mea

sure

d

Data

Tra

nsfe

r Rel

iabi

lity

to X

XX d

evic

e(s)

Air C

onta

min

ants

Adhe

res t

o an

d Pa

sses

UL/

FDA

Testi

ng

Inte

grat

es P

aten

t Prin

cipl

es

Inte

grat

es F

DA A

ppro

val

Have a modern look and feel 3 xIs Light weight 3 x xIs Small 3 xIs Easy to Use 9 xHas Long-Lasting Portable Power 9Low Cost Functional Prototype 3 x xLow UMC for Final Design 9 xAlert user of the following data: XXX 9 xMeasure Oxygen Levels 3 xMeasure CO2 Levels 3Transfer Data Wirelessly 9 xAssist Human to Breathe 9 x x x x xIntegrates into CPR Process 9 xDoes not interfere with the following life-saving measures: XXX 9 xImproves air quality delivered to patient 9 xIs safe 9 xIs reliable 9 x xNeeds to use principles in patents #5,211,170 and # 5,398,676 9 xNeeds to be consistent with FDA 510K Approval 9 x

Mea

sure

Brea

ths/

Min

Lite

rs

Lite

rs/m

in

cm H

20

% B

lood

C cm3

kg

Bina

ry A

esth

etic

Test

Bina

ry o

r Mor

e Fo

rmal

$$ $$

Bina

ry

Bits

Los

t/To

tal B

its D

esire

d to

be

Tra

nsfe

rred

Part

s per

Mill

ion

Bina

ry

Bina

ry

Bina

ry

Engineering Requirements

Requirements - Terminology

Term Definition CommentsCustomer 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

The House of QualityER

Interactions

EngineeringRequirements

CustomerRequirementsBenchmarking

CustomerRequirements

ERTargets

CR’svs.

EM’s

ER Benchmarking

10

Focus for MSD

Dries FastEasy to HoldLooks Good

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

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

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

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

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, 200415

Typical HoQ - PEV HoQ

QFD and ER List.xlsx

16K. Ishii, 2004

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

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

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

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, 200420

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

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

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 them23

Review of Team’s ER List