Customer Requirements Into Ctqs

Case for Quality Library - Appendix B - Site navigation and instructions
If you see this icon by the AdvaMed logo on the page, that means this slide contains interactive, live links
Text In Blue If you see text in bold blue on the page, that means this text is an interactive link that will take you to another
place in the library.
If your computer mouse turns into a white pointed hand when you pass over a text or image on the page,
that means that text or image has an interactive link that will take you to another place in the library.
If you see this pointer finger icon by a text or image on the page, clicking on the pointer finger icon will
take you to the related interactive link in another place in the library.
Clicking on the YELLOW arrow icon will take you BACK to the last page you were on.
back
Clicking on the GREEN arrow icon will take you to the NEXT sequencial page from where you were on.
next
Clicking on the BLUE arrow icon will take you to the MAIN Table of Contents page in the current library
main area that you are in.
Clicking on the PURPLE location marker icon will take you to the Table of Contents (TOC)
for the particular company presentation that you are in.
toc
Clicking on the BLUE house icon will take you to the MAIN library page for the Case of Quality where you
home can access other library areas.
Requirements Into CtQs
Practices To Translate Customer
Category B:
How Do You translate Customer
Requirements into CtQs?
main
next
home
Practices to Translate Customer Requirements into CtQs
main back next home
Table of Contents
1. Quality Functional Deployment model, QFD
2. Requirements Cascade
3. Key Tools
4. Risk Management
5. Quality Tree model
6. Design and Process CTQs
7. CTQ Cascade model
8. CTQ Flow-down model
9. Managing Requirements
10. Critical Parameter Management Process Model
11. Critical Quality Attributes (CQA) Model
toc
next
back
main
home
Model
Quality Function Deployment
B
Company:  Medical Devices
 10,001 + employees
 Global
toc main back next home
Tool/Method/Example Summary
 Tool/Example Name: Quality Function Deployment (QFD)
 General Description:
Process to translate Qualitative Customer requirements into Weighted &
Prioritized Quantitative Design, Engineering and Manufacturing requirements
 Glossary of terms:
 House of Quality – Common QFD matrix used to translate Qualitative
Customer Requirements into Quantitative Design requirements
 VOC – Voice of Customer
 Typical Uses:
 New Product Development
 Relevant FDA Regulations:
 21 C.F.R. §§ 820.30(c) Design Input, (d) Design Output
F
Company:  Hospital & Health Care
 Global
 Tool/Example Name: House of Quality (HofQ)
HofQ is a template used to Cascade requirements when utilizing QFD, including:
 Customer requirements vs. Design requirements
 Design requirements vs. Engineering design
 Engineering design vs. Product Characteristics
 Product characteristics vs. Manufacturing operations requirements
 Manufacturing operations requirements vs. Production/ controls
 QFD, Quality Function Deployment, links the needs of the customer with product design,
manufacturing and service functions.
 Typical Uses:
 HofQ is utilized during the design process to better understand 'true' customer needs and what
‘value’ means from the customer's perspective
 Applicable throughout design controls (21 C.F.R. § 820.30)
A
 1001-5000 employees
 North America
 Tool/Example Name: QFD
QFD is used to translate customer needs (whats) into system parameters (hows)
and to identify those system parameters which have the biggest impact on
customer satisfaction
 House of Quality: Also called QFD [Quality Function Deployment] is tool used
to systematically translate customer requirements into quantitative
parameters that can be used to develop a concept and select a product
solution.
 Typical Uses:
 QFD is used translate needs statements into measureable requirements
 Applicable to (21 C.F.R. § 820.30)
A
 North America

A
 North America
Core Process Using Quality Function

Deployment
• House of Quality used to Cascade requirements
– Customer requirements vs. Design requirements
– Design requirements vs. Engineering design
– Engineering design vs. Product Characteristics
– Product characteristics vs. Manufacturing
operations requirements
– Manufacturing operations requirements vs.
Production/ controls
• Consider the “Other Voices” – Business & Process
A
 North America
QFD Tool example QFD HOUSE 1
ROOF: CORRELATION
P M Star rating of facilty
R E
event satisfaction score
E A
C
D S # customer complaints
T
I U
Q # cu feet per person
C R
'
T E # entrée options
S
I S
noise level
V
E = taste rating
Direction of
ROOF Improvement
CORRELATION ROOM 4 PREDICTIVE MEASURES =CTQ'S
Strong Synergy ++ RELATIONSHIP KEY
event satisfaction score

+
# customer complaints
Synergy Strong 9 Competition Key:
# cu feet per person

X
Star rating of facilty

Weak Conflict Medium 3
# entrée options
Machine Machine Machine
High Conflict XX Weak 1 1 2 3
taste rating
noise level
Importance
Customers' Desired Outcomes CUSTOMER PERCEPTION:
SATISFACTION LEVEL
Primary Want Secondary Want 1 2 3 4 5
Excellent
Compan
y Party good food 9 9 3 9 9 5.0
good music 3 3 3 9 9 3.0
able to converse without

screaming 1 9 3 9 1.0
easy to mingle around 9 3 9 1.0
CTQ Priority 55 18 45 9 30 90 72 0 0 0 0 0 0 0 0 0 0 319

HOW IMPORTANT
% Importance 17 6 14 3 9 28 23
A
 North America
The 5 Core Principles

1. Product design is simply the successive refinement of requirements
All specifications are simply means to communicate requirements to the next level of
hierarchy through an unbroken cascade.
2. Nothing is more important to success than managing requirements
Requirements must be complete, concise, unambiguous, measurable and wholly transparent
to all participants. They are the basis for schedules, reviews, testing, metrics, regulatory
submissions, customer satisfaction, and continuous improvement.
3. Mitigations and residual risks are requirements that must be managed
All failure modes, including use error & foreseeable misuse, must be traced to hazardous
situations & all hazardous situations must be traced to potential harms.
4. Evidence of conformance must identify the design configuration
Prototypes are cost, not progress. Learning is progress. Configurations used for verification
must include assessments showing the configuration tested is equivalent to the design being
released.
5. Program Management relies on standard work and objective metrics
# +Δ requirements, # +Δ protocols w/GR&R, # +Δ protocols run, % +Δ req verified, % +Δ
processes w/capability estimated, % +Δ processes w/capability verified. Chronological hours
since last formal customer feedback, fever chart $$ vs plan.
You are currently viewing a featured section of AdvaMed's Case for Quality Library.
To view AdvaMed's Case for Quality website, click HERE. To view the full slide deck of AdvaMed's Design Control recommendations, click HERE.
toc
next
back
main
home
Requirements Cascade
A
 North America
 Tool/Example Name: Requirements Cascade DHF/DMR
A graphical representation of a requirements cascade where parent requirements
are translated to child requirements via a transfer function.
 Transfer Function is a mathematical representation of the relationship
between a set of design factors and output variables.
 Typical Uses:
 Translates the sensitivities of the top-level requirement to lower-level
requirements through a relationship equation
 Applicable throughout the design control (21 C.F.R. § 820.30) and linkages to
DHF (21 C.F.R. § 820.30(j))
A
 North America
Requirements Cascade
y Requirement
f( )
x REQ 1 REQ 2 REQ 3
REQ 1-1 REQ 1-2 REQ 1-3 REQ 1-4 REQ 1-1 REQ 1-2
REQ 1-1 REQ 1-2 REQ 1-3

3 elements of a cascade
• Parent requirement [y]
• Child requirement [x] • Y Requirements guide concept
• Transfer function [f()] development and selection
• Concepts dictate transfer functions
From “The METHOD,” multiple copyrights
2006-2013 • Design worksheets determine Xs
A
 North America

toc
next
back
main
home
Key Tools
B
 Global
Key tools used By Phase

Concept Definition Development Qualification
– VOC • Monte Carlo • Critical Parameter • Critical Parameter
gathering Models Management Management
• KJ VOC • Design / • Design Capability
Analysis Application FMEA Assessment
• QFD / HoQ • Measurement • Mfg Capability
• Concept Eval Systems Analysis Assessment
& Selection - (MSA)
Pugh Matrix • Screening /
Advanced DOE’s
• Transfer Functions
: Defined, Ranked
& Prioritized
• Monte Carlo
simulations
I
 Global
 Tool/Example Name: Focus Groups, Feature Ranking, Online Survey, Feature Value-
Cost Analysis, Spider Maps, Conjoint Analysis
Tools to establish customer requirements and to rank them based on value points, cost
etc.
 Importance scaling, sorting and scaling, forced ranking, feature trade-off Scatter
Plot, “Must Haves”, “Jewels”, “Peanuts”, “Black Hole”
 Typical Uses:
 Tools to determine and analyze customer requirements (“VOC”)
 N/A
 These tie the VOC and marketing requirements to design inputs, including part risk
classification determination of CtQ in the design controls process.
I
Company:
 Medical Devices
 Global
How Do You Translate Customer

Requirements into CtQs?
Through The Use of State of the Art Tools for Each DfX Pillar &
A Phased Discipline approach to Design and Product Realization
DF “X”
DF CE = Customer Experience
DF R = Reliability
DF M = Manufacturability
DF S = Serviceability
DF C = Cost
I
 Global
 Tool/Example Name: Part Risk Classification, DFMEA, PFMEA, Pareto Analysis, Cause-and-Effect
Diagram, 2x5xWhy
Tools to classify parts as part of design outputs, identify critical to quality characteristics (CtQs),
flow down of CtQs for part and process to manufacturing and suppliers via design transfer.
 Product attributes critical to quality (parts, modules, features), Common failure modes, Top
risks of product failure
 Typical Uses:
 To identify critical to quality features or process characteristics that are critical determinants
of quality, failure modes, risk management and risk mitigation
 21 C.F.R. §§ 820.30, 820.50, 820.70
 These tie to design for customer experience, manufacturability, reliability, serviceability, and
value engineering. They also tie to process and product quality assurance, design innovation
and software quality assurance.
I
Company:
 Medical Devices
 Global
A Five Pillar QA Program Supports Good

Design and DfX Practices
Supplier assurance – how to work with suppliers & flow down
of CtQ’s
Process assurance – how to do process control and process
validation of automated test systems
Product assurance – how to conduct post market surveillance
and enhance the customer experience
Design cycle and innovation assurance – how to control design
processes (e.g., CMMI)
Software validation & assurance – how to ensure product SW
is robust and bug-free
toc
next
back
main
home
Risk Management
C
 Global
 Tool/Example Name: Risk Management, CTQ monitoring program
CTQ monitor program to predict and prevent unfavorable behavior
 Risk Management, Fault Tree Analysis, Design FMEA, Use FMEA, Critical To
Quality, In Process Monitoring, Response Flow
 Typical Uses:
 Patient Safety, Process Control, predict and prevent unfavorable behavior

 21 C.F.R. §§ 820.30 & 820.70
C
 Global
Risk Management is integrated into design

and development process
as part of the PLCP.
Product Hazard Analysis uses:

• Fault Tree Analysis
• Design FMEA
• Use FMEA
Level 3 represents unacceptable harm and

level 0,1, & 2 drive verification & validation
confidence statements which must be met.
Product Risk Index Matrix

5 1 2 2 3 3
Occurrence of Harm
4 1 1 2 3 3
3 0 1 2 2 3
2 0 0 1 2 2
1 0 0 0 1 2
1 2 3 4 5
Severity of Harm
C
 Global
Why? CTQ monitor program is recommended to predict and prevent

unfavorable behavior
What? CTQ is a potentially vulnerable failure mode or process that is

key to assure patient safety
CTQ Screening:
1. Perform a failure - Failure Mode with high severity and RI (RI: 2 /
mode screening Options Severity: 4/5) –link to Risk Management
according to the CTQ processes.
decision flow and
- Vulnerable process - High Scrap, NCEPs and
create a preliminary
list /or Complaints
- Potentially affects patient safety
 IPM
2. Discard and select
5. Follow up and CTQs with proper
update plan rationale
 Response Flow
4. Create an 3. Propose and
analyze ideas for
implementation plan
making more robust
for the ideas selected
each selected CTQ
C
 Global
Translating User Needs into Design Inputs

• Translates UserNeeds Needsinto into Design Inputs
• Translates User Design Inputs
o Assess Risks
Initiate Market Specification
o Develop
Initiate Market
productSpecification
specifications
o Develop product specifications
• Develop prototypes
•
o Identify possible design concepts, Test methods, design
o Identify possible design concepts, Test methods, design
prototypes, evaluate prototypes
prototypes, evaluate prototypes
• Develop equipment & process
• Develop equipment & process
o Assess process technology, develop and execute
o Assess process technology, develop and execute
equipment strategy
equipment strategy
• Define Supply Chain
• Define Supply Chain
o Define supplier plan, define concept builds, establish
o Define supplier plan, define concept builds, establish
supply chain strategy
supplyYouchain strategy
are currently viewing a featured section of AdvaMed's Case for Quality Library.
To view AdvaMed's Case for Quality website, click HERE. To view the full slide deck of AdvaMed's Design Control recommendations, click HERE.
F
 Global
 Tool/Example Name: Active Requirements Management (RM) Tool
This tool is utilized to ensure that the various (inputs) requirements are translated
into predictive, measureable performance values. These outputs can be tracked on
the CTQ Scorecard. The Risk Flow Down model is utilized to ensure that risks
associated with a specific requirement have the appropriate mitigations.
 Glossary of terms (specific to this tool/example):
 None unique
 Typical Uses:
 These tools can be utilized during the design process to ensure requirements
are adequately translated to quantify performance values.
 21 C.F.R. §§ 820.30 design controls & FDA Preamble – comment 72.
F
 Global
Requirements Management (RM) Tools to Support PDP
• Active RM allows flowing up process capability and

predicted performance to customer requirements
Market Req. Market Req.
Product Req. Product Req. + “Why” +

Performance
Assembly Req.
Assembly Req. + Performance
Component Req.
Component Req. +Performance
Process Req.
Process Req + “Why” + Capability
CTQ Flow down/up: CTQ Flow down/up:

What What, Why, How, Cost?
F
 Global

F
 Global
Risk Flow Down

• FMEA table generated
• Requirement at each level of the flow down can have a failure

mode.
– Causes and Effects linked
– Transfer Functions
• Risks are connected to requirements and to each other

toc
next
back
main
home
Quality Tree Model

D
 Global
 Tool/Example Name: Quality Tree
Shows the flow down of customer requirements into Functional requirements, Design,
and Process requirements in a hierarchical graphic format to help identify CTQs.
 Glossary Of Terms:
 Functional Requirements – description or metrics that the device’s needs to perform
(functional output needs).
 Design Requirements – description or metrics that the device’s design to meet the functional
requirements.
 Process Requirements -description or metrics relative to how the device’s is manufactured to
meet the design and functional requirements.
 Typical Uses:
 To help identify the flow down of requirements into critical design or process
outputs needed. CTQ’s and important aspects of the product are typically shown
on this chart.
 Relevant FDA Regulations :
 21 C.F.R. §§ 820.30 (b), (c), (d), (e), and (f)
D
 Global
Developing the Quality Tree

• Quality Tree should be developed by the team
• The project customer requirements, Engineering documentation and

knowledge of the team are key inputs
• In sequence the following activities should occur

 Critical Customer Requirements are identified by the end of the Feasibility
 Functional Requirements are identified by the end of the Feasibility
 Design Requirements are identified in the Development Stage or earlier
 Process Requirements are identified in the Development Stage or earlier
D
 Global
Quality Tree Format

D
 Global
Selecting Your CTQs

• Once the full Quality Tree has been completed, the
team needs to make intelligent choices on which
Characteristics should be labeled CTQ's.
• The Bottom line is assurance of quality as it relates
to Critical Customer Requirement(s)
• American Society for Quality (ASQ) defines
assurance of quality as the planned and systematic
activities implemented in a quality system so that
quality requirements for a product or service will be
fulfilled.
toc
next
back
main
home
Design and Process CTQs

E
 Global
Design and Process CTQs

Critical to
Customer Critical to Critical to
Process Requirements
Customer
(CtC)
Drivers
Design (CtD) Process (CtP)
VOC KOL Product Design Process

Development Specification Requirements
Market Review
Assessment Procedures/ Product Use Design Risk Process Risk
Key Activities
Cases Assessment Assessment

QFD
Prototype Design Process
Verification Validation
product
QFD
CtQ
E
 Global
Translating Customer Requirements to CtQs:

• The many customer requirements are distilled down to
the Critical to Customer (CtC) – VoC, KOL, Market
Assessments, product review
• The CtC are translated down to Key Drivers by the use of
DFQ and ranking
• Drivers are translated into Product Requirements
• Product Requirements are translated into Product
Specifications (Critical to Design – CtD).
• CtD are approved by the Project Approval Board and
reviewed at Gates 2 through 4 and During Design Reviews
• CtD will drive the process development and the Critical to
Process (CtP) parameters to assure product design
E
 Global
CtQ in Product Development

toc
next
back
main
home
CTQ Cascade Model

F
 Global
CTQ Cascade
Customer Needs and Requirements

User Issues
User Needs/Requirements
Functions to Meet User Needs

Concepts to Meet the Functions
F
 Global
CTQ Cascade
Product Requirements
Measureable Performance
Requirements
Architecture: Subcomponents?
Attributes/ Properties/ Specifications

F
 Global
CTQ Cascade
Raw Material Properties,

Specifications , Sources of Variation
Critical Process Variables,
Requirements
Equipment Requirements,
Sources of Variation
F
 Global
CTQ Cascade
Risk Mitigation Strategies and Controls
Risks
Mitigations, Controls
Improve Chances of Success Proactively

F
 Global
CTQ Cascade

Verification and Validation
Specifications, Critical Testing

F
 Global
CTQ Cascade

Verification and Validation
toc
next
back
main
home
CTQ Flowdown Model

G
 5001-10,000 employees
 Global
Critical to Quality (CTQ) Flow down

Voice of
Customer
Function
Parts
Dimensions
Capability
Match Capability Vs. Goal
Launch
G
 5001-10,000 employees
 Global
CTQ Flow Down

Post Market Clinical Marketing Focus Groups Repairs Complaints Regulatory
Surveillance
Therapy system shall deliver the prescribed negative pressure to the wound site when
Voice of the Customer powered on
(User needs)
Access Risk level
Technical Requirements Therapy unit shall maintain pressure within ±x mmHg of target pressure from Top Down*
and Usability *
perspective
Part Drawings – (Link to Therapy Unit, Canister, Dressing (e.g. drape), System Interactions (sub-assembly) Link to DFMECA
for Risk
DFMEA for Risk)
Carry over to
Pump Flow rate Drape adhesive properties Canister – Unit interface PFMEA
CTQ Characteristics Pump Diaphragm characteristics
Link CTQs identified to Risk
•Top Down: evaluates the potential risks from the system level perspective, before finalizing the design. Mitigations from Top down should be used as an input to
the design. 48
• Usability risk analysis: evaluates the potential hazards related to the use or misuse of the product.
toc
next
back
main
home
Managing Requirements
H
 Global
Managing Requirements
Component
Reqs
Design Review
Trace to Design
Outputs
Process
Planning
Matrix
Critical Parameter Management

Process Model
toc
main
back
next
home
K
 Global
CPM Process Model – Value Stream

Input
Customer
Feedback
Loops
Input
PDP Process
Design
Product UFMEA Material
Qualifications
Specifications DFMEA Specifications
Process Development
& Validations
Process & Process

Customer
Assembly PFMEA Qualifications
Complaints
Specifications & Validations
Risk Identification
Non-
Inspection Scrap Testing
conformance
Results Reporting Results
Reporting
& Mitigation
Control & Monitoring
Critical Parameters are identified in Design and translated
throughout the QMS and ultimately is used to focus control &
monitoring and prioritized feedback loops.
K
 Global
CPM Process Model – Identification Targets - QE

Customer Each Quality Engineer has
been retrospectively
Input
Design
identifying their
Product
Specifications
UFMEA
DFMEA
Material
Specifications
Qualifications
& Validations Critical Parameters for their
assigned products
Process & Process
Customer
Complaints
Non-
The identified Critical Parameters are

conformance
Reporting
then:
1. Assessed for capability Starting with complaints and
2. Mitigations defined working to the left, critical
3. Improvement plans created safety, performance and
4. Controls & Monitors implemented compliance parameters
identified
K
 Global
CPM Process Model – Identification Targets - DA

Customer In a Prospective manner –
the development team, led
Input
Design
by DA, identifies their Critical
Product
Specifications
UFMEA
DFMEA
Material
Specifications
Qualifications
& Validations Parameters and rigorously
tests them.
Process & Process
Customer
Complaints
Starting with Customer Input

and working to the right, Inspection
Results
Scrap
Reporting
Testing
Results
Non-
conformance
Reporting
critical safety, performance

and compliance parameters The identified Critical Parameters are then:
1. Assessed for capability
identified
2. Risk assessed & Mitigations defined
3. Specifications created
4. Designs made robust
Transfer Function
5. Tested and optimized
CPyoutput = f(xinput) 6. Deployed to commercialization
K
 Global
CTQ’s (How Determined)

• Review of field complaints for high severity items
impacting the patient.
• Consulted with Product Surveillance for assistance with
interpreting complaints.
• Cross-functional review of what constitutes high severity
complaints.
Customer
Input
Design
Product UFMEA Material
Qualifications
Specifications DFMEA Specifications
& Validations
Process & Process

Customer
Complaints
Non-
conformance
Reporting
K
 Global
Example Product Deployment of CPM

• Critical Product and Process Parameters
 Capability and state of control
• Gap analysis
 Where we are now
 Improvement plans to achieve desired “State of Control”
• CPM will involve a reoccurring review of the

critical parameter and controls with
adjustments made as necessary.
toc
next
back
main
home
Critical Quality Attributes Model

J
 Global
Identification of Critical Quality

Attributes
1. Design Controls process (per QSR): Ensures that
Design
Design Inputs (including DI acceptance criteria) are
developed
developed that comprehensively meet the
equirements of the Intended Use and User Needs.
rrequirements
22.. Risk Management process (per ISO 14971): R eviews

Reviews
Design
Design Inputs to ensure that sufficient Design
Design Inputs
have
have been identified to address
address identified
identified Hazards.
33.. Design Con trols process ((per

Controls per QSR): Ensur es that
Ensures
De sign Outputs (including quality attributes) are
Design
developed
developed that comprehensively meet the Medical
requirements
requirements of the Design Inputs. Device
Hazards
Figure 2: Risk Management focus

J
 Global
Critical Quality Attributes

 Critical Quality Attributes are product design specifications and are documented in
the DHF as:
1. Design input acceptance criteria (in the Design I/O document) and/or
2. Design output specifications/tolerances (in the DMR)
DMR (Design)
1. Product drawings
“Refinement of Design Input” 2. Label text & artwork
(Product performance criteria) 3. Material specs
DIO Document 4. Software code
5. Product test specs
Intended Use/ DI # Design DI Acceptance criteria DI Acceptance DO # Design Outputs
User Need Input criteria Justification (PN/ Feature) Design Spec/tolerance 1-1-1-1
Design Spec/tolerance 1-1-1-2
1 1-1 xxxx Design Input Acceptance xxxx xxxx 1-1-1 Design PN/Feature 1-1-1 Design Spec/tolerance 1-1-1-3
criteria 1-1
1-1-2 Design PN/Feature 1-1-2
Design Outputs
J
 Global
Example Critical Quality Attributes

Design Input Acceptance Criteria Design Output Specs/Tolerances
1. Implant tip radius, Internal

 Implant fixation force 1. Implant thickness, Device color component position
 Implant actuation 2. Product identification text on device 2. Warning text on device and IFU
sound 3. Implant material 3. Internal component material
 Drill heat 4. Software platform/revision 4. Software code for voltage
(temperature) 5. Drill torque, Voltage output, Sterility calibration
 Drill metal debris rate Assurance Level, Device weight, 5. Internal power supply test
Video resolution voltage, Software checksum,
Implant hardness
DIO Document
DMR (Design)
1. Product drawings
2. Label text & artwork
3. Material specs
Manufacturing has visibility of all 4. Software code
product design specs in the DMR 5. Product test specs
Design Outputs
J
 Global
Critical Quality Attributes

– Critical CQA’s are critical product design specifications
• Critical CQA’s are product design specifications where being in-spec is considered “critical”
for product quality
– Note: Expectation is that manufactured product will meet all product design
specifications (quality attributes) in the DMR, whether designated as “critical” or not
• In accordance with QSR Subpart G, Production and Process Controls
• The designation of a product design specification as “critical” merely conveys that the consequences of
being out of spec are severe, so additional focus is prudent during manufacturing, verification, etc.
Critical
Quality
Quality
Attributes Attributes
Verify (Inspect) or Validate Verify (Inspect) or Validate

with more rigor
J
 Global
Identification and Classification of Critical CQA’s

J
 Global
Identify Critical CQAs

For a given quality attribute, if a significant departure from design tolerance
is predicted to result in unacceptable product quality (i.e., major customer
dissatisfaction and/or unacceptable risk), that quality attribute is identified
as a CQA.
Note: For most quality attributes, a large, unlimited departure from design
tolerance inevitably results in unacceptable product quality , but this does
not imply that most quality attributes are CQA’s. The main purpose of CQA
identification is to highlight those quality attributes for which a slight
departure from design tolerance has unacceptable consequences.
J
 Global

For CQA identification purposes, the concept of a “significant departure”
from design tolerance is interpreted as follows:
• For continuous quality attributes with linear design tolerance, a

significant departure from design tolerance should be defined as
departure up to a factor of 2 from design tolerance (i.e., up to a 100%
departure from design tolerance).
Reference: Juran, J.M. and Godfrey, A. B. (Eds.), Juran’s Quality Handbook, 5th edition,
New York: McGraw-Hill (1999), Section 22.6-22.7
5.30
Length
Design tolerance
5.20 5.40
5.10 5.50
Significant departure from
Design tolerance
(for CQA identification)
Figure: Significant departure from a linear design tolerance

J
 Global

• For discrete quality attributes, any departure from design tolerance may
be considered a significant departure, but project team personnel should
subjectively decide what constitutes a significant departure.
Example: For an implant, the color specification “green” might be

considered a CQA if manufacturing that implant as any color other than
green (e.g., “blue” or “red”) is predicted to result in unacceptable product
quality.
J
 Global
toc main back home

For CQA identification purposes, the consequence of a significant departure from
design tolerance (i.e., the failure effect) is determined using any of the following
methods or combination of methods:
1. Judgment of engineering, quality assurance, clinical affairs, and/or marketing
personnel on the project team
2. Inspection of Risk Management File info
3. Inspection and analysis of field data, test data, theoretical models, NC/CAPA
information, standards, regulations, and/or literature for similar products

Customer Requirements Into Ctqs

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Customer Requirements Into Ctqs

Uploaded by

Copyright:

Available Formats

Case for Quality Library - Appendix B - Site navigation and instructions

main back next home

toc main back next home

toc main back next home

toc main back next home

toc main back next home

toc main back next home

Core Process Using Quality Function

toc main back next home

QFD Tool example QFD HOUSE 1

CORRELATION ROOM 4 PREDICTIVE MEASURES =CTQ'S

Strong Synergy ++ RELATIONSHIP KEY

event satisfaction score

# cu feet per person

Star rating of facilty

able to converse without

CTQ Priority 55 18 45 9 30 90 72 0 0 0 0 0 0 0 0 0 0 319

toc main back next home

The 5 Core Principles

toc main back next home

toc main back next home

REQ 1-1 REQ 1-2 REQ 1-3

toc main back next home

toc main back next home

Key tools used By Phase

toc main back next home

toc main back next home

How Do You Translate Customer

DF CE = Customer Experience

toc main back next home

toc main back next home

A Five Pillar QA Program Supports Good

toc main back next home

 Relevant FDA Regulations:

toc main back next home

Risk Management is integrated into design

Product Hazard Analysis uses:

Level 3 represents unacceptable harm and

Product Risk Index Matrix

toc main back next home

Why? CTQ monitor program is recommended to predict and prevent

What? CTQ is a potentially vulnerable failure mode or process that is

toc main back next home

Translating User Needs into Design Inputs

toc main back next home

toc main back next home

Requirements Management (RM) Tools to Support PDP

• Active RM allows flowing up process capability and

Market Req. Market Req.

Product Req. Product Req. + “Why” +

CTQ Flow down/up: CTQ Flow down/up:

toc main back next home

toc main back next home

Risk Flow Down

• Requirement at each level of the flow down can have a failure

• Risks are connected to requirements and to each other

Quality Tree Model

toc main back next home

toc main back next home

Developing the Quality Tree

• The project customer requirements, Engineering documentation and

• In sequence the following activities should occur

toc main back next home

Quality Tree Format