Home > Articles > Business & Management

  • Print
  • + Share This
This chapter is from the book

Running a QFD Workshop: Mega Motors Example

Unless you are already somewhat familiar with QFD, all this probably sounds a bit nebulous, so it’s time for an example. While QFD can certainly be used as a tool by an individual, its biggest value is as a tool for team product planning, so our example follows a development team in a workshop setting. For our example, we’ll take a use case and QFD-driven approach to thinking about the design of an automobile; actually, a video storyboard about an automobile.

Storyboarding is a great requirements engineering technique for eliciting what Leffingwell and Widrig call "Yes, but..." reactions from a customer.4 The effectiveness of storyboards was demonstrated for me by a colleague who successfully used them in the oil and gas industry on a reinvent-the-paradigm project that proposed to change radically how the user approached their job.5 A storyboard was used as an effective tool to communicate both to the customer and the project team what life would look like in this new vision of the world.

There are a number of goals for this example of which I’d like you to be aware. First and foremost, I want to illustrate QFD’s use as a tool for planning the focus of a release. What better way to demonstrate this than with an example from the industry that helped popularize QFD, allowing companies like Toyota to plan for products customers would want to purchase.

The example also needs to demonstrate the basic parts and process of working with the QFD matrix without the domain of the problem getting in the way. This example—creation of a storyboard for a new vehicle—has the benefit that most people are familiar enough with automobiles to recognize whether the QFD process is producing results that really make sense or not. And it is simple enough to avoid getting bogged down in or distracted by the complexities and realities of creating a software system, allowing you to focus on learning QFD. The same goal could have been achieved with familiar examples, such as an ATM system or banking system, but they are already high mileage examples in the use case literature (pun definitely intended).

And finally, whereas we may be accustomed to associating use case-driven development with software, there is certainly no reason it cannot be applied elsewhere, such as in the design of hard-goods and services. This example will be novel in that respect.

For a real life example of use cases applied to the development of drive-by-wire cars at Volvo, see Johannessen et al.’s Hazard Analysis in Object Oriented Design of Dependable Systems.

After we’ve looked at QFD in action, we’ll look at examples of QFD applied to more "standard" software development projects in Chapter 2, "Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization."

Workshop Overview

Mega Motors is planning the focus of their next release of their flagship vehicle. Before full development begins, a project team composed of both marketing and engineers has been given the task of determining what key features of the vehicle will be most attractive to the customer. After these key features have been identified, a video-based storyboard shot with a mockup will be produced that focuses on these key features in use in a fashion typical of the customer. The video storyboard will be used with focus groups to get early impressions and reactions to the proposed new vehicle features and enhancements.

You have been asked to facilitate an offsite QFD workshop to jump start and align the thinking of the project team members.

Before the Workshop

As workshop facilitator you meet with hosts of the workshop—Vice President of Marketing and Vice President of Engineering—the day before the workshop is to begin. You start by working with them to draft an initial objective statement for the workshop:

"Determine what key features of the Mega Motors vehicle will be most attractive to the customer, along with a key use case that will be used as the basis for a video-based storyboard shot with a mockup to advertise these key features being used in typical fashion by a typical customer."

Next, you give a brief overview of the QFD process, and in particular review the basic components of a QFD matrix (see Figure 1.3).

Figure 1.3

Figure 1.3   Principal components of the QFD matrix, sometimes referred to as the "House of Quality."

Walking through the diagram of Figure 1.3, you explain to the VPs that QFD stands for Quality Function Deployment. To make sense of the name, try this: The "F" in QFD stands for the features and functions of the product. The goal of QFD is to find the best set of "F" to meet—or deploy (that’s the "D")—the goals "Q."

The QFD matrix is the central tool in QFD; it is sometimes called the "House of Quality." The matrix is a tool for establishing links between goals (the "Q, "which is referred to as Whats in the matrix) and ways to meet or deploy those goals (the "F," which is referred to as Hows in the matrix). These links are captured in the matrix as Relationships between Whats and Hows (the central part of the matrix).

You also explain that what constitutes the Whats and Hows can change as you work through the QFD process: the outputs from one matrix (i.e., the Hows) can become the inputs to another matrix (i.e., the Whats) as illustrated in Figure 1.2.

The Correlation section of the matrix—sometimes called the "roof"6 of the House of Quality—provides a means of capturing information about Hows that may interact with one another—either in a positive, reinforcing way, or negatively, working against one another.

The output of the QFD matrix is a Prioritization of Hows, calculated as a function of the prioritization of Whats and the strength of relationships between Whats and Hows.

Finally, you lay out a tentative game plan for working with the project team (see Figure 1.4).

Figure 1.4

Figure 1.4   Road map for the Mega Motors QFD workshop.

Working through Figure 1.4, note the following:

  1. The workshop will begin by determining a prioritized set of business drivers for the project (video production).

  2. The development team will brainstorm use cases that could be used as the basis for a storyboard of the vehicle being used in a manner typical of the customer.

  3. The use cases will then be analyzed and prioritized to identify those that most closely align with the business drivers.

  4. Those prioritized use cases will then be used to analyze quality requirements, such as reliability, safety, and vehicle look and feel, to see which quality requirements best align with the prioritized use cases.

  5. The same will be done with components of the vehicle—engine, transmission, body, and so on—to identify those components that best align with the prioritized use cases.

  6. The workshop will conclude with the results of the prioritized quality requirements and vehicle components being used to sketch out a video that shows the vehicle in use—as per the highest priority use case—showcasing the high-priority quality aspects of the high-priority components of the vehicle (e.g., reliability of the engine, safety of the interior, sporty feel of the steering, and so on).

Specify Business Drivers

The next day, you begin the QFD session with the usual introductions and explain to the team that QFD is a type of Joint Application Development (JAD) session, where ideally you have representatives for each of the roles that need to be filled in the development of a product: in this case, a team made up of marketing and engineering, representing the two ends of the hierarchy of Figure 1.1. You emphasize to the team that while QFD can be done by a single person, the real value is in the team alignment that occurs and increased problem solving from the "two heads are better than one" phenomenon.

You have prepared a QFD "road map" to help the team better visualize the overall QFD process for the workshop and will use it throughout to orient the team as to where they are at any given time (see Figure 1.5).

Figure 1.5

Figure 1.5   Your location on the QFD road map.

With intros and overview out of the way, you review the workshop objective statement drafted with the VPs of Marketing and Engineering. In order to make sure that everyone really buys into this objective statement, you ask the team for pros and cons on the objective as stated; in doing so you may bring to the surface tacit issues that have been missed. With minor modifications in place and a "thumbs up" vote to signify sign-off from all team members, you are ready to proceed.

What Is Driving the Project?

OK, you ask: what is driving this project (i.e., production of the video storyboard)? The marketing group has done its homework and has identified a profile of customer types it plans to bring into the focus group. The team suggests that the business driver for the project is to produce a focus group video that targets the interests of the following customer profile:

  • Young single male

  • Young single female

  • Married couple with young children

  • Double income couple, no kids

  • Older, retired couple

Addressing the engineers in the group, you ask if they are comfortable with this customer profile as a means to drive the project. One question they have is how do you know these are the right business drivers?

Good question. You reply that in some sense the QFD workshop is a way to determine if the business drivers are right. Engineers build prototypes all the time to test ideas. You ask them to think of QFD as a way of prototyping a project, allowing you to run through a complete product development cycle quickly, from start (thinking about the business drivers) to end (thinking about the final product that results from the business drivers). In fact, with QFD, what-if analysis is pretty easy, allowing you to essentially simulate different projects from start to end, exploring the consequences of different priorities at the business driver or use case levels. In doing this, you may well learn along the way that the initial business drivers are leading to results you intuitively feel are not what they should be, in which case, a reexamination of the business drivers may be in order. As with any prototype, the real value of QFD may not necessarily be the artifacts produced but with the discovery process that takes place. And one discovery could well be that your business drivers aren’t right.

This prototyping concept appeals to the engineers in the workshop, and they agree that as a first iteration they can’t think of any better business drivers.

Prioritize Business Drivers

One last critical step remains: prioritizing the list of customer profiles. As it turns out, this is also a very good way to test if you have the right business drivers.

For this, you explain you will be using a technique called Wideband Delphi.7 This is a group problem-solving technique that is often applied to project schedule and effort estimation; here you will apply it to prioritizing the business drivers. You explain that it is an iterative process of first making anonymous prioritizations individually or in small groups. This is then followed by "show-and-tell" of individual results, and then group discussion of any divergence ("This is why I prioritized differently from you..."). In this process, tacit assumptions and information held by individuals are brought to the surface for the group as a whole to see. With a couple of iterations of this process, the group will hopefully converge on an answer that is better than any individual would have come up with alone.

To start the Wideband Delphi prioritization, you break the team into several small groups, place them in separate corners of the room, and tell each they have $100 of virtual money to spend on the customer profiles, allocating the money in proportion to the relative importance of the customer. This is a standard prioritization technique used by meeting facilitators and has been suggested by Todd Wyder for use with QFD in ranking use cases. This approach has the benefit that it ranks the business drivers via a ratio scale. The problem with the use of 1-5 or 1-10 type rating scales, which are traditionally used in QFD,8 is that they are ordinal scales: is a business driver assigned a 5 really five times more important than one assigned 1?9 It has the added benefit of preventing the ranking of every business driver high-priority; something marketing folk—indeed all of us—are often wont to do!

After a period of time, each separate group has completed allocation of their $100 across each of the customer types. You re-assemble the team and have each group present their results on a flip chart at the front of the room. Each presentation is followed by discussion, and you also ask the group to brainstorm the pros and cons of each prioritization as they are presented. Pro/con analysis is a great tool for surfacing hidden assumptions and decision-making criteria at work.10 At the end of the first iteration, three key issues have emerged:

  1. One group has rated Older, Retired Couple quite high on the list.

    • Pro cited: "This group represents a significant portion of the future demographics."

    • Con cited: "Older, Retired Couple may potentially have less disposable income in upcoming years."

  2. Another group has placed Married Couple with Young Children high on their list.

    • Pro cited: "This group has traditionally been the strongest in terms of brand loyalty to Mega Motors."
  3. Another group has placed Double Income Couple, No Kids at the top of their list.

    • Pro cited: "This group has lots of disposable income for buying vehicles."

The Wideband Delphi prioritization process has brought to the surface what the team quickly realizes are actually business drivers in their own right (i.e., the customer profile for the new Mega Motors vehicle needs to take into account market size, brand loyalty, and disposable income of each customer type). As this discovery illustrates, part of the value of QFD is that it helps bring to light tacit assumptions, hidden agendas, and misconceptions as a team works through a problem. In doing this, information previously held by individuals surfaces to become part of the team collective consciousness. This is the process at work, and it’s important to keep a record of team discoveries as you go.

Enter Business Drivers into QFD Matrix

With this bit of alignment in place, each small group once again goes to its corner of the room to re-prioritize the customer profile. After reviewing each group’s results of the second round, they are finally able to agree on an allocation of dollars across the list of customer types (see Table 1.1). This split, they all are willing to agree, is a decent compromise of the new business drivers underlying the customer profile (i.e., market size, brand loyalty, and disposable income).11

Table 1.1  $100 in virtual money is allocated in proportion to importance of each customer type based on the market size, brand loyalty, and disposable income of each customer type.

Customer Type

Dollar Amount

Young Single Male


Young Single Female


Married Couple with Young Children


Double Income Couple, No Kids


Older, Retired Couple




At this point, the team has successfully turned a vision and objective statement into a concrete set of prioritized business drivers that can be used for prioritization and for making trade offs. The business drivers are entered into the QFD matrix along with the priorities converted to percentages (see Figure 1.6).

While representatives of all the customer types will be included in the focus group, type Married Couple with Young Children, the customer type of greatest importance, has been selected by the team as the focal point for the video storyboard showing the vehicle being used in a fashion typical of the customer. This selection is reflected in Figure 1.6 as highlighted text.

Figure 1.6

Figure 1.6 Prioritized customer types are entered into the QFD matrix as business drivers. Highlighting shows highest priority type and focal point for the video storyboard.

Identify Use Cases

In "traditional" manufacturing-based QFD, after the customer needs are identified (also called voice of the customer, or business drivers), the next step is to identify what are variously called technical performance measures or technical requirements. This latter term in particular does not mean what it would in a software engineering context. Technical requirements in QFD lingo are actually measures that can be made on a manufactured product to judge how well it satisfies the customer needs. As Lou Cohen has pointed out, for QFD applied to software, it is common for this measurement phase to be skipped over, moving directly to the identification of features and functions of the software; that is what we’ll do here.

The "F" in QFD stands for functions. The goal of QFD is to find the best set of "F" that meets or deploys the goal "Q." As we are dealing with use case-driven development projects, the "F" will stand for use cases. In our Mega Motors QFD workshop, the goal is to identify the set of use cases that can best be used to meet our business drivers.

Brainstorm Use Cases to Meet Business Drivers

In this next step of the Mega Motors workshop, the team brainstorms a list of use cases that reflect the use of the vehicle by the customer types that have been identified (refer to Figure 1.6). Figure 1.7 shows where you are in the overall QFD process at this point.

Figure 1.7

Figure 1.7   Your location on the QFD road map.

Because the business drivers of our Mega Motors example are couched in terms of a customer profile that closely resembles actors in use case development, the team is able to quickly develop a set of use cases that reflect different uses of the vehicle. The team also selects the use cases to emphasize different features and functions and to stress different components of the vehicle. For example, the Drive through Mountains use case was selected because mountain driving is notoriously difficult on the engine going uphill, brakes going downhill, and relies heavily upon good steering for hairpin turns; in all, a thorough use of three components in a manner distinct from the other use cases.

The use cases identified by the team are:

  • Carpool in Stop and Go Traffic

  • Drive Long Road Trip

  • Go Off-roading

  • Take/Pick Up Kids at School

  • Romantic Night on the Town

  • Drive through Mountains

In the previous step of the workshop, you worked with the team to identify Married Couple with Young Children as the focal point for the focus group video storyboard. From this set of uses cases just identified, one will eventually be selected (in the next step) as the basis for the storyboard itself, showing a married couple with children using a mockup of the Mega Motors vehicle. In addition, the set of prioritized use cases as a whole will be used to analyze and prioritize quality requirements and components (in the step after next). These will be featured in the video.

Enter Use Cases into QFD Matrix

After the list of use cases is identified, the use cases are entered into the QFD matrix (see Figure 1.8).

Keep in mind that the business drivers for a project will not always bear such a resemblance to use case actors. Neither is it the case that the QFD process always starts with business drivers. There may be occasions in which the use cases come first, followed by the search for business drivers with which to prioritize them.

Figure 1.8

Figure 1.8   Use cases to be analyzed and prioritized are entered into columns of matrix.

Analyze Relationship of Use Cases to Business Drivers

To this point in the Mega Motors workshop, you have worked with the team of engineers and marketing reps to identify a prioritized set of business drivers and a set of use cases (not yet prioritized). In this next step of the QFD workshop (see Figure 1.9), the team analyzes and prioritizes each use case in terms of each business driver. This provides:

  1. A prioritization of the use cases in terms of how well each lines up with the business drivers

  2. One use case singled out as the basis for the storyboard itself, which will show a married couple with young children using a mockup of the Mega Motors vehicle as per the use case that is selected

There are generally two ways to proceed on analyzing use cases (columns) in terms of business drivers (rows). One approach is to proceed by column, analyzing one use case against all business drivers, then moving to the next use case, and so on. This column-wise approach is advocated by Ronald Day in Quality Function Deployment: Linking a Company to Its Customer, stating that if the team works row-wise, they can often find a relationship between almost any customer need (business driver) and technical requirement (use case).

On the other hand, when the QFD matrix is being used to select the best choice(s) from a set of alternatives, I’m inclined to argue that row-wise works best, taking a business driver and analyzing it in terms of all the use cases, then moving to the next business driver. Working row-wise lends itself better to asking the question: Which of these use cases best meets a given business driver? Because part of the goal of the workshop is to identify the best use case for a video storyboard, this is the strategy you decide to use with the team.

Figure 1.9

Figure 1.9   Your location on the QFD road map.

Which Use Cases Best "Deploy" Each Business Driver?

From this stage of the QFD workshop forward, you have arranged to have a projector in the room, attached to a computer setup with the QFD matrix. This provides a common display for the whole team to see and work from. Working row-wise, you start with the first business driver, Young Single Male (i.e., video storyboard must target this customer) and walk the team through asking this question: Which of the following use cases is a young single male most likely to be interested in?

  • Carpool in Stop and Go Traffic

  • Drive Long Road Trip

  • Go Off-roading

  • Take/Pick Up Kids at School

  • Romantic Night on the Town

  • Drive through Mountains

You instruct the team to rate interest using this scale common to QFD:

  • 9 (nine)—Very Interested

  • 3 (three)—Interested

  • 1 (one)—A little interest

  • 0 (blank)—Not enough interest to mention

To further aid the prioritization of the use cases and address the concern expressed by Ronald Day about working row-wise, you instruct the team that as a guideline, try not to assign more than two use cases a nine. (This is just a suggestion, and is based on trying to identify that proverbial 20% of the use cases that delivers 80% of the bang for the buck. Because there are six use cases, 20% would be approximately one or two use cases that you are restricting to receive a "9".)12

Figure 1.10 shows the QFD matrix after row one—Young Single Male—has been completed.

Figure 1.10

Figure 1.10 Each use case is rated in terms of interest to Young Single Male. Assumptions, ideas, issues, and questions are recorded as the analysis proceeds, shown here as comments made in cells of the matrix.

A very important part of QFD is the discovery and brainstorming that occurs while a team is thinking about the correlation of business drivers to use cases. As a facilitator, you are prepared to capture ideas, issues, assumptions, notes, and questions on a flip chart at the front of the room. You also have the person working the QFD matrix record this information as notes in the appropriate cells of the matrix (refer to Figure 1.10).

For example, as the team discusses the interest of young single males in the use case Go Off-roading, there is discussion as to whether they are really attracted to off-roading per se, or more to the looks of a vehicle that is equipped for off-roading (i.e., big tires, high ground clearance, and so on). This is an important insight the team feels worth capturing (a vehicle that looks like an off-road vehicle is cheaper to build than one actually capable of off-roading).

Another question, as the team discusses the possible interest of young single males in use case Drive through Mountains, is what about the mountains would draw the attention of a young single male? The answer: skiing, camping, rock climbing, and so on. This information could well be used in future elaboration of the use case for this particular customer type if that becomes necessary; again, this is information the team felt worth capturing. QFD is not only a powerful tool for prioritizing use cases, but also for harnessing team brainstorming in a structured, systematic way.

As the team scores each use case in terms of the business driver (interest in use case by young single male), the results are instantly calculated at the bottom of the QFD matrix implemented as a spreadsheet. The row Raw Score sums for each column are the products of business driver priority times the score given to the use case (blank, 1, 3, or 9). The row Relative Weight then calculates the relative percent for each use case’s raw score. Excel formulas for use case Drive through Mountains are shown in Figure 1.11.

Figure 1.11

Figure 1.11 Excel formulas for calculating Raw Score and Relative Weight for each use case. Your favorite spreadsheet will have similar functionality.


After about an hour and a half, the team has completed a review of each use case in terms of each business driver.13 Each use case has received a rating of 0 (blank), 1, 3, or 9, indicating the strength of its relationship to the business driver (the higher the number, the stronger the relationship). Just as important as the score, however, are the team discussions that transpire; this is team alignment to a common understanding of the problem taking place. Some of the various ideas, assumptions, and notes recorded as part of the discovery process are shown in Figure 1.12.

Figure 1.12

Figure 1.12 Relationship part of matrix completed showing strength of relationship between use cases and business drivers (i.e. focus group customer types).

The final prioritization of use cases is summarized in Table 1.2, with use case Take/Pick Up Kids at School being the highest ranking use case. This use case is selected by the team as the basis for the focus group video storyboard in which a married couple with young children (the high-ranking customer type) will be shown using a mockup of the Mega Motors vehicle taking and picking up the kids at school. Customer type Married Couple with Young Children and use case Take/Pick Up Kids at School are highlighted in the QFD matrix to indicate this (see Figure 1.12).

Table 1.2  Relative importance of each use case in terms of business drivers

Use Case

Raw Score

Relative Weight

Carpool in Stop and Go Traffic



Drive Long Road Trip



Go Off-roading



Take/Pick Up Kids at School



Romantic Night on the Town



Drive through Mountains



In addition to providing a basis for prioritizing use cases, analyzing the relationship between business drivers and use cases can also help identify missing use cases. If you have a business driver for which no use case seems to correlate very well, you may well be missing a use case or use cases; in QFD lingo, the customer need or business driver has no function (use case) through which to be deployed.

Analyze Correlations Between Use Cases

The next and final step for this particular QFD matrix is to analyze the correlation between the use cases (see Figure 1.13).

In "standard" QFD, this step is usually done with non-functional requirements or design goals that can sometimes work against one another. For example, in software the design goal to build a component that is highly portable from one platform to another may work against the design goal of optimum speed. The code you have to write to be portable may not be the same code you would write to take advantage of hardware acceleration tricks on a given, single platform. The idea is to apply this same concept to use cases, looking for ones that the team anticipates are going to negatively correlate, where aspects of the product required for one use case work against aspects of the product required by another use case.

Figure 1.13

Figure 1.13   Your location on the QFD road map.

In this step, you have the team fill in the top, correlation part of the QFD matrix (see Figure 1.14).

The correlation part of the matrix is set up such that there is a cell for each pair-wise combination of use cases. Figure 1.14 shows that the team has identified a negative correlation (denoted with a minus sign) between use case Go Off-roading and use case Drive Long Road Trip: they anticipate that the characteristics of a vehicle designed for off-roading (tight suspension, short wheel base for going over bumps, knobby off-road tires) are opposites of the design characteristics of a vehicle built for comfort on long road trips. In the correlation part of the matrix, use cases that work against one another are shown with a negative sign. Likewise, the team has identified a negative correlation between the use case Go Off-roading and the use case Take/Pick Up Kids at School: a key design characteristic of a vehicle built for off-road driving is high ground clearance. This is seen to impede the activities of use case Take/Pick Up Kids at School, namely easy loading and unloading of cargo and putting kids in, and taking kids out of, a car seat.

Figure 1.14

Figure 1.14 The correlation part of the matrix—sometimes called the "roof" of the house of quality—is used to make note of use cases that may work against one another.

First Matrix Complete; QFD Workshop Status Check

The Mega Motors QFD workshop team has made good progress, so you decide to review the results thus far:

  • A set of business drivers has been identified in the form of a customer profile (that is to say, types of customers that will be attending the focus group).

  • The customer types were prioritized using a variant of Wideband Delphi. In addition to producing a prioritized set of customer types, the process also helped bring to the surface tacit assumptions and information held by individuals for the group as a whole to see. Three additional underlying business drivers were identified: market size, brand loyalty, and disposable income of each customer type.

  • From the prioritized list of customer types, Married Couple with Young Children scored highest and was identified as the focus of the video storyboard.

  • Use cases were identified that would be of interest to all the customer types. The use cases were then prioritized by analyzing the relationship between each business driver and use case, scoring that relationship with a scale of 0 (blank), 1, 3, or 9 (highest score).

  • The high-ranking use case—Take/Pick Up Kids at School—was then selected by the team to serve as the basis for the storyboard’s storyline.

  • Correlations between use cases were analyzed to identify negative correlations (i.e., use cases that might work against one another). Use case Go Off-roading was identified as having a negative correlation with use cases Take Long Road Trip and Take/Pick Up Kids at School.

In the next step of the QFD workshop, the prioritized use cases will be used to move the business drivers down into aspects of system design to analyze quality requirements and vehicle components that should be featured in the focus group video storyboard.

"Flipping the Matrix": Deployment to Quality Requirements

As noted earlier, QFD has received some attention in the use case community as a means of prioritizing use cases. What has received less attention, however, is the subsequent use of prioritized use cases as input to QFD to prioritize other aspects of software development (e.g., alternate design approaches). That is the goal of the Mega Motors QFD workshop team in the next step.

Recall that the "D" in QFD stands for "Deployment." In a previous workshop step, the team analyzed the relationship between business drivers and use cases to identify the priorities over the use cases that would best deploy the business drivers. In this next step, the business drivers will be deployed deeper into design aspects of the product by use of the prioritized list of use cases.

The prioritized use cases will be used to analyze quality requirements, such as reliability, safety, and vehicle look and feel, to see which quality requirements best align with the prioritized use cases and, in turn, the business drivers. The same will be done with components of the vehicle: engine, transmission, body, and so on.

These results will then be used to finish the outline for a video storyboard showcasing the high priority quality aspects of the high priority components of the vehicle (e.g., reliability of the engine, safety of door locks, and so on) while in use by the high priority customer type—married couple with young children—taking and picking up their kids at school (the high-priority use case).

In this step of the workshop (see Figure 1.15), the team will prioritize quality requirements for the Mega Motors vehicle in terms of the prioritized use cases from the QFD matrix (columns of Figure 1.14). This involves building a new QFD matrix in which the output of Figure 1.14 becomes the input of the new matrix. This is sometimes called "flipping the matrix" because columns of the first QFD matrix will now become the rows of the next matrix (see Figure 1.16).

Figure 1.15

Figure 1.15   Your location on the QFD road map.

Figure 1.16

Figure 1.16 The matrix for analyzing and prioritizing quality requirements takes as its input the output from the matrix shown in Figure 1.14.

Resolve Negative Correlation Between Use Cases

One issue that must be addressed at this point is what to do about the results of the analysis of use case correlations (see Figure 1.14): use case Go Off-roading was identified as having a negative correlation with use cases Take Long Road Trip and Take/Pick Up Kids at School. Such negative correlation can sometimes be an opportunity for new radical product design as a team brainstorms for innovative ways to turn what appears to be a negative into a positive.

For example, thinking outside the box a bit, a team might decide to build a vehicle with adjustable suspension allowing for high ground clearance for off-roading, low ground clearance for easy passenger and cargo loading and unloading, and adjustable stiffness for a soft, smooth ride on long road trips and tight, controlled ride on the trail. Voilà! Markets that were once separated—the off-roaders and the luxury/family/road-trippers—are now united! And in fact, that is just what Land Rover did in 1993 with their Electronic Air Suspension (EAS) system, dubbed the "magic carpet ride," combining the luxury car market with the off-road market.

In the case of the Mega Motors team, however, because the Go Off-roading use case ranked so low in relative weight, the decision of the team is to drop that use case as a driver in the project. In the flipped-matrix of Figure 1.16, this is accomplished by zeroing out the raw score in the new matrix. This effectively cancels out this use case as a factor in subsequent analysis based on prioritized use cases. This identifies another strength of QFD: it is fairly easy to do what-if analysis to explore the consequence of different priorities at the business driver or use case levels.

Brainstorm List of Quality Requirements

To brainstorm, the team begins by compiling a list of quality requirements in which the identified customer types are typically interested. Between a common set of requirements used on most Mega Motors vehicles and review of ideas and notes collected thus far in the workshop (e.g., those in Figure 1.12), the team is able to quickly identify a half dozen quality requirements:

  • Reliability

  • Good Looks

  • Safety

  • Fuel Economy

  • Sporty Power and Steering

  • Seating and Cargo Capacity

The quality requirements are entered into the new QFD matrix as columns, as shown in Figure 1.17.

Figure 1.17

Figure 1.17   Quality requirements to be analyzed and prioritized are entered as columns in the matrix.

Which Quality Requirements Are Most Important for Each Use Case?

Next, you work with the team to analyze and prioritize each quality requirement (columns) in terms of each use case (rows). The goal is to identify a few key quality requirements that are most important to the prioritized use cases. You instruct the team to rate the quality requirements in terms of their importance to each use case:

  • 9 (nine)—Very important to the use case

  • 3 (three)—Important to the use case

  • 1 (one)—Somewhat important to the use case

  • 0 (blank)—Has little or no importance to the use case

As before, you have the team work row-wise. For each use case they will review each quality requirement, and then move to the next use case. You instruct them that as a guideline they should try not to allocate more than two 9s per use case; this forces the team to think in terms of what is the biggest bang for the buck in quality requirements per use case.

The results of the team’s efforts are shown in Figure 1.18. In addition to scoring each quality requirement in terms of importance to the use cases, the team also makes notes on assumptions upon which the scoring was based: ideas, questions, and so on. These are entered on the flip chart at the front of the room and into the appropriate cells of the QFD matrix, which is being projected on the screen at the front of the room.

The scoring of quality requirements in terms of use cases has identified Reliability and Seating and Cargo Capacity as the two high scoring use cases; this is indicated by the highlighting in Figure 1.18.

Figure 1.18

Figure 1.18 Completed matrix showing importance of quality requirements to use cases. The two high-scoring quality requirements, Reliability and Seating and Cargo Capacity, are highlighted.

Analyze Correlations Between Quality Requirements

The final step of analysis on this matrix is to have the team analyze the quality requirements in terms of how they correlate with one another, identifying ones that work positively in support of one another and ones that work against one another negatively. The quality requirements are entered in the correlation part of the matrix—the "roof" of the matrix—then analyzed pair-wise. The results of the team’s analysis of the correlation of quality requirements are shown in Figure 1.19. To summarize, Reliability and Safety were found to be positively correlated: a vehicle that was unreliable was likely to also be unsafe. Given that safety was highly ranked as a quality requirement to start with, marketing felt it might be worthwhile to pursue reliability and safety in tandem as part of the video storyboard. This addition of Safety to the list of quality requirements to focus on in the video storyboard is indicated by highlighting in the matrix (see Figure 1.19).

Quality requirement Fuel Economy was found to be negatively correlated with Sporty Power and Steering (the more power, the more gas it burns), and also with Seating and Cargo Capacity (the more carrying capacity, the bigger the vehicle, the more gas it burns). Even though Fuel Economy was not rated very important to the use cases, the team decided it was wise to make note to be alert for potential drops in the fuel efficiency of the vehicle that might result from increases in seating and/or cargo capacity (a high-ranking quality requirement). This is a typical use of the correlation information in QFD: while you may decide that a given quality requirement is not to be the focus of a new release, you also don’t want it to regress in response to some other change. In software, performance is a quality requirement that often suffers this fate.

Figure 1.19

Figure 1.19  Reliability and Safety were found to be positively correlated. Fuel Economy was found to be negatively correlated with both Sporty Power & Steering and Seating & Cargo Capacity.

Flipping the Matrix: Deployment to Vehicle Components

One last QFD matrix is needed to complete the analysis of the Mega Motors team. In this final QFD step (see Figure 1.20) the prioritized use cases are used to analyze components of the vehicle—engine, transmission, body, and so on—to determine which best align with the prioritized use cases and, in turn, the business drivers.

Figure 1.20

Figure 1.20   Your location on the QFD road map.

Working with the team, you work through the same process as in the previous section, "Flipping the Matrix: Deployment to Quality Requirements," but rather than addressing quality requirements, it is done for the following components of the Mega Motors vehicle:

  • Brakes

  • Steering

  • Engine

  • Transmission

  • Body

  • Interior

  • Suspension

The results of this step are shown in Figure 1.21; the team did not feel it necessary to do analysis of the correlation of components, so there is no "roof" to the matrix.

Figure 1.21

Figure 1.21   Matrix showing relationship of vehicle components with use cases.

To summarize the results of this last step, components Body and Interior were identified by the Mega Motors team as having the greatest correlation to the prioritized use cases. They are shown highlighted in Figure 1.21 to indicate that they will be the featured components of the video storyboard.

Workshop Conclusion and Summary

With the completion of the third and final QFD matrix, the team is ready to wrap-up its findings (see Figure 1.22).

To review, the objective statement of the workshop was to:

Determine what key features of the Mega Motors vehicle will be most attractive to the customer, along with a key use case that will be used as the basis for a video-based storyboard shot with a mockup to advertise these key features being used in typical fashion by a typical customer.

Figure 1.22

Figure 1.22    Your location on the QFD road map.

From the workshop, the following has been identified as the basis for the focus group video storyboard:

The video will follow a married couple with young children as they drive the new Mega Motors vehicle to take and pick up their children from school. Featured in the video will be the vehicle’s interior and body, focusing on safety, reliability, and ample seating and cargo capacity.

One good thing about QFD is its support of traceability. When results are presented after the workshop to the VP of Engineering and Marketing, it will be possible to explain the trail of thought leading to the recommendation. QFD also allows the VPs to do follow-up what-if analysis on alternate business driver priorities, exploring other possible outcomes, if they choose to do so.

Finally, while this workshop has successfully identified the overall focus of the video storyboard, a further QFD workshop is probably needed to drill down into more detail,14 this time extending participants to include someone from the team that will actually produce the video. The goal of that workshop will be to:

  • Use QFD to identify and prioritize specific parts of the interior and body that play key roles in the scenarios that make up the Take/Drop Kids at School use case.

  • Select the highest priority parts from the prioritized list to brainstorm and prioritize design ideas to make them reliable, safe, and facilitate expanded seating and cargo capacity.

A QFD road map for such a follow-up workshop is given in Figure 1.23.

To close the workshop, you review assigned action items and then conduct a brief "postmortem," looking for things participants thought worked well in this workshop and should be repeated in subsequent workshops and for things that could be done better next time. That task completed, the workshop comes to a close.

Figure 1.23

Figure 1.23  QFD roadmap for subsequent workshop to drill down deeper in identifying design ideas for specific parts of body and interior to make them reliable, safe, and facilitate increased seating and cargo capacity.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020