Sei sulla pagina 1di 51

Creative Engineering

g g Design
g
Module 4: Problem identification using requirement checklists,
products and patent study, ISQ, requirement list, assigning
importance to requirements

Centre for Product Design and Manufacturing
Indian Institute of Science, Bangalore, India

Amaresh Chakrabarti
1
Outline and Modules
Module Topic No of hrs
No of hrs
1 Introduction: design Thinking across domains, major elements of design thinking,  6
definition of system, design, product design, engineering design, creativity, science, 
design science (research); Importance of design
design science (research); Importance of design
2 Product life cycle, Structure of systematic product design process, Structure of  4
systematic product development process, Importance of systematic design, , Case Study
3 Task Clarification1: overall process and steps, market study, user/habitat analysis using 4
role play, observations and interaction with stakeholders
4 Task Clarification 2: Problem identification using requirement checklists, study of  4
products and patents using Innovation Situation Questionnaire (ISQ), steps for collating 
data from multiple sources into a stakeholder requirement list translating stakeholder 
data from multiple sources into a stakeholder requirement list, translating stakeholder
requirements into technical requirements, assigning importance to requirements
5 Task Clarification 3: Problem definition to develop solution neutral problem statements, 4
problem analysis to develop input‐output transformation, case study
6 Introduction to conceptual design: Identification of functions, Ideation, Consolidation  4
into solution proposals (Concepts), and their systematic evaluation for selection of the 
most promising concept. Details of function structure generation and brainstorming
7 Conceptual design 2: Details of Synectics
Conceptual design 2: Details of Synectics method, Trigger Word technique, Checklist 
method, Trigger Word technique, Checklist 4
method, Examples
8 Conceptual design 3: Consolidation of ideas into concepts, e.g. with Morphological  4
charts. Use of TRIZ Contradiction or ideality to identify and resolve issues with concepts
9 ld
Conceptual design 4: Methods for simulation: analytical, virtual and physical 
h d f l l l l d h l 4
simulations, for evaluation or improvement.
10 Comparative evaluation and selection of concepts: ordinal and cardinal methods 4 2
TOTAL 42
Overview of Module 4
• Problem identification using requirement checklists
• Study of products and patents using Innovation Situation 
Questionnaire (ISQ)
• Steps for collating data from multiple sources into a 
stakeholder requirement list
stakeholder requirement list
• Translating stakeholder requirements into technical 
requirements
• Assigning importance
Assigning importance to requirements
to requirements

3
Main Stages of the Design Process
Main Stages of the Design Process
Activity Input/Output

SOCIETAL NEED
(OR IDEA)
TASK
CLARIFICATION

REQUIREMENTS

CONCEPTUAL
DESIGN

CONCEPT

EMBODIMENT
DESIGN

LAYOUT

DETAIL
DESIGN
PRODUCTION
INSTRUCTIONS

4
Task Clarification
• Purpose: Starting with perceived need, develop a requirements list

• Steps:
• Needs analysis – Establish current or latent economic existence of need (as a 
set of opportunities) using problems and opportunities based on knowledge of
set of opportunities) using problems and opportunities based on knowledge of 
• stakeholder/habitat study (who stakeholders are and what they need)
• market/business study (what the market is and what it can afford)
• product/technology study (competitive/related products/technologies)
d / h l d ( ii / l d d / h l i )
• Define stakeholder requirements of market segment – Identify what the 
market and its stakeholders might find attractive
• Define consumer‐specific technical requirements – Identify possible 
technical, economic, aesthetic etc. requirements for the product
• Assign importance –
g p Assess relative importance of the requirements
p q

• Outcome: A set of requirements with relative importance

5
Need to Requirements: A possible Route
Identify directions for 
what to observe
what to observe Observe habitat and 
Observe habitat and
activities to identify 
Identify further 
Use requirement problems Use ISQ
problems and 
Checklists, videos
U
Use role plays
l l questions to probe
questions to probe
Study product to 
identify specific 
problems
Use 
U
QFD Develop a list of  User interviews, surveys
Develop a list of testable,  stakeholder  Study habitat, and 
technical system  requirements interact with users to 
requirements identify specific 
Use requirement Checklists
Use Matrix method, Use problems
Objectives tree Problem Develop a I/O 
analysis Study market and 
y
Establish relative  statement of the  business to identify 
importance of technical  problem specific problems
requirements
Develop a Solution  Use market surveys
Use Problem Neutral Problem 
definition Statement (SNPS)
6
Outcome: A list of testable (where possible quantifiable), technical requirements with relative importance
Mission Statement (design brief) for a Project
(from Ulrich & Eppinger, 2003)
Mission statement (design brief) a common starting point for a product development
Mission statement (design brief) a common starting point for a product development 
project; it may also start from the scratch, e.g. by study of habitats
• Mission statement specifies the direction, but not a precise destination or particular way to proceed.
• Mission statement is an outcome from product planning activities
Mission statement is an outcome from product planning activities
• Mission statement for a cordless screwdriver project is given below:

Mission Statement: Screw Driver project
Product Description • Hand‐held, power‐assisted device for installing threaded 
fasteners
Key Business Goals • Product to be introduced in one year
• 60% gross margin
60% gross margin
• 15% share of cordless screwdriver market in 3 years
Primary Market • Do‐It‐Yourself customer

Secondary Market
Secondary Market • Casual customer
Casual customer
• Light duty professional
Assumptions • Hand held
• Power assisted
• Rechargeable battery
Rechargeable battery
Stakeholders • User
• Retailer
• Sales
• S i
Service
• Production
• Legal department
7
• Battery recycler
Product Study: ISQ

• What products to collect data on?
• Existing product(s), for cases where development team already has a product
• Products from competitors or products strongly related to the current effort
Products from competitors or products strongly related to the current effort
• Related patents

• What is Innovation Situation Questionnaire (ISQ)?
at s o at o S tuat o Quest o a e ( SQ)
• ISQ is a structured questionnaire for collection of product data
• For each type of product, one ISQ needs to be used
• Data collected can be used for multiple subsequent stages, e.g. ideation, 
Data collected can be used for multiple subsequent stages e g ideation
analysis, etc.

• Next slides provide an introduction to questions in ISQ
N t lid id i t d ti t ti i ISQ
• With an example

8
Femur
• FFemur of a patient has been fractured, and were stuck 
f ti t h b f t d d t k
together using two screws.
• The doctor practises a policy of waiting at least one year 
before removing a screw This assures that the break is
before removing a screw. This assures that the break is 
united.
• After the screw is removed the patient must wait for the 
whole in the bone to fill before walking without crutches.
• Though this patient was quite active and much younger 
than usual, the doctor stood by the usual policy since he 
Screws lacked data about younger.
• Earlier removal could have been easier; screws often left 
for 70 yr olds
• Two other options were offered for initial primary function 
of having the leg injury heal safely, but their secondary 
f h i th l i j h l f l b t th i d
effects were not acceptable. These are:
• Prolonged bed rest with leg traction or full body cast 
for 2 months
for 2 months
• No cast because the break did not go all the way 
through the bone; but an unusual stress or stumble 
Example from Terninko et al., 1998 could complete the break.

9
ISQ
• Features
– Helps reformulation and decomposition of the problem
– Use generic terms, record solutions generated during this
• Information about system to be improved; its environment
• Name: (if exists): 
• screw and screwdriver
• Primary function (use active verb, object
y ( j and constraint))
• Screw holds bones surfaces in position during healing
• Structure (current / desired): at static state plus drawings
• hollow shank head Allen wrench hole Allen wrench
hollow shank, head, Allen wrench hole, Allen wrench
• Functioning (behaviour): how it works to do primary function
• Screwdriver placed in the hole in screw‐head, turned in to place
• Screw cuts into the bones, and holds them together
• For removal, first tighten the screw to break the connection
• Then slowly turn it out
Then slowly turn it out

10
ISQ
• Information about system to be improved; its environment
y p ;
• System environment
• how it (should) interact with super‐system of which it is a part
• R
Removing screw from leg part of removing foreign materials 
i f l f i f i i l
from body
• With any other system with which it interacts, or in proximity
• The screw driver interacts with screw head and bone around
• Natural system surrounding it
• Need to be in a sterile environment and inside body with little
Need to be in a sterile environment and inside body with little 
space to manoeuvre

11
ISQ
• Available resources: free resources available for use
• Substance: materials
• Bone, tissues, moisture, metal, blood, calcium
• Field: energy/actions
Field: energy/actions
• Chemical reactions in the body, mechanical displacement, body 
temperature, friction, electricity and lights in the operating room
• F
Functional: what functions are available already
i l h f i il bl l d
• Body tries to remove foreign materials
• Informational: what information is available
• Time: What time is available
• Space: What space is available

12
ISQ
• Information about the problem situation
• Drawback(s) to eliminate or desired improvement(s)
• High frictional and cutting forces (for the thread) cause high torque 
requirements. The primary function is already performed. Subsequent
requirements. The primary function is already performed. Subsequent 
secondary function of removal has failed.
• Mechanism which causes the drawback to occur, if it is clear
• Bone has grown around and in the screw
Bone has grown around and in the screw.
• The bone has also bonded to the screw.
• Allen wrench hex hole in the screw head is not good for high torque.
• Now there is no hex hole but a near‐circular hole!
• The screw had is below the surface of the new bone growth.

13
ISQ
• Information about the problem situation
• History of development of the problem
• The doctor practises a policy of waiting at least one year before 
removing a screw. This assures that the break is united.
removing a screw. This assures that the break is united.
• After the screw is removed the patient must wait for the whole in the 
bone to fill before walking without crutches.
• Though this patient was quite active and much younger than usual
Though this patient was quite active and much younger than usual, 
the doctor stood by the usual policy since he lacked data about 
younger.
• Earlier removal could have been easier screws often left for 70 yr olds
Earlier removal could have been easier; screws often left for 70 yr
• Two other options were offered for initial primary function of having 
the leg injury heal safely, but their secondary effects were not 
acceptable. These are:
t bl Th
• Prolonged bed rest with leg traction or full body cast for 2 
months
• No cast because the break did not go all the way through the 
bone; but an unusual stress or stumble could complete the break
14
ISQ
• Information about the problem situation
• Other problems to be solved: modify direction of development?
• Tools which clamp to the head or core around the screw could work
• Coring device would leave a larger hole than the screw would have lef
Coring device would leave a larger hole than the screw would have lef 
otherwise if to could be removed as intended
• Bone removal weakens the cortex of the bone and requires a longer 
period of healing
period of healing
• A less invasive method is desired
• The screw could be left in place, patient brainwashed to believe it OK
• The patient could be given painkilling drugs during cold weather. 
However, evidence suggests pain in cold weather does not go away 
even after the screw is removed
• If original problem were not removing a screw but joining broken 
bones, glue could be used as an alternative: does not work alone

15
ISQ
• Changing the system
• Allowable changes: complete/major/small changes and why
• Only minimal changes: concern about patient’s well‐being
• Any tool for removal is possible
Any tool for removal is possible
• A new tool for removing the screw to be designed, but it must 
withstand high temperatures for sterilisation and fit space 
requirements to minimise invasiveness of the procedure
requirements to minimise invasiveness of the procedure
• Limitations to changing the system: what can/not be changed
• The environmental conditions cannot be changed (sterile inside body)
• Safety of patient and medical staff cannot be ignored

16
ISQ
• Criteria for selection of solution concepts
• Desired technological characteristics
• Reduce frictional forces, increase torque potential to the head, reduce 
effort of cutting new thread in bone
effort of cutting new thread in bone
• Effort required to turn the screw is decreased by reducing friction
• Is there an organic version of machine cutting oil?
• D i d
Desired economic characteristics
i h i i
• Desired timetable
• Expected degree of novelty
• Other criteria
• Time required to remove the screw
• Length of incision required to use the tool
Length of incision required to use the tool

17
ISQ
• History of attempted solutions to the problem
• Previous attempts to solve the problem: why they failed also
• Other systems with similar problem: Solved? Apply? Why not?
• Bolts rusted in metals: use an easy out for bolts. Drill a hole in the 
Bolts rusted in metals: use an easy out for bolts Drill a hole in the
exact centre of a right threaded bolt, turn a left threaded screw until 
tight and turning further will bring the bolt out.
• Wood screws with stripped heads: Use a hack saw to cut a new slot in 
Wood screws with stripped heads: Use a hack saw to cut a new slot in
the screw head.
• Nails driven in tree years earlier: new tree growth around the head of 
the nail can be removed
the nail can be removed.
• All these methods could work for screw in the bone, but since screw 
removal should occur in a sterile environment  as quickly as possible 
and without leaving any foreign materials in the leg or bone, drilling 
d ith t l i f i t i l i th l b d illi
and cutting should be minimised.

18
Requirements from Interviews etc.: General Steps
(adapted and extended from Ulrich & Eppinger, 2003)

1. Gather raw data from stakeholders, product study, market study
• Raw data in the form of answers from interactions with stakeholders:  interviews, focus groups, surveys etc.
Raw data in the form of answers from interactions with stakeholders: interviews focus groups surveys etc
• Raw data from market surveys, product study e.g. study of patents and of existing and competitors’ products
• Raw data from observations of habitat, products and processes
• Put this in a structured form such as the one shown in the next slide

2. Interpret raw data in terms of stakeholder needs
• Translate each statement/observation obtained as raw data into a need statement using the guidelines below
• Guideline 1: Express the need as what the product should do, and not how it might do this
• Guideline 2: Express the need as specifically as the raw data (to avoid loss of information)
Guideline 2: Express the need as specifically as the raw data (to avoid loss of information)
• Guideline 3: Use positive and not negative phrases wherever possible
• Guideline 4: Express the need as an attribute of the product wherever possible

3. Organise
g the needs in a hierarchy of needs
y
• Organise the needs into a set of primary needs, each characterised further with secondary (or tertiary) needs
• Primary needs the most general, secondary or tertiary are in more detail. A procedure for this is as follows:
• Step 1: Eliminate redundant statements; group the remaining statements according to their similarity
• Step 2: For each group decide on a label (a statement of need that generally describes the group)
Step 2: For each group decide on a label (a statement of need that generally describes the group)
• Step 3: Consider creating subgroups consisting of 2‐5 groups (only if the number of groups is 20 or more)
• Step 4: Review and edit the organised need statements to finalise the groups

19
Requirements from Interviews etc.: General Steps…
(adapted and extended from Ulrich & Eppinger, 2003)

4
4. Establish the relative importance of the needs
Establish the relative importance of the needs
• Outcome of this is a numerical importance weighting for a subset of needs.
• Use either consensus among team members or importance obtained from stakeholders/data
• Use matrix method taught later to establish the numerical value of importance

5. Reflect the results and the process
• Were all important types of stakeholders interacted with?
• Were all important market studies included?
• W
Were all important products analysed?
ll i d l d?
• Were all important habitats, their processes, people and products in action bserved?
• Were the needs beyond those related to existing products only identified (latent needs)?
• Was it possible to identify stakeholders that would be good participants in the subsequent development effort?
• Wh t k
What knowledge has been gained during this process? What have been the surprises?
l d h b i d d i thi ? Wh t h b th i ?
• Were everyone involved in the organisation developing the product involved who need to know about 
stakeholder needs been informed?
• How should the process be improved in future product development efforts?

20
Interpretation, Guidelines: Examples from Screwdriver Project
(from Ulrich & Eppinger, 2003)

Stakeholder Details, Type of stakeholder, Whether willing to follow up
Interviewer Details, Date of Interview
Question or Prompt Stakeholder Statement Interpreted Need
Typical uses I need to drive screws fast The screwdriver should drive screws faster than by 
hand
Likes‐current tool I like the pistol grip, feels the best The screwdriver should be comfortable to grip

Dislikes‐current tool Sometimes I strip tough screws The screwdriver should not strip screw heads

Suggested Improvements A point so I can scrape paint off screws The screwdriver should allow the user to work with 


screws that have been painted

Guideline Stakeholder Statement Need Statement –Right Need Statement –Wrong


What, not  Can’t you use protective shields The screwdriver battery should  The screwdriver battery contacts 
how around the battery contacts?  be protected against accidental  should be covered by a 
shorting protective shield
protective shield
Positive, not  Even if it rains, I still need to work  The screwdriver should operate  The screwdriver should not stop 
negative outside on Saturdays normally in the rain working  in the rain

An attribute I must be able to charge my  The screwdriver can be charged   An automobile cigarette lighter 


of the  battery from my cigarette lighter from an automobile cigarette  adapter should be able to charge 
21
product lighter the screwdriver battery
Grouped List of Customer Requirements: Screwdriver
(Adapted from Ulrich & Eppinger, 2003)

• The following gives an example of grouped list of requirements
• The groups can be further sub‐grouped
• Relative importance of the requirements in the groups can be assessed by the two methods shown later:
• Matrix method
• Objectives Tree

No. Product/Sub‐ Customer Requirement Importance: scale 1‐5


system/component 1: lowest, 5: highest
1 Screwdriver Should provide plenty of power to drive screws
provide plenty of power to drive screws 4

1.1 Screwdriver Should maintain power for several hours of heavy use low

1.2 Screwdriver Should be able to drive screws into hardwood medium

1.3 Screwdriver Should be able to drive screws faster than by hand high

2 Screwdriver Should be safe 5

2.1 Screwdriver Can be used on electrical devices high

2.2 Screwdriver Should not cut user’s hands high

… … …

22
Another Example List of Customer Requirements
(from Ulrich & Eppinger, 2003)

• Example for a Suspension fork
• A specialised
p bicycle components company interested in developing a front suspension fork
y p p y p g p
• For mountain bicycle market
• A component with high value for recreational cyclist
• The need analysis led to the following list of customer requirements:

N
No. Product/Sub‐
P d t/S b C t
Customer R
Requirement
i t IImportance:
t scale 1‐5
l 15
system/component 1: lowest, 5: highest
1 Suspension Should reduce vibration to hands 4

2 Suspension Enable high speed descents on bumpy trails 5

3 Suspension Should allow sensitivity adjustment 3

4 S
Suspension
i Sh ld b li h
Should be lightweight
i h 3

5 Suspension Should be easy to install 1

6 Suspension
p Should instill pride
p 5

7 Suspension Should not be contaminated by water 5

8 Suspension Should allow easy replacement of worn out parts 1

9 Suspension Should be safe in a crash 5

… … … 23
Developing Technical Requirements
(Adapted from Ulrich & Eppinger, 2003)
• Technical Requirements/Engineering Characteristics/Product Specification are 
different from Stakeholder/Customer requirements/needs in the following
• Stakeholder requirements have subjective quality: e.g. suspension should be easy to install
Stakeholder requirements have subjective quality: e g suspension should be easy to install
• Helpful in establishing issues of interest to stakeholders, but provide little guidance how to translate in a product
• Leaves large margin for subjective interpretation, need precise, measurable detail of what the product must do

• Technical requirements specify what to achieve in a product (not how to achieve)


Technical requirements specify what to achieve in a product (not how to achieve)
• For “Suspension easy to install” technical requirement may be “Average time to assemble fork to frame <1 min”
• Helpful in establishing issues of interest to stakeholders, but provide little guidance how to translate in a product
• Leaves large margin for subjective interpretation, need precise, measurable detail of what the product must do

• Steps for translating customer req. to technical requirements
1. Prepare the list of metrics: Most useful metrics are those that reflect most directly and precisely the degree to 
which the product satisfies the stakeholder requirements; Think of how to test whether and to what extent each 
stakeholder requirement is satisfied by the product; sometimes a requirement may need multiple tests and
stakeholder requirement is satisfied by the product; sometimes a requirement may need multiple tests and 
metrics to assess its degree of fulfilment Use the needs‐metric matrix in the next slide
2. Collect competitive benchmarking information: This is needed to ensure the product has a clear and distinct 
position in the market vis‐à‐vis its competitors; For each competitive product enter the values of the metrics
3. Set ideal and marginally acceptable target values: Ideal value is what the developer ideally wishes to achieve,
Set ideal and marginally acceptable target values: Ideal value is what the developer ideally wishes to achieve, 
while marginal value is the minimum it wishes to achieve; these are guided by how well the compatitors are 
doing in each such metric, how important the requirement representing the metric is, how capable the 
developer is in meeting this target, how suitable the metric is for the target market etc.
4. Reflect on the results and the process: Iterate if necessary before finalising the targets; consider whether the 
Reflect on the results and the process: Iterate if necessary before finalising the targets; consider whether the
targets are reflective of the true beliefs of the team, whether one should consider one or multiple products, 
whether any requirement is missing, etc.
24
• Use above steps to develop new products; QFD to incrementally improve existing products
Metrics for Technical Requirements: Suspension
(from Ulrich & Eppinger, 2003)

No Metric Competitor1  Competitor  New  New  How well  I


– Current  1‐how well product  product  new product m
value satisfies this  Ideal Value marginal  will satisfy  p
requirement value req .
1 Attenuation from dropout to  8 dB * >15 dB >10dB ** 4
handlebar at 10Hz
2 Maximum value from the 
M i l f th 36
3.6g * <3.2
32 <3.5
35 ** 5
“Monster” test
3 Damping coefficient adjustment 3
range
4 Total mass 3

5 Time to assemble to frame 1

6 Test for assessing instilling pride 5

7 Time in spray chamber without  5
water entry
8 Time to (dis)assemble for  1
maintenance; need for special tools
9 Japan industrial standards test 5

25
Competitive Benchmarks for Tech. Req: Suspension
(
(from Ulrich & Eppinger, 2003)
pp g , )

No Customer Requirement Metric Imp.


.
1 Should reduce vibration to hands Attenuation from dropout to handlebar at 10Hz 4

2 Enable high speed descents on bumpy trails Maximum value from the “Monster” test 5

3 Should allow sensitivity adjustment Damping coefficient adjustment range 3

4 Should be lightweight Total mass 3

5 Should be easy to install Time to assemble to frame 1

6 Should instill pride Test for assessing instilling pride 5

7 Should not be contaminated by water


Should not be contaminated by water Time in spray chamber without water entry
Time in spray chamber without water entry 5

8 Should allow easy replacement of worn out parts Time to (dis)assemble for maintenance and need  1


for special tools
9 Should be safe in a crash
Should be safe in a crash Japan industrial standards test
Japan industrial standards test 5

… …

26
Quality Function Deployment (QFD)
(Example and images from Roozenburg and Eekels, 1995)
(Example and images from Roozenburg and Eekels, 1995)

• A method for supporting Problem identification -> > requirement specification


• By identifying needs of the customer (customer requirements) and interpreting
these in terms of technical parameters and target values (technical requirements)

Nine Steps:
1. Make overview of product attributes reflecting customer need
2. Benchmark current product with competitive products
3. Determine project objectives: what your project is going to do
4. Describe new product in terms of techn. Parameters (eng. char.)
5. Translate project objectives into priorities for tech. parameters
6 Make nature/strength of interactions betn.
6. betn parameters explicit
7. Analyse current/competitive products to establish target values
8. Seek feasibility of intended improvements (benefit vs cost)
9. Develop plan for the product involved (targets, priorities, rel.)
27
House Of Quality

Interrelationship
between
Technical Descriptors

Technical Descriptors
(Voice of the organization)

uirements
uirementts
(Voice of the
e

Priioritized
Customer)

ustomer
ustomer

Relationship between
Requirements and

Requ
Requ

Cu
Cu

D
Descriptors
i t

Prioritized Technical
Descriptors
28
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)
Step 1: Make an overview of product attributes reflecting wishes of the customer

1. In terms which customers themselves use or formulate these


2. Using data obtained through customer/market research
3. Or documentation on complaints and repairs
4. Or trend analyses, earlier QFD analyses, etc
5
5. Output represents ‘voice
voice of the customer
customer’
6. Sub-steps:
1. Generate
2. Find relative importance/weight
3. select
4. classify (distribute over homogeneous categories)
5. structure (determine the means-end chain)
7 This can be subjective/internal,
7. subjective/internal or external (consumer research)
29
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)
Step 1: Make an overview of product attributes reflecting wishes of the customer

1. Determine what the customer considers important here


• Say: case should be easily transportable, open, close
• ‘Easily
Easily transportable
transportable’:: easily picked up
up, carried,
carried put down
• All these in cars, trains, bicycles
• g g factors indicate relative importance
Weighing p of these:5-pt
p scale
First level attributes:
• easy to carry (importance 2)
• easy to open (importance 4)
• easy to find contents (importance 4)
• adjustable capacity (importance 1)
j p y( p )
• easy to close (importance 3)
• durable (importance 5)
• stable when standing (importance 3)
stable when standing (importance 3)
• privately accessible (importance 2)
30
House Of Quality
For further details of the example, see: Roozenburg, N.F.M., Eekels, J. (1995) 
Product Design, Fundamentals and Methods, Wiley, Chichester, UK 

Interrelationship
between
Technical Parameters

Technical Parameters
(Voice of the organization)

uirements
(Voiice of the
ustomer))

Priioritized
Atttributes

ustomer
Product

Step 1 Relationship between


Product Attributes and

Requ
Attributes

Cu
Cu
P

P
Parameters
t

Prioritized Technical
Parameters
31
Quality Function Deployment (QFD)
((from Roozenburgg and Eekels, 1995)
, )
Step 2: Benchmark current product with competitive products
• Assumes that org. has a current product for specific target group
• Here, this is subjected to competitive bench-marking
• Earlier obtained product attributes used as evaluation criteria
1. Against
g each,, find if the current pproduct is better/worse/similar ((all these seen from the
customer’s perspective (not yours!)
2. A systematic comparison shows in which respects our product is and is not better than the
products of the competitors
• What the strong/weak points of our product to the customer
• The product evaluation quickly show potential for improvement
Our case is: Competitor’s case is:
• equally easy to carry (4) • equally easy to carry (4)
• less easy to open (3) • more easy to open (4)
• less easy to find contents (2)
y ( ) • less easy to find contents (4)
y ( )
• more adjustable capacity (3) • more adjustable capacity (4) 
• less easy to close (3)  • more easy to close (5) 
• more durable (4)
more durable (4) • less durable (1)
less durable (1)
• more stable when standing (4) • more stable when standing (3)
• equally privately accessible (3) • equally privately accessible (3)32
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

St 33: D
Step Determine
t i project
j t objectives:
bj ti what
h t your project
j t is
i going
i tot do
d

• Evaluation (step 2) provides insight into current problem areas


1. Combine performance data with rel. importance of attributes
2. Use this to identify opportunities for improvement
3. And determine project objectives (strategic choices)
• For each product attribute:
• A target value is laid down in score (on a 5-pt scale)
• For attributes requiring
q g no improvement
p target
g = eval score
• Improvement rate = target value/evaluation score
• Weight of attribute = improvement rate x rel. importance
• Normalise the weighting scores (last column)
To be improved:
• ease of opening of case (1.7)
• ease of closing of case (1.3)
• ease of finding contents (2.5) 33
Ifor the detailed example, see : Roozenburg, N.F.M., Eekels, J. (1995) 
Product Design, Fundamentals and Methods, Wiley, Chichester, UK  Step 3: Product 
E l ti
Evaluation
Target Improv weight Weight 
Step 2: Product Evaluation value  ement  %
rate

1 2 3 4 5
Eas to carr 2
Easy to carry 2 4 1 2 6
Easy to open 4 5 1.7 6.8 20
y
Easy to find contents 4 5 2.5 10 30
Adjustable capacity 1 4 1 1 3
Easy to close 3 4 1.3 3.9 12
Durable 5 4 1 5 15
Stable when standing  3 4 1 3 9
Privately accessible 2
Privately accessible 2 3 1 2 6
Our product 33.7 100
Competitior’s product

34
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

Step 4: Describe new product in terms of technical Parameters (eng. characteristics)

• The measurement units based on the spec of the earlier products


• Or derived byy operationalisation
p of p
product attributes
• Measurability of the parameters are seen as very important
• The example shows nine techn. parameters (columns of matrix)
• Matrix is called House of Quality (HOQ)
Technical parameters:
• volume of case (cm3)
• safety lock (type)
safety lock (type)
• empty weight (kg)
• opening steps (number)
• segments (number)
t ( b )
• material (type)
• angle of opening (degrees)
• closing force (N)
• wear of lock (number) 35
House Of Quality
For further details of the example, see: Roozenburg, N.F.M., Eekels, J. (1995) 
Product Design, Fundamentals and Methods, Wiley, Chichester, UK 

Interrelationship
between
Technical Parameters

Step 4
Step 4 Technical Parameters
Technical Parameters (Voice of the organization)

uirements
(Voiice of the
ustomer))

Priioritized
Atttributes

ustomer
Product

Relationship between
Attributes and

Requ
Cu
Cu
P

P
Parameters
t

Prioritized Technical
Parameters
36
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

Step
p 5: Translate project
p j objectives
j into priorities
p for technical p
parameters

• In a matrix, attributes (what) set against tech. parameters (how)


• This matrix is called Interaction matrix
1. For each cell, determine whether there is a relationship or not
2. And if yes, what the strength of that relationship is
3
3. Based on these,
these operationalise attributes,
attributes set parameter priority
• The speed with which contents of the case can be found relates strongly to
the number of segments in the case and less so to the volume and angle of
opening
i off the
th case
• Strong rel = 9; medium rel = 3; weak rel = 1
• Imp. of param-attribute rel = strength of rel x weight of attribute
• Priority of techn. Param = sum of these scores in its column
• Normalise priority
Priority techn. paramters:
y p
• no of opening steps (21%)
• number of segments (19%) 37
House Of Quality
For further details of the example, see: Roozenburg, N.F.M., Eekels, J. (1995) 
Product Design, Fundamentals and Methods, Wiley, Chichester, UK 

Interrelationship
between
Technical Parameters

Technical Parameters
(Voice of the organization)

uirements
(Voiice of the
ustomer))

Priioritized
Atttributes

ustomer
Product

Relationship between
Attributes and

Requ
Cu
Cu
P

P
Parameters
t
Step 5

Prioritized Technical
Parameters
38
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

Step 6: Make nature and strength of interactions between parameters explicit

• Changing a parameter can influence one/more other parameters


• I
Important
t t to
t makek nature
t andd strength
t th off interactions
i t ti explicit
li it
• In ‘roof of the HOQ’ these interactions can be laid down
• For example,
example the wear of lock is influenced by the closing force
1. Make explicit their nature (positive or negative; not in example)
2. Make explicit their strength (strong/weak/medium; in example)

39
House Of Quality
For further details of the example, see: Roozenburg, N.F.M., Eekels, J. (1995) 
Product Design, Fundamentals and Methods, Wiley, Chichester, UK 

Step 6
Interrelationship
between
Technical Parameters

Technical Parameters
(Voice of the organization)

uirements
(Voiice of the
ustomer))

Priioritized
Atttributes

ustomer
Product

Relationship between
Attributes and

Requ
Cu
Cu
P

P
Parameters
t

Prioritized Technical
Parameters
40
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

Step 7: Analyse current/competitive products to establish target values

• This comparison provides an insight into the possibilities for


improvement and help set target values to be pursued
1. Products are evaluated again, now against technical parameters
2. On the basis of the technical data and priorities of the technical
parameters, their target values are now determined
3. Based on these, operationalise attributes, set parameter priority

41
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

S 88: S
Step Seekk ffeasibility
ibili off iintended
d d iimprovements (b
(benefit
fi vs cost),
) not shown
h in
the example figures

• In general one will seek improvement of those parameters for


which competitive products score better than the own product
• Feasibility
F ibilit off an improvement
i t depends
d d on
• knowledge and skills of the people in the organisation
• available development capacity
• available production processes
• Example excludes this step
1. Estimate ‘degree of complexity’ or costs of improvement
2. Based on priority, feasibility, mutual rel between parameters,
decide which
hich parameters and target values
al es to be focused
foc sed on
42
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

Step 9: Develop plan for the product involved (targets, priorities, relationships)

1. Lay down target values (requirements) for technical paramters


• And
A d ttailored
il d tot development
d l t capacity
it available
il bl for
f the
th project
j t
• Parameters that do not qualify due to development capacity can
give direction for R&D activities in the long term
• Final result of QFD method is a development plan for product

43
For further details of the example, see: Roozenburg, N.F.M., Eekels, J. (1995) 
Product Design, Fundamentals and Methods, Wiley, Chichester, UK 

Interrelationship
between
Technical Parameters

Technical Parameters
(Voice of the organization)

ements
(Voice of the
omer)

Priorittized
butes

omer
duct

Relationship between

Custo
Prod

Require
Custo
Attrib

Attributes and
Parameters

Prioritized Technical
Parameters

Measurement unit cm3 type kg No. No. type deg N No.

Our product 400 p 2.5 6 4 r 81 0.50 5500 Step 7


Competitor’s  420 q 2 4 6 s 84 0.35 4000
product
Target value 400 p 2.5 2 8 r 81 0.50 5500 Step 9 44
Quality Function Deployment (QFD)
(from Roozenburg and Eekels, 1995)
(from Roozenburg and Eekels, 1995)

• Design team will pay attention to reduce 
Design team will pay attention to reduce
number of steps in opening the case with 
target value = 2
• A safety lock to close the case is also 
A f t l kt l th i l
required
• Reliability of lock set at target = 5500 mean 
time to failure rate
• This requirement should improve the ease of 
closing
• Durability will improve further and needs to 
be brought into notice
• Needs to make a new design of the interior 
of the case with target no of segments = 8
• Thus volume, angle, weight also to be taken 
Th l l i ht l t b t k
into account
45
Assessing Relative Importance: 
Three Methods
Three Methods
• Method1: Dividing requirements into two groups: demand and wish
Method1: Dividing requirements into two groups: demand and wish
• Demands: Requirements that cannot be dispensed with in the product, if these are not satisfied, the 
product has not reached the minimum level of satisfaction
• Wishes: Requirements not essential, but whose satisfaction would substantially improve the product
• Assign weights to the wishes using Matrix method and Objectives Tree method
• Use a two‐stage process when evaluating alternative solutions:
• Discard all solutions that do not satisfy the demands
• Among those that satisfy the demands, compare and select the one(s) that satisfies wishes best
Among those that satisfy the demands compare and select the one(s) that satisfies wishes best

• Method2: Treating all requirements as wishes
• Use Matrix method and Objectives Tree method to assign weights to all requirements
Use Matrix method and Objectives Tree method to assign weights to all requirements
• Compare all solutions using all requirements and their weights, and select the best

• Method3: Use QFD, which has a built in method of weighting
• Assign weights to customer requirements using Matrix method and/or Objectives Tree method
• Assign weights to technical requirements using the process of QFD

46
Matrix Method: 
Quantifying Relative Importance
Quantifying Relative Importance
1. Place criteria or requirements Ki  in rows and columns 4. Place in a   5. Distribute 
2
2. C
Compare each Ki in row with Kj
h Ki i ith Kj in columns assigning 
i l i i 1 10 i t
1‐10 point  100 points 
100 i t
values to Kj with respect to each Kj as follows: scale (if the  among the 
• Ki Better than Kj = 1; similar = .5; Kj worse than Ki = 0 sum in Step  criteria
3
3. Sum of values for Ki for all columns = its rel importance
Sum of values for Ki for all columns = its rel. importance 3 was 0
3 was 0, 
assign 01)

10  K1
10 K1 50 K1
k1 k2 k3 k4 Sum
S 09
k1 1 1 .5 2.5 (1) 08  K4 30 K4
07
k2 0 .5 .5 1.0 (3) 06
05
k3 0 .5 0 0.5 (4) 04  K3 15 K3
03
k4 .5 .5 1 2.0 (2) 02  K2 05 K2
47
01
Objectives Tree
(from Pahl and Beitz, 2007)
• The list of requirements have several groups to which they belong
• How to assign relative importance to each requirement belonging to a group
• If rel. importance of the general requirement representing the group is known
p g q p g g p
• and relative importance of all requirements within the groups is known

• This can be done using Objectives tree
• Shows requirements in a hierarchy of objectives representing the (sub‐)groups

• Procedure
• Let O1, O2 etc. be criteria representing general requirements
Let O1 O2 etc be criteria representing general requirements
• O11, O12 represent O1 at the next level of detail, O21, O22… represent O2 etc.
• O111, O112 represent O11 at next level of detail, etc. Low fuel 
•The Objectives tree is represented as below: consumption
O111
Low running costs
O11 Low oil 
O112
consumption
Economic 
efficiency of  O1 Low repair costs
O121
engine
O12
Weight of  O122
engine
O1 48
Objectives Tree
(from Pahl and Beitz, 2007)
• Procedure continued
• Let the sum of relative importance of all criteria at the top level be 1.0
• For each crietion, write name of criterion on top within the bubble (e.g. O111)
p ( g )
• Write its relative importance on below left, if total weight of the level of the bubble belongs were 1
• e.g. for O111, it is 0.67, and for O112 it is 0.33
• Calculate  its its absolute weight below right by
• multiplying  the factor below left for the bubble in the previous level of which it is a sub‐bubble
multiplying the factor below left for the bubble in the previous level of which it is a sub bubble
•With the relative weight of this bubble (below right)
• e.g. for O111, multiple 0.5 with 0.67 to find 0.34
• The process ensures that sum of absolute importance at each level  = 1
O111
0.67/0.34
O11
O112
0.5/0.5
0.33/0.16
O1 O121
1.0/1.0
/ O12 0.34/0.09
0.25/0.25
O122
0 33/0 08
0.33/0.08
O12
O123 49
0.25/0.25
0.33/0.08
Example Requirement List 1 
(from Pahl and Beitz, 2007)
(from Pahl and Beitz 2007)

• Method1: Dividing requirements into two groups: demand and wish
• Demands: Requirements that cannot be dispensed with in the product, if these are not satisfied, the 
Demands: Requirements that cannot be dispensed with in the product if these are not satisfied the
product has not reached the minimum level of satisfaction
Organisation Requirements List for a PCB positioning machine Issued on (Date), Page no.

Changes D or W Responsible


1. Geometry: dimensions of the test sample Batra’s group
D Length of circuit board 80‐650 mm
D Breadth of circuit board 50‐570 mm
W Height 0.1‐10 mm
2. Kinematics
31 August 2013 D Precise positioning of the test sample
W Minimum handling time
3. Forces:
D Weight of the test sample <1.7kg
4 Energy
4. Energy
D Electrical and or pneumatic (6‐8 bar)
50

Example Requirements List 2
(from Ulrich & Eppinger, 2003)

No Customer Requirement Metric New  New  Im


product  product  p.
Ideal Value
Ideal Value marginal
marginal 
value
1 Should reduce vibration to hands Attenuation from dropout to  >15 dB >10dB 4
handlebar at 10Hz
2 Enable high speed descents on  Maximum value from the “Monster”  <3.2 <3.5 5
bumpy trails test
3 Should allow sensitivity adjustment Damping coefficient adjustment 3
range
4 Should be lightweight Total mass 3

5 Should be easy to install Time to assemble to frame 1

6 Should instill pride Test for assessing instilling pride 5

7 Should not be contaminated by water 5

8 Should allow easy replacement of  Time to (dis)assemble for  1


worn out parts maintenance; need for special tools
9 Should be safe in a crash Japan industrial standards test 5

51

Potrebbero piacerti anche