Quality by Design, Reliability and Risk

Introduction

Quality is most effectively achieved before production begins. Inspection can detect some defects, but it cannot reliably remove the causes of poor design, unsafe operation, excessive variation, or premature failure. Quality by design therefore treats customer requirements, technical performance, reliability, safety, maintainability, regulatory compliance, and life-cycle cost as design responsibilities rather than downstream correction activities.

This chapter examines an integrated set of methods for designing quality into products, services, and processes: quality function deployment (QFD), design reviews, failure mode and effects analysis (FMEA), fault-tree analysis (FTA), mistake-proofing, robust design, reliability analysis, and risk-based decision-making. These methods are complementary. QFD translates stakeholder needs into design requirements; reviews provide disciplined decision gates; FMEA and FTA identify and prioritize failure risks; mistake-proofing prevents human error; robust design reduces sensitivity to variation; and reliability analysis estimates performance over time.

The central managerial principle is that risk should be addressed at the earliest feasible point in the life cycle. A design change made during concept development is generally cheaper and more effective than a corrective action made after launch, field failure, or regulatory intervention.

Learning objectives

By the end of this chapter, the reader should be able to:

1. Explain how quality by design differs from inspection-based quality control.
2. Construct and interpret the principal logic of a QFD House of Quality.
3. Plan effective design reviews and distinguish verification from validation.
4. Apply FMEA and FTA to identify causes, effects, controls, and critical risks.
5. Explain mistake-proofing, robust design, and reliability engineering principles.
6. Calculate basic reliability measures under stated assumptions.
7. Make risk-based decisions using severity, occurrence, detectability, and uncertainty.
8. Evaluate the governance, ethical, and operational limitations of design-risk methods.

1. Quality by design as a life-cycle discipline

Quality by design (QbD) is the systematic translation of intended use and stakeholder needs into measurable product, service, and process characteristics. It incorporates the voice of the customer, statutory obligations, scientific or engineering knowledge, process capability, and life-cycle learning.

A useful life-cycle sequence is:

Need identification → concept definition → requirements → architecture → detailed design → verification → validation → launch → operation and maintenance → feedback and redesign.

Quality is not identical to conformance. Conformance asks whether an output meets specified requirements. Quality by design also asks whether the requirements are appropriate, whether users can achieve the intended outcome, whether failure consequences are acceptable, and whether the system remains effective under realistic variation.

Three distinctions are important:

• Customer satisfaction: the perceived value and suitability of the offering.
• Conformance: compliance with stated requirements.
• Fitness for use: the ability to perform its intended function safely and consistently in its actual context.

A design may conform to an incomplete specification and still fail in use. Conversely, a robust design anticipates foreseeable misuse, environmental variation, maintenance conditions, supply changes, and human limitations.

Prevention, appraisal, and failure costs

The prevention–appraisal–failure framework classifies quality-related costs. Prevention includes design analysis, training, supplier qualification, and mistake-proofing. Appraisal includes testing, inspection, and audits. Internal failure includes scrap and rework; external failure includes warranty claims, recalls, injuries, service disruption, and loss of trust. Investment in prevention does not eliminate all appraisal or failure costs, but it aims to reduce total cost and risk over the life cycle.

2. Quality Function Deployment

Quality Function Deployment is a structured method for converting the voice of the customer into prioritized technical requirements and deployment actions. Its best-known tool is the House of Quality, although QFD can extend through several linked matrices: product planning, part deployment, process planning, and production planning.

2.1 The voice of the customer

Customer information should be collected from interviews, observation, complaints, service data, market research, regulatory requirements, and expert users. Statements such as “the machine should be easy to use” are valuable but incomplete. They should be transformed into measurable requirements, for example:

• setup time no greater than five minutes;
• error recovery possible without specialist assistance;
• operating noise below a specified limit;
• availability above a defined target.

The transformation must preserve customer intent without prematurely prescribing a technical solution.

2.2 Main elements of the House of Quality

A common prioritization calculation is:

Here, P_j is the unnormalized priority of technical characteristic j, I_i is the importance rating of customer requirement i, and R_ij is the relationship weight between requirement i and characteristic j. The relationship scale must be defined in advance, for example 9 for strong, 3 for moderate, 1 for weak, and 0 for none. The calculation assumes that the ratings are ordinal approximations used for prioritization, not precise measurements of utility.

If customer importance ratings are normalized, the relative priority can be expressed as:

where W_j is the proportionate priority and m is the number of technical characteristics. The values sum to 1 when at least one priority is positive.

The roof is particularly important because improving one characteristic may damage another. For example, increasing structural thickness may improve strength but increase weight and cost. Such conflicts should be resolved through trade-off analysis rather than hidden in separate departmental decisions.

2.3 Worked QFD illustration

Suppose three customer requirements have importance ratings 5, 4, and 3. Two technical characteristics have relationship weights as follows:

The priorities are:

P_A = (5×9) + (4×1) + (3×3) = 63

P_B = (5×3) + (4×9) + (3×1) = 54

Thus Characteristic A receives the higher calculated priority, although the result depends on the validity of the ratings and relationship judgments. QFD does not replace engineering judgment; it makes assumptions and trade-offs visible.

3. Design reviews, verification, and validation

A design review is a planned, multidisciplinary evaluation of a design against requirements, risks, interfaces, resources, and readiness for the next stage. Effective reviews are not ceremonial presentations. They are evidence-based decisions with documented actions, owners, due dates, and escalation rules.

Typical review stages include concept review, preliminary design review, critical design review, production-readiness review, and post-launch review. The exact names vary by industry.

Verification and validation

• Verification: Are we building the product or process right? It evaluates conformity to specified requirements through inspection, analysis, testing, or demonstration.
• Validation: Are we building the right product or process? It evaluates fitness for intended use under realistic or representative operating conditions.

A design can pass verification yet fail validation if the requirements were incomplete, the operating environment was unrealistic, or human interaction was neglected.

A mature review examines:

1. traceability from stakeholder needs to design outputs;
2. safety and regulatory requirements;
3. interfaces and boundary conditions;
4. tolerance and measurement assumptions;
5. supplier and material risks;
6. maintainability and service access;
7. software, cybersecurity, and data dependencies where relevant;
8. verification evidence and unresolved anomalies;
9. residual risk and acceptance authority.

Independence is valuable. The designer should explain the design, but a reviewer who is sufficiently independent should challenge assumptions and evidence. Reviews should also avoid the “single-point estimate” problem: ranges, confidence, sensitivity, and uncertainty should be discussed where decisions depend on forecasts.

4. Failure Mode and Effects Analysis

FMEA is a bottom-up, team-based method that examines how an item, process step, or system function could fail, what effects would result, what causes are plausible, and how current controls address the risk. Design FMEA focuses on product or system design; process FMEA focuses on manufacturing or service delivery; system FMEA examines interactions and functions at a higher level.

A typical FMEA records:

• item or process function;
• failure mode;
• local, next-level, and end effect;
• severity;
• potential cause or mechanism;
• occurrence or likelihood;
• prevention controls;
• detection controls;
• detectability;
• recommended action;
• responsible owner and completion evidence.

4.1 Risk Priority Number and its limitations

A traditional FMEA uses severity S, occurrence O, and detectability D, often each scored from 1 to 10:

The Risk Priority Number is dimensionless and useful as a screening aid. It assumes that the scales are meaningfully defined and that multiplication is an acceptable aggregation rule. It should not be treated as a probability, expected loss, or universal ranking. Different combinations can produce the same RPN despite very different consequences. For example, a catastrophic but rare failure may deserve priority over a frequent minor inconvenience even if both have equal RPNs.

Better practice supplements RPN with severity thresholds, action-priority categories, risk matrices, quantitative consequence analysis, and explicit consideration of uncertainty. Any score should be supported by evidence rather than negotiation among the loudest participants.

4.2 FMEA example

Consider a medical-device charging process. A failure mode is “battery not fully charged before use.” Its effect may be loss of device availability; a cause may be an incorrectly seated connector. Prevention controls could include keyed connectors and a charging procedure. Detection controls could include a charge-status indicator and an automated functional test.

If a team assigns S=8, O=4, and D=6, then:

RPN = 8×4×6 = 192

An effective action would preferably reduce occurrence or eliminate the cause, such as a keyed connector, rather than merely adding a final inspection. After implementation, the team must reassess the scores using evidence and record residual risk.

5. Fault-tree analysis

FTA is a top-down, deductive method that begins with a defined undesired top event and decomposes it into combinations of lower-level events using logical gates. It is particularly useful for safety, availability, and system-level interactions.

An OR gate indicates that any input event can produce the output. An AND gate indicates that all input events are required, subject to the modeled assumptions. Basic-event definitions must be precise; vague events produce misleading trees.

For independent events A and B:

The first expression is the probability of at least one event occurring. The second applies to independent events occurring together. If events are dependent, common-cause or conditional-probability methods are required; blindly multiplying probabilities is invalid.

For rare, independent events, P(A OR B) ≈ P(A)+P(B) because the product term is small. This approximation must be checked against the required accuracy.

FTA complements FMEA. FMEA asks, “How can this item fail and what happens?” FTA asks, “What combinations can produce this top event?” FTA is effective for common-cause analysis, redundancy assessment, and safety-case reasoning, but it can omit unanticipated events, human-system interactions, or poorly defined boundaries.

6. Mistake-proofing and human-centered design

Mistake-proofing, or poka-yoke, prevents an error from occurring or makes it immediately apparent before harm or downstream defect occurs. Examples include keyed connectors, asymmetrical fixtures, presence sensors, interlocks, barcode verification, software input constraints, and a requirement to complete a checklist step before proceeding.

There are three broad levels:

1. Elimination: remove the opportunity for error.
2. Prevention: make the error impossible or highly unlikely.
3. Detection: identify the error immediately and stop or contain the process.

Detection is generally weaker than elimination because it depends on timely response. However, prevention may be costly or may constrain flexibility. Good design balances safety, usability, maintainability, and operational practicality.

Human error should not automatically be attributed to carelessness. Designers should examine confusing interfaces, fatigue, workload, ambiguous instructions, poor lighting, incompatible incentives, and organizational conditions. Ethical quality management avoids punitive responses when system design is the dominant cause.

7. Robust design and variation management

Robust design seeks performance that is relatively insensitive to noise factors such as temperature, material variation, operator technique, wear, and environmental conditions. It does not mean eliminating all variation; it means designing so that unavoidable variation produces acceptable outcomes.

A response model can be represented as:

where y is the performance response, x represents controllable design or process factors, and z represents noise factors. Robust design chooses x so that the response meets requirements across the plausible range of z.

Designers may use designed experiments, tolerance analysis, simulation, parameter design, and control-factor/noise-factor studies. A useful engineering objective is to minimize both mean deviation from target and sensitivity to noise. The specific loss function must be selected for the application; there is no universal robust-design formula.

Taguchi loss concept

For a nominal-the-best characteristic, a quadratic loss model is often written:

Here, y is the measured performance, T is the target, and k converts squared deviation into monetary or consequence units. The model assumes loss increases symmetrically and quadratically around a target. It is a conceptual approximation, not a claim that every customer experiences exactly quadratic loss. For smaller-the-better or larger-the-better characteristics, different formulations are needed.

Robust design also requires measurement-system adequacy. A team cannot distinguish design variation from measurement error unless the measurement process is known to be sufficiently capable.

8. Reliability engineering

Reliability is the probability that an item performs its required function for a specified time under stated conditions. The definition requires four elements: function, time, operating conditions, and failure criterion.

Let T be a nonnegative lifetime random variable. The reliability function is:

The failure distribution function is:

The probability density, when it exists, is f(t) = dF(t)/dt. The hazard rate is:

It represents the instantaneous failure rate conditional on survival to time t. It is not generally the same as the proportion failing per unit time in the original population.

Exponential reliability model

If failures occur with a constant hazard rate λ and the model assumptions are reasonable, then:

The mean time to failure is:

For repairable equipment, mean time between failures (MTBF) is commonly used, but its interpretation depends on the operating and repair definitions. MTTF for nonrepairable items and MTBF for repairable systems should not be used interchangeably.

For a series system, where all components must operate and component failures are independent:

For an active parallel system that operates if at least one independent component operates:

These formulas do not automatically account for common-cause failures, imperfect switching, standby behavior, dependence, maintenance, or shared environments.

Worked reliability example

Two independent components in series have reliabilities 0.98 and 0.95 over a specified mission time. The system operates only if both operate:

R_s = 0.98×0.95 = 0.931

Thus system reliability is 0.931, or 93.1%. The result shows why a system can be materially less reliable than its strongest component. If the components were dependent because both experienced the same overheating condition, the multiplication assumption would be inappropriate.

Reliability growth requires disciplined failure data, root-cause correction, controlled design changes, and retesting. Simply testing more units without correcting failure mechanisms does not create reliability growth.

9. Risk-based decision-making

Risk is commonly understood as the effect of uncertainty on objectives. In operational quality, risk analysis should consider at least likelihood, consequence, exposure, detectability, uncertainty, and the effectiveness of controls. A numerical risk estimate is useful only when its definitions, evidence, and decision thresholds are transparent.

For discrete events, an expected-loss model may be used:

where p_i is the probability of scenario i, C_i is its consequence measured in consistent units, and E(L) is expected loss. The model assumes the scenarios are sufficiently defined and that consequences can reasonably be represented in the chosen units. It should not be used to justify trading away non-negotiable safety or legal requirements merely because expected monetary loss is low.

A sound risk process includes:

1. define the decision, system boundary, and affected stakeholders;
2. identify hazards, failure modes, and credible scenarios;
3. estimate likelihood and consequence using evidence and ranges;
4. analyze uncertainty and sensitivity;
5. select controls according to the hierarchy of controls;
6. assign risk ownership and acceptance authority;
7. verify control effectiveness;
8. monitor leading and lagging indicators;
9. review assumptions after changes, incidents, or new information.

The hierarchy of controls generally favors elimination, substitution, engineering controls, administrative controls, and personal protective equipment in that order, although sector-specific rules may vary. Risk acceptance must be authorized at the appropriate level and must never be concealed through optimistic scoring.

10. Integrated application: illustrative case of an automated infusion pump

This is a fictional illustrative case, not a report of an actual organization.

Background and problem

A manufacturer is developing an automated infusion pump for hospital use. Customer research identifies accurate delivery, rapid setup, clear alarms, battery availability, easy cleaning, and safe operation as important needs. Early prototypes meet laboratory accuracy requirements but users report confusing alarm messages and occasional connector misalignment during simulated emergency setup.

Analysis

QFD translates “safe and quick setup” into requirements for keyed connection, setup time, alarm comprehensibility, confirmation feedback, and battery reserve. The design team builds a House of Quality and discovers that a larger display improves alarm comprehension but increases power consumption. This trade-off becomes an explicit design decision rather than an accidental compromise.

A design FMEA identifies “incorrect tubing connection” as a failure mode with potentially severe clinical effect. Rather than relying solely on operator training, the team evaluates an asymmetric connector, a mechanical lock, an electronic presence sensor, and a startup flow check. The actions reduce the opportunity for error and improve detection.

An FTA begins with the top event “incorrect infusion delivered.” Branches include incorrect programmed value, blocked flow, software calculation error, and incorrect tubing connection. The analysis identifies a common software-data interface as a common-cause concern affecting several nominally independent functions.

Reliability analysis is applied to the battery and alarm subsystem. The team does not assume that laboratory component reliability equals field reliability; it includes temperature, charging behavior, cleaning fluids, and user handling in validation conditions. Human-factors specialists conduct realistic usability studies, while quality engineers verify traceability from hazards to tests.

Approach and solution

The organization establishes a cross-functional review board involving design engineering, nursing users, quality, regulatory affairs, manufacturing, service, and cybersecurity. It adopts severity-based escalation: any credible hazardous failure requires documented control even if occurrence is low. It also introduces software input limits, connector keying, visual and audible alarm differentiation, battery self-test, and service-data monitoring.

Outcome

In the illustrative scenario, simulated setup errors decline after connector redesign, and validation identifies a previously overlooked alarm-obscuration problem in a noisy ward. The team revises the alarm hierarchy and updates training and labeling. The important outcome is not a single score; it is the improved evidence chain from need to risk control to validation.

Learning points

1. Customer requirements must include actual use context.
2. FMEA and FTA reveal different structures of risk.
3. Human factors and software interfaces can create common-cause failures.
4. Verification evidence is insufficient without realistic validation.
5. Residual risk requires explicit ownership and communication.

11. Limitations, governance, and contemporary practice

These methods depend on competent teams, accurate data, clear system boundaries, and willingness to challenge assumptions. FMEA scores can become ritualistic; QFD can convert nuanced needs into misleading numbers; FTA can omit unknown or emergent interactions; reliability models can fail when data are sparse or censoring is ignored; and design reviews can become status meetings rather than decision forums.

Governance should address:

• traceability of requirements, assumptions, evidence, and changes;
• competence and independence of reviewers;
• protection of users and affected communities;
• escalation of safety and regulatory concerns;
• retention and integrity of test and field data;
• privacy when operational or customer data are analyzed;
• cybersecurity and software supply-chain risk;
• accessibility and equitable performance across user groups.

AI and digital engineering can support failure-data mining, anomaly detection, simulation, requirements analysis, and predictive maintenance. However, AI-generated recommendations require validation, provenance, bias assessment, cybersecurity controls, and human accountability. A model trained on historical failures may reproduce reporting bias and may miss novel failure modes. Automation should improve evidence and attention, not remove responsible engineering judgment.

Best practice is therefore not the use of the largest number of tools. It is the disciplined integration of a few appropriate methods, with explicit assumptions, independent challenge, measurable controls, and life-cycle feedback.

Chapter Summary

Quality by design moves quality responsibility upstream. QFD converts stakeholder needs into prioritized and measurable technical characteristics while exposing design trade-offs. Design reviews provide evidence-based decision gates, and verification must be distinguished from validation. FMEA is a bottom-up method for examining failure modes, causes, effects, and controls; FTA is a top-down method for analyzing combinations that produce an undesired event. RPN can support screening but should not replace severity-based judgment or quantitative analysis.

Mistake-proofing addresses human error through elimination, prevention, or immediate detection. Robust design reduces sensitivity to noise factors and requires sound measurement and experimentation. Reliability analysis defines performance over time and uses models such as the reliability function, hazard rate, exponential model, and series-system relationship only under stated assumptions. Risk-based decisions must consider uncertainty, consequences, control effectiveness, ethics, and governance. Across the life cycle, the strongest quality systems connect requirements, risks, design controls, verification, validation, field evidence, and continual learning.

Key Terms

Quality by design: A systematic approach that builds quality into requirements, design, and processes before production or delivery.

Voice of the customer: Structured knowledge of user and stakeholder needs.

Quality Function Deployment: A method for translating customer needs into technical and operational requirements.

House of Quality: The principal QFD matrix linking customer requirements with technical characteristics.

Design review: A formal multidisciplinary evaluation of design evidence and readiness.

Verification: Confirmation that specified requirements have been met.

Validation: Confirmation that the result is fit for intended use.

Failure mode: A specific way in which a function or item can fail.

FMEA: A bottom-up analysis of failure modes, effects, causes, and controls.

Fault-tree analysis: A top-down logical analysis of combinations producing a top event.

Mistake-proofing: Design that prevents or immediately detects errors.

Robust design: Design that maintains acceptable performance despite noise factors.

Reliability: Probability of performing a required function for a stated time under stated conditions.

Hazard rate: Instantaneous conditional rate of failure among surviving items.

MTTF: Mean time to failure for nonrepairable items.

MTBF: Mean time between failures for repairable systems, subject to defined operating assumptions.

Residual risk: Risk remaining after controls are implemented.

Common-cause failure: A shared cause that defeats apparently separate functions or components.

Risk acceptance: A formally authorized decision that remaining risk is tolerable.

Review Questions

Short Answer Questions

1. What is the principal difference between verification and validation?
2. Identify the main elements of a House of Quality.
3. Why should RPN not be interpreted as a probability?
4. What does a series-system reliability model assume?
5. Give two examples of mistake-proofing.

Long Answer Questions

1. Explain how QFD, design reviews, FMEA, and validation can be integrated across a product life cycle.
2. Compare FMEA and fault-tree analysis in terms of direction of reasoning, typical outputs, and limitations.
3. Discuss how robust design addresses variation and why measurement-system quality matters.
4. Explain the ethical and governance implications of risk acceptance for safety-critical products.
5. Evaluate the strengths and weaknesses of using reliability models to support maintenance and design decisions.

Analytical / Application Questions

1. A system has three independent series components with reliabilities 0.99, 0.97, and 0.96 over a mission. Calculate system reliability and explain two reasons why the result might overstate field reliability.
2. Construct a mini-FMEA for a service process in which a customer receives the wrong item. Specify one failure mode, effect, cause, prevention control, detection control, and recommended action.
3. An organization must choose between a frequent low-consequence failure and a rare catastrophic failure with similar RPN values. Develop a risk-based recommendation that uses severity, uncertainty, control hierarchy, and governance rather than RPN alone.

Multiple Choice Questions with Answers

Question 1

Which QFD element identifies measurable design responses to customer needs?

A. Technical characteristics

B. Competitive assessment

C. Customer complaint log

D. Audit schedule

Correct Answer: A. Technical characteristics

Question 2

What is the principal purpose of validation?

A. To prove that drawings are complete

B. To confirm fitness for intended use

C. To calculate an RPN

D. To establish a supplier price

Correct Answer: B. To confirm fitness for intended use

Question 3

A traditional FMEA RPN is calculated as:

A. S + O + D

B. S × O × D

C. S ÷ O × D

D. O − S + D

Correct Answer: B. S × O × D

Question 4

In a fault tree, an AND gate indicates that:

A. Any one input is sufficient

B. No input can cause the output

C. All modeled input events are required for the output

D. Inputs are necessarily statistically independent

Correct Answer: C. All modeled input events are required for the output

Question 5

Which action is generally the strongest form of mistake-proofing?

A. Adding a warning poster

B. Increasing final inspection

C. Eliminating the opportunity for error

D. Asking operators to work faster

Correct Answer: C. Eliminating the opportunity for error

Question 6

For a constant hazard rate λ, reliability at time t is:

A. λt

B. 1 − λt

C. e^{−λt}

D. 1/λt

Correct Answer: C. e^{−λt}

Question 7

Two independent components in series have reliabilities 0.98 and 0.95. What is system reliability?

A. 0.030

B. 0.931

C. 0.965

D. 1.930

Correct Answer: B. 0.931

Question 8

Which statement about an RPN is most accurate?

A. It is a probability of failure

B. It is an expected monetary loss

C. It is a screening indicator requiring contextual judgment

D. It automatically prioritizes catastrophic risks correctly

Correct Answer: C. It is a screening indicator requiring contextual judgment

Question 9

In robust design, noise factors are:

A. Factors deliberately controlled as design settings

B. Sources of variation that are difficult or costly to control

C. Errors in the customer database only

D. Always equivalent to measurement error

Correct Answer: B. Sources of variation that are difficult or costly to control

Question 10

For independent events A and B, the probability of both occurring is:

A. P(A) + P(B)

B. P(A) − P(B)

C. P(A)P(B)

D. 1 − P(A)P(B)

Correct Answer: C. P(A)P(B)