2. Customer, Stakeholder and Quality Requirements

Introduction and Context

Quality management begins before a product is designed, a process is operated, or a service is delivered. It begins with understanding what creates value for customers and other stakeholders. A technically sophisticated product may fail if it does not solve the customer’s problem. Conversely, a modest design can succeed when it reliably satisfies the requirements that matter most.

In production management, requirements provide the link between market expectations and operational control. Customer statements such as “the machine should be easy to use,” “delivery must be dependable,” or “the service should respond quickly” are meaningful, but they are not yet suitable for engineering, purchasing, inspection, scheduling, or process improvement. They must be translated into measurable quality characteristics, acceptance criteria, and process controls.

This chapter examines that translation. It integrates the voice of the customer (VoC), stakeholder analysis, Kano analysis, quality function deployment (QFD), critical-to-quality (CTQ) characteristics, service-quality concepts, and requirements traceability. The central managerial issue is not merely collecting expectations; it is deciding which expectations are strategically important, converting them into verifiable specifications, and maintaining their connection throughout the product or service life cycle.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Distinguish customers, stakeholders, needs, requirements, specifications, and CTQ characteristics.

2. Collect and interpret the voice of the customer using qualitative and quantitative methods.

3. Apply Kano analysis to classify customer attributes and manage satisfaction trade-offs.

4. Explain and use QFD to translate customer requirements into technical and operational responses.

5. Construct measurable CTQ statements and service-quality measures.

6. Develop a requirements traceability approach for production and quality assurance.

7. Evaluate practical, ethical, technological, and managerial challenges in requirements management.

From Expectations to Quality Requirements

A customer need is a desired outcome expressed in ordinary language. A requirement is a documented obligation or expectation that can guide design and evaluation. A specification is a precise statement of the required value, range, method, or condition. These terms are related but not interchangeable.

For example, “the packaging should protect the product” is a need. “The package shall prevent damage during normal distribution” is a requirement. “The package shall withstand a specified compression load and pass a defined drop-test protocol” is a specification. The final statement enables objective verification.

Requirements may originate from several sources:

• external customers and end users;
• distributors, service partners, and suppliers;
• regulators and certification bodies;
• owners, investors, employees, and communities;
• internal departments such as production, maintenance, sales, and logistics;
• lessons from complaints, warranty claims, audits, and field failures.

The purchaser is not always the user, and the user is not always the person who defines the specification. A hospital purchasing department, for example, may evaluate price and contractual terms, while clinicians evaluate usability and patients experience safety and comfort. A robust quality system therefore identifies the complete stakeholder network rather than treating one commercial contact as the whole customer.

Requirements also differ in visibility. Some are explicitly stated, such as a delivery date or dimensional tolerance. Others are implicit, such as reasonable safety, reliability, legal compliance, or compatibility with normal operating conditions. A third category consists of latent needs: expectations customers may not articulate because they have not imagined a different solution. Innovation often depends on discovering these latent needs without confusing novelty with value.

A useful hierarchy is:

Need → customer requirement → measurable quality characteristic → specification → verification evidence.

For instance:

Need: safe operation.

Requirement: the operator must be protected from foreseeable contact with moving parts.

Quality characteristic: guarding coverage, interlock response, and stopping time.

Specification: the machine shall stop within a defined time after guard opening.

Evidence: test record, inspection result, and approved design documentation.

This hierarchy prevents a common error: allowing vague customer language to pass directly into production without an operational definition.

Understanding the Voice of the Customer

The VoC is the structured representation of customer statements, experiences, preferences, problems, and desired outcomes. It is not simply a list of survey responses. It requires interpretation, segmentation, prioritisation, and translation.

Methods of capturing the VoC

Different methods reveal different kinds of information. Interviews and contextual observation are valuable for understanding work practices, frustrations, and unspoken constraints. Focus groups can expose alternative perceptions, although dominant participants may distort the discussion. Surveys provide broader coverage and support statistical comparisons, but their quality depends on question design. Complaint records, warranty data, returns, call-centre logs, web reviews, and usage analytics reveal actual failure and dissatisfaction patterns. Sales and service employees can provide important intermediary knowledge, although their interpretations should be distinguished from direct customer evidence.

A strong VoC programme uses triangulation. If customers claim that a product is unreliable, the organisation should compare that perception with failure rates, service calls, operating conditions, and competitor performance. If survey respondents rank delivery speed highly but routinely accept later deliveries, the organisation should investigate whether the survey question captured a genuine priority or a socially desirable response.

Interpreting customer language

Customers usually describe outcomes rather than technical solutions. A statement such as “I want a stronger motor” may actually mean “I need the equipment to complete the task without stalling.” Recording the proposed solution too early can constrain innovation. Analysts should repeatedly ask what problem the customer is trying to solve and under what conditions.

The “five whys” technique can help distinguish symptoms from underlying needs, but it must be used carefully. Customer needs are also influenced by context, risk, culture, accessibility, and the consequences of failure. A requirement that appears minor in a consumer product may be critical in medical, aerospace, automotive, chemical, or infrastructure applications.

Prioritising requirements

Not every customer statement can receive equal resources. Prioritisation may consider importance, dissatisfaction, frequency, strategic fit, regulatory significance, risk, cost of implementation, and competitive differentiation. Importance alone is insufficient. A characteristic may be highly important but already well satisfied; another may be moderately important yet represent a major source of dissatisfaction.

Segmentation is essential. Requirements can vary by market, application, geography, user skill, operating environment, and customer value proposition. Aggregating all responses into one average may hide a safety-critical minority or produce a design that satisfies no segment particularly well.

Kano Analysis: Satisfaction Is Not Linear

The Kano model explains why improving every attribute does not produce the same increase in customer satisfaction. It classifies attributes according to how their presence or performance affects satisfaction.

Must-be attributes are basic expectations. Their presence may not create enthusiasm, but their absence causes strong dissatisfaction. Safe operation, accurate billing, and basic reliability often fall into this category. Kano classification is context-dependent: an attribute may become a must-be as the market matures.

One-dimensional attributes produce satisfaction approximately in proportion to performance. Faster delivery, longer battery life, lower defect rates, or reduced energy consumption may be evaluated in this way. These attributes are common targets for competitive benchmarking.

Attractive attributes are unexpected benefits. Their absence does not usually cause dissatisfaction, but their presence can create delight. They may become normal expectations over time, so they require periodic reassessment.

Indifferent attributes have little effect on satisfaction for a particular customer segment. Investment in them may create technical complexity without meaningful value.

Reverse attributes satisfy some customers but dissatisfy others. Excessive automation, for example, may be valued by one group and rejected by users who require control or transparency.

A Kano questionnaire generally presents functional and dysfunctional forms of an attribute. Respondents indicate how they would feel if the feature were present and if it were absent. The paired answers are interpreted through a classification matrix. The method is useful for discovering asymmetry, but it has limitations: results can depend on wording, sample composition, cultural context, and changing expectations. Kano analysis should therefore support, not replace, behavioural data and managerial judgement.

The strategic implication is important. Organisations must first protect must-be performance, then compete on important one-dimensional characteristics, and selectively invest in attractive features. Adding attractive features cannot compensate for a failure in safety, basic reliability, or contractual performance.

Quality Function Deployment and the House of Quality

QFD is a systematic method for translating customer requirements into technical characteristics, process plans, and control activities. Its best-known representation is the House of Quality, although QFD can extend through several linked matrices.

The first stage begins with the “voice of the customer.” Customer requirements are organised into a hierarchy, often from broad needs to specific attributes. Each requirement is assigned an importance rating, preferably based on evidence rather than assumption. Competitive information may be added to show how the organisation and competitors perform from the customer’s perspective.

The team then identifies measurable technical characteristics that influence each customer requirement. A technical characteristic should be controllable or designable and should have a direction of improvement: larger is better, smaller is better, or target is best. The relationship matrix indicates the strength of connection between each customer requirement and each technical characteristic. A roof matrix may show positive or negative correlations among technical characteristics.

For example, reducing product weight may improve portability but conflict with structural robustness. Increasing insulation may improve energy efficiency while increasing size or cost. These relationships reveal trade-offs that may otherwise be discovered late through failed prototypes or customer complaints.

A simplified importance calculation for a technical characteristic can be expressed as:

Technical priority = Σ (customer importance × relationship strength).

Organisations often use relationship weights such as 9 for strong, 3 for medium, and 1 for weak relationships, although the numerical convention is not universal. The result is a prioritisation aid, not an objective truth. It should be reviewed against risk, feasibility, regulation, cost, and competitive strategy.

QFD may continue from product planning to part deployment, process planning, and production or service control. In a manufacturing setting, a customer requirement such as “consistent cutting performance” may be translated into blade geometry, material hardness, spindle stability, process capability, inspection frequency, and maintenance requirements. In a service setting, “quick resolution” may become response-time targets, staffing rules, escalation procedures, knowledge-base quality, and first-contact resolution measures.

QFD is most effective when conducted by a cross-functional team. Marketing contributes customer knowledge, design contributes technical feasibility, operations contributes process capability, procurement contributes supplier realities, quality contributes measurement and risk perspectives, and service personnel contribute field experience. A QFD matrix created by one department often becomes a visually impressive but operationally weak document.

Critical-to-Quality Characteristics

A CTQ characteristic is a measurable attribute whose performance is essential to satisfying a customer, stakeholder, regulatory, or process requirement. CTQs provide the operational bridge between customer value and process control.

A CTQ tree is a practical method for deriving measurable characteristics. It starts with a broad need, identifies drivers of that need, and defines measurable requirements. For example:

Need: dependable order fulfilment.

Driver: accurate and timely processing.

Requirements: correct item, complete quantity, dispatch within agreed time.

CTQs: order accuracy percentage, fill rate, order-cycle time, and on-time shipment rate.

A CTQ should have a clear operational definition. “Fast response” is not a CTQ until response is defined, such as the time from a valid customer request to an acknowledged and actionable response. “Low defect rate” requires a defined defect, unit of measure, sampling rule, and reporting period.

CTQs may be classified as measurable outputs, process characteristics, or leading indicators. A final defect rate is an output measure. Torque variation during assembly is a process characteristic. Equipment condition or training completion may be a leading indicator. A mature quality system uses all three because final inspection alone cannot assure quality economically.

Specifications commonly take three forms:

• nominal-is-best, where deviation in either direction is undesirable;
• larger-is-better, where higher performance is preferred within safe or feasible limits;
• smaller-is-better, where lower values are preferred.

A specification must not be confused with a control limit. Specification limits express customer or design requirements; control limits describe the observed behaviour of a stable process. A process can be statistically stable but incapable of meeting specifications, or apparently capable for a short period while remaining unstable. This distinction is central to quality assurance.

Service Quality and the Experience of the Customer

Manufactured products and services differ in important ways. Services often involve customer participation, simultaneous production and consumption, variable performance, and limited ability to inspect before delivery. Consequently, service quality depends not only on the final outcome but also on the process and interaction.

A widely used service-quality framework considers dimensions such as:

• reliability: performing the promised service dependably and accurately;
• responsiveness: willingness and ability to provide prompt help;
• assurance: competence, credibility, and ability to create trust;
• empathy: attention to individual customer circumstances;
• tangibles: physical facilities, equipment, appearance, and communication materials.

These dimensions should not be applied mechanically. Their importance varies by service and customer segment. In a digital banking service, security and system availability may dominate. In healthcare, empathy, clinical competence, privacy, and safety interact. In industrial maintenance, technical resolution and restoration time may matter more than physical appearance.

Service requirements should be stated in observable terms. “Professional staff” might become a competency standard, a communication protocol, a first-contact resolution target, and a customer-feedback measure. However, excessive standardisation can suppress judgement and empathy. Service quality design must therefore balance consistency with appropriate discretion.

The gap between expected and perceived service is a useful diagnostic idea, but expectations are not fixed. They are shaped by prior experience, advertising, alternatives, urgency, and the severity of the customer’s problem. Measuring satisfaction alone can conceal low expectations or customer switching barriers. Organisations should combine satisfaction data with retention, repeat contact, complaint escalation, response performance, and outcome measures.

Requirements Traceability Across the Life Cycle

Requirements traceability is the ability to follow a requirement from its origin through analysis, design, implementation, verification, release, and subsequent change. A traceability matrix may connect customer needs to requirements, risks, design outputs, process controls, test cases, inspection records, training, and field feedback.

A basic traceability record may include an identifier, source, requirement statement, rationale, priority, owner, verification method, acceptance criterion, status, revision history, and links to related risks. Unique identifiers prevent ambiguity. “Improve reliability” is not traceable; “R-017: the unit shall operate for the specified test duration without functional failure under defined conditions” is more suitable, provided the conditions and evidence are documented.

Traceability supports several management purposes. It demonstrates that important requirements have not been lost during translation. It reduces the risk of releasing a product with unverified obligations. It helps assess the impact of proposed changes. It supports audits, regulatory submissions, failure investigation, configuration management, and learning from field performance.

Traceability is not the same as maintaining a large spreadsheet. Records must remain current, controlled, and useful. Excessive documentation can encourage superficial compliance, while insufficient traceability creates hidden risk. The appropriate level depends on product criticality, regulatory exposure, supply-chain complexity, and change frequency.

Digital requirements-management and product-lifecycle systems can connect QFD outputs, risk analyses, computer-aided design, enterprise resource planning, manufacturing execution systems, inspection data, and service records. Analytics can identify recurring complaint themes, detect changes in customer priorities, and compare requirements with actual performance. Artificial intelligence may assist with classifying feedback or identifying duplicate requirements, but human review remains necessary because automated systems can misinterpret sarcasm, context, minority needs, or legally significant language.

Applied Case: Redesigning an Industrial Portable Compressor

Background

The following is an illustrative case. A manufacturer of portable compressors serves construction contractors, rental companies, and maintenance departments. Sales were stable, but warranty claims and negative reviews were increasing. Customers praised the compressor’s power but complained that it was difficult to transport and frequently unavailable when needed.

Situation and problem

The organisation initially proposed a larger motor and a digital display. Engineering believed these changes would differentiate the product. However, service records showed that failures were often associated with overheating, delayed maintenance, damaged connectors, and difficult starting in cold conditions. Interviews revealed three customer segments with different priorities: contractors valued mobility and rapid start-up, rental companies valued robustness and low service cost, and maintenance departments valued diagnostic information and reliable operation.

Analysis

The cross-functional team collected interviews, complaint data, rental-return inspections, competitor observations, and field measurements. Kano analysis suggested that basic starting reliability and safe operation were must-be attributes. Noise level and operating duration were one-dimensional attributes. A remote diagnostic alert was attractive to maintenance departments but indifferent to some contractors.

The team created a QFD matrix. High-priority technical characteristics included starting reliability at low temperature, thermal protection, connector durability, handle and wheel design, service-access time, and operating noise. The larger motor had a weak relationship with the most important customer needs and created conflicts with weight, heat, and transportability. It was therefore not selected as the primary improvement.

CTQs were defined as follows: start success under specified temperature conditions; maximum allowable operating temperature; connector mating-cycle durability; maximum lifting force; service-access time; and noise level at a defined distance and load. Each CTQ received a verification method and an accountable owner.

Approach and solution

The redesigned product used improved thermal management, a more robust connector, a revised transport frame, clearer maintenance indications, and a cold-start improvement. A limited diagnostic function was included for the maintenance segment, but the team avoided making it a universal design priority. A traceability matrix linked each customer requirement to design features, validation tests, supplier controls, and service instructions.

Pilot units were tested in laboratory conditions and with representative users. Feedback led to a change in wheel geometry and a simplified maintenance-access panel. The design review also identified a potential ethical issue: the maintenance indicator could not be allowed to imply that the product was safe to operate under all conditions. Instructions clearly stated the limits of the indicator and the need for specified inspections.

Outcome

The case organisation reported fewer early-life complaints during its pilot period and improved usability ratings among contractors. More importantly, management gained a disciplined basis for deciding which features to fund. The principal result was not one particular technical innovation; it was the alignment of customer priorities, measurable CTQs, verification evidence, and post-sale learning.

Learning points

1. Customer power ratings did not identify the main sources of dissatisfaction.

2. Different segments required different priorities.

3. Kano analysis prevented attractive technology from displacing must-be performance.

4. QFD exposed trade-offs among weight, heat, reliability, and cost.

5. CTQs made vague expectations testable.

6. Traceability connected market evidence with design and field validation.

Challenges, Risks and Common Mistakes

The first challenge is confusing stated preferences with actual value. Customers may request features that are familiar, fashionable, or easy to describe, while the underlying need is different. Second, organisations may over-rely on averages and ignore segments with severe consequences of failure. Third, teams may assign importance ratings without reliable evidence, turning QFD into an exercise in internal opinion.

Other common mistakes include writing requirements as solutions rather than outcomes, using ambiguous terms such as “user-friendly” or “high quality,” failing to define operating conditions, and treating every requirement as equally negotiable. A further error is assuming that customer satisfaction data can replace objective performance data. Satisfaction is important, but it must be interpreted alongside defects, reliability, delivery, safety, and cost.

Requirements can also conflict. A customer may desire low price, rapid delivery, extensive customisation, high durability, and sustainable materials simultaneously. Managers must make trade-offs explicit rather than allowing them to emerge through uncontrolled compromises. Risk-based prioritisation is especially important when requirements concern safety, privacy, accessibility, environmental impact, or vulnerable users.

Ethical, Governance and Professional Considerations

Requirements management has ethical significance. Organisations should not deliberately make safety information obscure, define quality in a way that hides foreseeable failures, or use customer data beyond legitimate purposes. VoC research should respect privacy, informed participation, confidentiality, and appropriate data retention. Feedback from vulnerable users should not be dismissed because it is numerically small.

Governance requires clear ownership of requirement approval, change control, deviation acceptance, and release decisions. Regulatory and contractual requirements must be distinguished from optional preferences, but both need traceable interpretation. When artificial intelligence analyses customer feedback, organisations should examine bias, explainability, data security, and the possibility that minority or negatively expressed experiences are systematically misclassified.

Professionals also have a duty to communicate uncertainty. A specification is not a guarantee of every possible outcome. Test conditions, exclusions, assumptions, and residual risks should be visible to decision-makers and users.

Emerging Developments and Best Practice

Customer and stakeholder requirements are increasingly dynamic. Connected products generate usage data that can reveal real operating conditions, while digital service channels provide continuous evidence of friction and failure. Sustainability requirements now extend beyond product performance to energy use, repairability, material sourcing, packaging, emissions, and end-of-life recovery. Accessibility and inclusive design are becoming more central because a product that works only for an assumed average user may fail important populations.

The most effective organisations treat requirements as living knowledge rather than a document created at project initiation. They refresh VoC evidence, monitor shifts in Kano categories, connect operational data with customer outcomes, and use closed-loop learning from complaints and field failures.

Best practice includes:

• identify all relevant customer and stakeholder groups;
• distinguish needs from proposed technical solutions;
• use multiple evidence sources and segment the data;
• prioritise requirements using importance, risk, dissatisfaction, and strategy;
• translate requirements into measurable CTQs and acceptance criteria;
• use cross-functional QFD to expose relationships and trade-offs;
• assign ownership and verification responsibility;
• maintain proportionate, controlled traceability;
• validate with representative users and realistic conditions;
• review requirements after launch using field and service evidence.

Chapter Summary

Quality requirements translate value expectations into conditions that design, production, service, and assurance functions can understand and verify. Customers and stakeholders may express needs directly, indirectly, or not at all; therefore, VoC work requires interviews, observation, surveys, operational data, segmentation, and interpretation. Kano analysis distinguishes must-be, one-dimensional, attractive, indifferent, and reverse attributes, helping managers allocate attention appropriately.

QFD provides a cross-functional method for linking customer requirements with technical characteristics and revealing trade-offs. CTQs convert important needs into measurable, controlled characteristics with defined operating conditions and verification methods. Service-quality analysis extends quality beyond physical conformance to reliability, responsiveness, assurance, empathy, and tangible evidence. Requirements traceability maintains the connection from source need to design, process control, verification, release, and field learning. Effective practice combines customer evidence, technical discipline, risk-based judgement, ethical governance, and continuous revision.

Key Terms

Voice of the customer: Structured evidence about customer needs, expectations, experiences, and desired outcomes.

Stakeholder: A person or group that can affect, be affected by, or have an interest in an organisation’s decisions and results.

Customer requirement: A stated or implied expectation that an offering or process should satisfy.

Specification: A precise, measurable statement of required performance, characteristics, or conditions.

Latent need: An unarticulated expectation or opportunity that customers may not consciously express.

Kano analysis: A method for classifying attributes according to their effect on customer satisfaction.

Must-be attribute: A basic requirement whose absence causes strong dissatisfaction.

One-dimensional attribute: An attribute for which improved performance generally increases satisfaction.

Attractive attribute: An unexpected feature whose presence can create delight without causing dissatisfaction when absent.

Quality function deployment: A structured approach for translating customer requirements into technical, process, and control requirements.

House of Quality: The commonly used matrix representation of the first stage of QFD.

Critical-to-quality characteristic: A measurable characteristic essential to satisfying an important requirement.

CTQ tree: A hierarchical method for deriving measurable requirements from broad customer needs.

Operational definition: A precise description of how a characteristic is measured, classified, or evaluated.

Service quality: The degree to which a service process and outcome meet customer expectations and requirements.

Requirements traceability: The ability to follow a requirement through its source, implementation, verification, and changes.

Acceptance criterion: A condition or test result that determines whether a requirement has been satisfied.

Control limit: A statistically derived boundary describing process behaviour, distinct from a customer specification limit.

Review Questions

Short Answer Questions

1. Distinguish a customer need, a requirement, and a specification.

2. What is the purpose of Kano analysis?

3. Define a critical-to-quality characteristic.

4. Why is the purchaser not always the only customer who should be considered?

5. What is requirements traceability?

Long Answer Questions

1. Explain how the voice of the customer can be collected, interpreted, and prioritised in a production organisation.

2. Describe the Kano model and discuss its implications for quality investment decisions.

3. Explain the structure and managerial value of the House of Quality.

4. Discuss how CTQ characteristics connect customer expectations with process control and verification.

5. Explain the importance of service-quality dimensions in designing and managing service operations.

Analytical / Application Questions

1. A manufacturer receives complaints that its product is “unreliable.” Develop a CTQ tree showing how this statement could be translated into measurable requirements and verification evidence.

2. A service provider plans to invest heavily in a new mobile application while response-time complaints remain unresolved. Use Kano analysis and QFD concepts to evaluate this decision.

3. Construct a basic requirements-traceability plan for a safety-critical industrial machine, identifying sources, design outputs, verification activities, and change-control needs.

22. Multiple Choice Questions with Answers

Question 1

Which sequence best represents the translation of customer value into quality assurance evidence?

A. Specification → need → requirement → inspection

B. Need → requirement → measurable characteristic → specification → verification evidence

C. Complaint → specification → need → production plan

D. Technical feature → customer survey → need → acceptance criterion

Correct Answer: B. Need → requirement → measurable characteristic → specification → verification evidence

Question 2

In Kano analysis, a must-be attribute is one that:

A. Creates delight whenever it is present

B. Has no effect on satisfaction

C. Causes strong dissatisfaction when absent but limited enthusiasm when present

D. Always produces satisfaction in direct proportion to performance

Correct Answer: C. Causes strong dissatisfaction when absent but limited enthusiasm when present

Question 3

What is the principal purpose of the relationship matrix in a House of Quality?

A. To calculate employee productivity

B. To connect customer requirements with technical characteristics

C. To replace all product testing

D. To identify only regulatory requirements

Correct Answer: B. To connect customer requirements with technical characteristics

Question 4

Which statement is the best CTQ formulation?

A. The service should be fast

B. Customers should be happy with delivery

C. The order shall be dispatched within the agreed cycle time, measured from order confirmation to carrier handover

D. The company should improve logistics

Correct Answer: C. The order shall be dispatched within the agreed cycle time, measured from order confirmation to carrier handover

Question 5

A technical characteristic has high QFD priority when it:

A. Is expensive, regardless of customer relevance

B. Has strong relationships with highly important customer requirements

C. Is preferred by the engineering department alone

D. Has the largest numerical measurement

Correct Answer: B. Has strong relationships with highly important customer requirements

Question 6

Which example most clearly distinguishes a control limit from a specification limit?

A. A control limit describes customer demand, while a specification limit describes process variation

B. Both terms mean exactly the same thing

C. A specification limit states required performance, while a control limit describes observed process behaviour

D. A control limit is always wider than a specification limit

Correct Answer: C. A specification limit states required performance, while a control limit describes observed process behaviour

Question 7

A customer asks for a “stronger motor,” but investigation shows the real problem is stalling during a particular task. What is the best requirements-management response?

A. Accept the motor request without further analysis

B. Translate the request into the underlying outcome and define performance under relevant conditions

C. Reject the request because customers cannot specify technology

D. Replace all customer evidence with competitor data

Correct Answer: B. Translate the request into the underlying outcome and define performance under relevant conditions

Question 8

Which service-quality dimension is most directly concerned with performing a promised service accurately and dependably?

A. Reliability

B. Empathy

C. Tangibles

D. Assurance

Correct Answer: A. Reliability

Question 9

What is the main value of requirements traceability?

A. It guarantees that no design trade-offs will occur

B. It links requirements to implementation, verification, changes, and evidence

C. It eliminates the need for customer research

D. It allows specifications to remain ambiguous

Correct Answer: B. It links requirements to implementation, verification, changes, and evidence

Question 10

In the illustrative compressor case, why was the larger motor not selected as the primary improvement?

A. Motors are never relevant to compressor quality

B. It had a weak relationship with the highest-priority needs and created trade-offs with weight and heat

C. Customers rejected all technical improvements

D. QFD prohibits changes to product architecture

Correct Answer: B. It had a weak relationship with the highest-priority needs and created trade-offs with weight and heat