QFD IN SOFTWARE ENGINEERING

A thesis submitted

to Kent State University in partial fulfillment of the requirements for the

degree of Master of Science

by

Leenah O. Alrabghi

December, 2013

Thesis written by

Leenah O. Alrabghi

B.S., King Abdulaziz University, 2006

M.S., Kent State University, 2013

Approved by

Dr. Austin Melton Chair, Master Thesis Committee

Dr. Arden Ruttan Members, Master Thesis Committee

Dr. Paul Farrell Members, Master Thesis Committee

Accepted by

Dr. Javed Khan Chair, Department of Computer Science

Dr. Raymond Craig Associate Dean, College of Arts and Sciences

ii

TABLE OF CONTENT

LIST OF FIGURES ...... VII

LIST OF TABLES ...... IX

ACKNOWLEDGEMENTS ...... X

CHAPTER 1 INTRODUCTION ...... 1

1.1 Background ...... 1

1.2 Objectives of the Study ...... 2

1.3 Research Problem ...... 2

1.4 Scope of the Study ...... 2

1.5 Organization of Thesis ...... 3

CHAPTER 2 QFD OVERVIEW ...... 4

2.1 Definitions of QFD ...... 4

2.2 Difference between QFD and Other Quality Methodologies ...... 6

2.3 Brief History ...... 7

2.4 Benefits of QFD ...... 8

2.5 Objectives of QFD ...... 11

2.6 Applications of QFD ...... 12

2.7 Problems and Limitations of QFD ...... 14

2.8 Quantitative Approaches of QFD ...... 15 iii

2.8.1 AHP ...... 16

2.8.2 Fuzzy logic ...... 16

2.8.3 ANN ...... 18

2.8.4 The Taguchi Method ...... 18

2.8.5 Statistically Extended QFD ...... 20

2.8.6 Dynamic QFD ...... 21

CHAPTER 3 THE QFD PROCESS ...... 22

3.1 Four-Phase Model ...... 22

3.2 House of Quality (HOQ) ...... 25

3.2.1 Part A. Customer Requirements (WHATs)...... 28

3.2.2 The Kano Model...... 30

3.2.3 Part B. Planning Matrix (WHYs) ...... 33

3.2.4 Part C. Technical Measures (HOWs) ...... 36

3.2.5 Part D. Relationship Matrix between WHATs and HOWs ...... 38

3.2.6 Part E. Technical Correlation Matrix ...... 39

3.2.7 Part F. Technical Matrix...... 41

3.3 Numerical Example ...... 44

3.3.1 The HOQ ...... 53

3.3.2 The Complete QFD ...... 55

CHAPTER 4 ATTEMPTS TO USE QFD IN SOFTWARE DEVELOPMENT ...... 57

4.1 Zultner’s Software Quality Deployment (SQD) Approach ...... 57 iv

4.2 Blitz QFD ...... 62

4.3 Shindo’s Approach ...... 65

4.4 Ohmori’s Model ...... 66

4.5 Herzwurm, Schockert, and Mellis PriFo Software QFD Model ...... 68

4.6 Liu’s Software QFD ...... 71

4.7 Experiences with Software QFD ...... 73

CHAPTER 5 IDENTIFY SOFTWARE ENGINEERING ACTIVITIES THAT ARE

QFD STEPS AND FILLIING THE GAPS ...... 79

5.1 Phase 1 ...... 81

5.1.1 Product Planning in QFD ...... 81

5.1.2 Requirement Phase in Software Engineering ...... 82

5.1.3 How Can a Software Engineer Get Benefits from QFD? ...... 85

5.1.4 What is QFD Missing? ...... 89

5.1.5 Suggestions to Improve QFD for Software Engineering ...... 91

5.2 Phase 2 ...... 97

5.2.1 Parts Deployment in QFD ...... 97

5.2.2 Design Phase in Software Engineering ...... 97

5.2.3 How Can a Software Engineer Benefit from QFD? ...... 98

5.2.4 What is QFD Missing? ...... 98

5.2.5 Suggestions to Improve QFD for Software Engineering ...... 99

v

5.3 Phase 3 ...... 99

5.3.1 Process Design Phase in QFD ...... 99

5.3.2 Implementation Phase in Software Engineering ...... 99

5.3.3 How Can a Software Engineer Benefit from QFD? ...... 100

5.3.4 What is QFD Missing? ...... 100

5.4 Phase 4 ...... 101

5.4.1 Process/Quality Control in QFD ...... 101

5.4.2 Testing Phase in Software Engineering ...... 101

5.5 Phase 5 ...... 102

5.5.1 Maintenance Phase in Software Engineering ...... 102

5.6 An Enhanced Software QFD ...... 103

5.7 A Numerical Example of HOQ ...... 110

CHAPTER 6 CONCLUSION AND FUTURE WORK ...... 114

REFERENCES ...... 118

vi

LIST OF FIGURES

Figure 2.1. Interpretation of Japanese characters for QFD...... 5

Figure 2.2. Japanese automakers with QFD made fewer changes than did U.S. companies

without QFD...... 9

Figure 3.1. The four-phase model of QFD...... 23

Figure 3.2. Brief description of the HOQ...... 26

Figure 3.3. Detailed description of the HOQ...... 27

Figure 3.4. The Kano model...... 30

Figure 3.5. Relationship levels ...... 39

Figure 3.6. Bundles of customer requirements...... 46

Figure 3.7. Relative importance of customer requirements...... 47

Figure 3.8. Customer competitive assessments...... 48

Figure 3.9. Direction of improvement...... 49

Figure 3.10. Relationship matrix...... 50

Figure 3.11. Technical correlation matrix...... 51

Figure 3.12. Technical measures...... 53

Figure 3.13. House of quality (HOQ)...... 54

Figure 4.1. Zultner’s comprehensive approach...... 58

vii

Figure 4.2. Z-0 matrix for classifying users...... 58

Figure 4.3. Zultner’s information deployment...... 59

Figure 4.4. “T”-type matrix...... 61

Figure 4.5. Blitz QFD...... 62

Figure 4.6. Shindo’s approach...... 66

Figure 4.7. Ohmori’s model...... 67

Figure 4.8. PriFo approach...... 70

Figure 4.9. Liu’s SQFD...... 72

Figure 4.10. Satisfaction of the developers with product-related goals...... 77

Figure 4.11. Satisfaction of the developers with project-related goals...... 78

Figure 5.1. Waterfall model...... 80

Figure 5.2. Four-phase model...... 80

Figure 5.3. Enhanced software QFD...... 104

Figure 5.4. GPS example...... 112

viii

LIST OF TABLES

Table 2.1.Summary of QFD Applications in Software Systems ...... 13

Table 4.1.Comparison of Results Achieved between Traditional Approaches and SQFD

...... 76

Table 5.1.Criteria of a Good Requirement...... 84

ix

ACKNOWLEDGEMENTS

Alhamdulillah and Thank to Allah S.W.T. with all gracious and merciful for giving me strength and ability to complete this thesis research successfully. I would like to express my gratitude to all those who gave me the possibility to complete this thesis.

I would like to express my deep and sincere gratitude to my supervisor, Dr.

Melton. His patience, motivation, encouragement and guidance helped me in all the time of research and in writing of this thesis.

I dedicate this thesis to my dearest family members—my parents Omar and

Salwa, my husband Shadi and my daughter Rewa’a for their love and care, support and understanding throughout my study and research.

Leenah O. Alrabghi

December 2013, Kent, Ohio

x

CHAPTER 1

INTRODUCTION

1.1 Background

High software quality results in greater customer satisfaction, competitive advantage for the company, and reduced maintenance costs. Software quality can be viewed as conformance to software requirements from customers (Liu, 2000). QFD builds quality into a product by ensuring that customer requirements are integrated into every stage of the development life cycle. Additionally, QFD enables engineers to compare their products to those of their competitors. Further, it allows the company to become proactive when quality problems arise, instead of being reactive to problems by waiting for customer complaints (Zairi & Youssef, 1995). All information is recorded in a QFD matrix form, making it easily to read and locate.

Major software failures are due to defects in requirements (Jones, 2012). The

QFD method, with its VOC Table, can be used as a tool to carry out requirements analysis activities. Moreover, QFD can manage different phases of the software development life cycle. Experiences in using QFD in the software industry have shown to

1

2

be successful. However, companies are reluctant to share their knowledge due to competitive factors.

1.2 Objectives of the Study

There are four main contributions of this thesis:

 Provides an overview of the QFD concept.

 Develops an understanding of the QFD process.

 Reviews documented attempts to apply QFD to software development.

 Identifies software engineering activities that are QFD steps and determines

what QFD is missing in order to represent the software development life

cycle.

1.3 Research Problem

This study reviews some background information as well as examining QFD experiences in the field of software engineering. The goal is to develop a good understanding of the QFD method. Moreover, this paper makes a comparison of QFD steps and software engineering activities to detect any gaps in the QFD method, as well as discovering QFD tools that can assist engineers to develop high quality products.

1.4 Scope of the Study

This thesis centers on the quality function deployment method. The scope of the study is using QFD in software engineering. QFD was originally developed for the manufacturing industry to produce high quality products. There have been many attempts to use QFD in the development of software products; however, software and hardware

3

have quite different characteristics, and this must be taken into account before applying a method used to manufacture products—such as QFD—into developing software products. Additionally, matching QFD steps to software engineering activities allows us to realize some QFD gaps that are related to software development. Moreover, this matching can uncover tools that can be used to improve the quality of a software product.

1.5 Organization of Thesis

This thesis is structured follows: Chapter 2 aims to give an overview of the QFD method and presents the concept, history, and application of quality function deployment to different areas. Chapter 3 explains the QFD process and how it works. A numerical example is used to develop a better understanding. A review of the previous work done in software QFD is discussed in Chapter 4, along with successful application of QFD in the software development area. Chapter 5 examines and matches QFD steps with software engineering processes. In addition, it proposes an enhancement of the software QFD

(SQFD). Finally, Chapter 6 provides conclusions from this study and suggestions for future work.

CHAPTER 2

QFD OVERVIEW

Quality function deployment (QFD) is a valuable technique for product design and development. It originated in Japan in the 1960s by Yoji Akao. However, it was not until the 1980s that it was introduced to the United States and Europe. QFD is a proactive approach: The majority of time is spent in the planning phase to ensure that quality is deployed into a product before the production begins. This ultimately reduces time, costs, the number of product changes, and startup problems. QFD improves communication among company departments since it requires cross-functional teams to develop its matrices. QFD has been applied in various industries such as manufacturing, software, service, and education.

2.1 Definitions of QFD

Quality function deployment (QFD) was named based on the Japanese characters

Hin Shitsu (meaning quality, feature, or attribute), Kino (function or mechanization) and

Ten Kai (deployment, diffusion, development, or evolution) (Lockamy III & Khurana,

1995). Glenn Mazur (1996), the Akao prizewinner, interprets these Japanese characters for QFD as shown in Figure 2 .1.

4

5

品 Hin – Multitudes’ voices

質 Shitsu – Ax & shell; money, value

機 Ki – Frontier guards attend to detail

能 No – Bear: courage

展 Ten – Unroll train of kimono

開 Kai – Cooperate to open barriers

Figure 2‎ .1. Interpretation of Japanese characters for QFD.

Because these Japanese characters are from the 1970s, there are multiple definitions of QFD. Defined by its founder, Akao (1990), “QFD is a way to assure the design quality while the product is still in the design stage. . . . QFD is [a] method for developing a design quality aimed at satisfying the consumer and then translating the consumer’s demand into design targets and major quality assurance points to be used throughout the production phase” (Akao, 1990). The American Supplier Institute (ASI,

1987) defines QFD: “A system for translating customer requirements into appropriate company requirements at every stage, from research through production design and development, to manufacture, distribution, installation and marketing, sales and

6

services.” QFD is a methodology that concentrates on taking account of quality and its different dimensions during the product design process, integrating quality to a product from the beginning (Lillrank, 1990).

QFD is a quality, planning, and decision-making tool. In addition, it is a customer-driven quality management system for product development. QFD translates the subjective quality criteria and product requirements stated in the customer’s own words into objective, viable product requirements, stated in parameters that can be quantified and measured and then used to design and manufacture the product (Hill,

1992.) It is a methodology for incorporating the voice of the customer, both spoken and unspoken, into a product. In other words, the voice of the customer is translated into the voice of the engineer.

Quality function deployment (QFD) is a structured, multidisciplinary technique for product definition that maximizes value to the customer (Squires).

2.2 Difference between QFD and Other Quality Methodologies

Conventional quality systems focus on minimizing negative quality in a product, such as eliminating defects and reducing faults and errors. However, a company can have a zero defect product and still not be able to sell its product. This is because it has given more weight to the engineering capabilities and less to customers’ needs. Moreover, in a highly competitive market, a zero-defect product is not enough: A company must maximize customer satisfaction (Akao, 1990).

7

QFD uses a quite different approach. It adds values to the product by maximizing positive qualities, such as ease of use, fun, and luxury. Customer requirements—both spoken and unspoken—are addressed by QFD (Akao, 1990).

2.3 Brief History

QFD was first proposed by Shigeru Mizuno and Yoji Akao in Japan in the 1960s.

Previous quality control approaches had focused on fixing a problem during or after manufacture; however, the goal of QFD is to design customer satisfaction into a product before manufacture.

In 1966, a large-scale application was first presented by Kiyotaka Oshiumi, who was working with Bridgestone Tire Company in Japan. His method used a process assurance items fishbone diagram to identify customer requirements (effect) and identify the design substitute quality characteristics and process factors (causes) needed to control and measure it (Mazur).

QFD attracted little interest in the beginning; that is, until 1972, when QFD was adapted to design an oil tanker at the Kobe shipyard of Mitsubishi Heavy Industries Ltd using the fishbone diagram. Ultimately, the fishbone diagram turned out to be impractical; the effects in the diagram share multiple causes. The process was then illustrated through quality Tables with the rows being desired effects of customer satisfaction and the columns being the controlling and measurable causes. Further, the value engineering principles established by Katsuyoshi Ishihara combined to develop the comprehensive QFD system (Akao & Mazur, 2003; Jnanesh & Hebbar, 2008; Zairi

& Youssef, 1995).

8

The first book on QFD was Quality Function Deployment (Mizuno & Akao,

1978). The book was published in Japanese but translated into English in 1994 (Jnanesh

& Hebbar, 2008). Toyota Auto Body adapted QFD in the late 1970s and made refinements to the quality Tables.

The first annual QFD Symposium was held in Japan in 1983. The same year,

QFD was first formally introduced to the United States and Europe, and the American

Society of Quality Control published an article of Akao’s work in Quality Progress

(Kogure & Akao, 1983). Additionally, Cambridge Research (today, Kaizen Institute) invited Akao to Chicago to give a four-day QFD seminar on corporate-wide quality control and quality deployment. Bob King and GOAL/QPC began to sponsor annual

QFD lectures to American audiences from 1986 to 1990. The North America QFD

Symposium led by Robert M. Adams in 1989 helped spread and expand the use of QFD in the United States. Furthermore, the QFD Institute was established in 1994, and in1996 founded an annual Akao Prize to award 25 recipients for their excellent work in developing and disseminating QFD (Akao & Mazur, 2003).

2.4 Benefits of QFD

Quality function deployment (QFD) offers many benefits to its practitioners.

Figure 2.1 shows the number of changes in the automaker industry, both in the United

States and Japan. According to Akao (1990), Tamagawa University and the University of

Michigan conducted a survey on trends in QFD applications. Eight hundred companies

(400 apiece) were selected from both Japanese and US companies with similar background on QFD. The identical survey was sent to both countries’ participants. One

9

hundred forty-six Japanese companies, and 147 US companies responded. The companies were asked how they used QFD. The highest responses were:

 To attain better design and better customer satisfaction;

 As a tool for cross-functional communication and coordination;

 To shorten the product development cycle time. (Akao, 1990)

Figure 2‎ .2. Japanese automakers with QFD made fewer changes than did U.S. companies without QFD.

Many studies reported the benefits of QFD (Zairi & Youssef, 1995; Jaiswal, 2012;

Carnevalli & Paulo, 2008):

 Defines product specifications and characteristics that meet customers’

requirements and priorities while paying attention to competitors. This leads

to greater market share, increased revenue, reduced complaints, and better

reaction to marketing opportunities;

10

 Proactively focuses on the customer in the early design stages. Critical items

are identified for parameter design, and product planning is much easier to

carry out;

 Mistaken interpretations of priorities and objectives are minimized since

planning takes place at an earlier stage;

 Leads to major reduction in development time, costs, cycle time, number of

project changes, and startup problems;

 Improves reliability by guaranteeing consistency between the customer’s

requirements and the measurable specifications of the product, as well as

between the planning and the production process;

 Informs and convinces all those responsible for various stages of the process

about the relationship between the quality of the output at each phase and the

quality of the finished product;

 Leads to a satisfied, delighted customer;

 Improves communications, creates multifunctional teams from various

disciplines, and facilitates and encourages teamwork and participation. This

helps in decision making and priority definition;

 Increases the precision of the quality and productivity of service in a continual

improvement process that, in turn, helps the company reach world class;

 Creates a strong database of customer understanding and internal

effectiveness and external competitiveness. This preserves the company’s

knowledge.

11

2.5 Objectives of QFD

Jaiswal (2012) listed some objectives of QFD:

 Creates value for customers through improving the approach in which new

products are developed;

 Recognizes the customer;

 Defines customers’ needs;

 Establishes a way to meet customers’ requirements;

 Outlines product specifications that meet the customers’ real desires;

 Includes all information needed to design a product or service, without

excluding any point of view;

 Provides competitive benchmarking support;

 Maintains consistency between the planning and manufacturing processes of a

product;

 Offers an inventory of audit trail from the manufacturing floor back to

customers’ demands;

 Provides automatic documentation of the project during its evolution;

 Determines current technical measures that are closely linked to customers’

requirements;

 Identifies current technical measures that are redundant;

 Defines new customer-related technical measures that are required;

 Recognizes conflicts among different performance measures;

 Identifies target values for technical measures;

12

 Outlines the difficulty level in accomplishing the target values for specific

performance measures.

QFD has three major objectives: identify the customer, identify what the customer wants, and learn how to fulfill those wants (Zairi & Youssef, 1995).

2.6 Applications of QFD

Shipbuilding (Nishimura, 1972) and electronic industries (Akao, 1972) were the first two areas in which quality function deployment were applied. Zultner (1994) has categorized the applications of QFD into three main groups: hardware, software, and service. However, with extensive use of QFD, the spread of QFD application has moved to every field. It is difficult to find any area of industry in which QFD has not been used.

Chan and Wu (2002) classified applied industries of QFD as follows: transportation and communication, electronics and electrical utilities, software systems, services, education, and research. The application of QFD to software systems is summarized in Table 2.1.

13

Table 2‎ .1.Summary of QFD Applications in Software Systems

Counts Application area Authors

Anonymous (1993b), Barnett and Raja (1995), Basili and Musa (1991), Brown (1991b), Chang (1989), Elboushi and Sherif (1997), Haag et al. (1996), Haavind (1989), Herzwurm et al. (1997, 2000), Karlsson (1997), Kekre et al. (1995), Liu et al. (1998), Liu (2001), 1 Software Ouyang et al. (1997), Richardson (2001), Roche and Jackson (1994), Thackery and Van Treeck (1990), Xiong and Shindo (1995), Yilmaz and Chatterjee (1997), Yoshizawa et al. (1990), Zhou (1998), Zultner (1990, 1992)

Decision support 2 Sarkis and Liles (1995) systems

3 Expert systems Ngai and Chow (1999)

Human–machine 4 Nibbelke et al. (2001) interface

Chang and Lin (1991), Erikkson and McFadden (1993),

5 Information systems Han et al.(1998)

6 Integrated systems Wasserman et al. (1989)

7 Management Eyob (1998)

14

information systems

8 Profiling systems LaSala (1994)

9 Web pages Tan et al. (1998)

2.7 Problems and Limitations of QFD

QFD has numerous applications; nevertheless, there have been some problems associated with its implementation (Zairi & Youssef, 1995; Jaiswal, 2012; Chan & Wu,

2002; Carnevalli & Miguel, 2008):

 Because QFD deals with huge amount of data, it can become unmanageably

large and complex. This can result in higher data storage, manipulation, and

maintenance costs;

 A QFD process can take long time to develop;

 Finishing QFD behind schedule does not allow changes to be applied;

 QFD is mainly a qualitative method, especially when it comes to interpreting

the customers’ voice since it is usually subjective and ambiguous;

 It is difficult and time consuming to input and translate large amounts of

customer needs into measurable product characteristics;

 The relationship between customer requirements and technical measures is

sometimes difficult to determine;

 Since QFD is an ongoing process, an error in one phase can spread to

successive phases;

15

 Some QFD practitioners limit their use of QFD to the first phase only;

 While the degree of the relationship in QFD is imprecise, the values used to

determine the strength of relationships are absolute, implying that accurate

and representative data are available;

 Target values setting are often vague.

To overcome QFD’s tendency to become unmanageably large, Carnevalli and

Miguel (2008) listed some solutions, such as controlling the size of the matrix by limiting the number of items in the quality matrix. Another strategy is to split the project into manageable sub-charts, to enable exploration of data in smaller matrices; however, doing so can produce new problems as it does not consider the relationship between customer requirements and product characteristics.

2.8 Quantitative Approaches of QFD

To make QFD more practical and address some of its limitations, a number of quantitative techniques have been used to extend QFD’s use (Mehrjerdi, 2010;

Bouchereau, & Rowlands, 2000; Chan & Wu, 2002):

(1) Analytical hierarchy process (AHP).

(2) Fuzzy logic set theory.

(3) Artificial neural networks (ANN).

(4) The Taguchi method.

(5) Statically extended QFD.

(6) Dynamic QFD.

16

2.8.1 AHP

Developed in 1980, the analytical hierarchy process is a multi-criteria decision- making method. A pair-wise comparison of elements in a level of hierarchy with respect to an element of the preceding level is applied to produce a relative importance of criteria. AHP can deal with comparisons made by human natural language and convert them into a ratio scale. The decision-making process is made based on the best information available.

In conventional QFD, the cross-functional team defines the relationship between customer requirements and technical measures using a Likert scale, such as 1-5-9. It is not an easy task to correlate subjective customer needs with quantitative measurable product features.

Moreover, because team members have different perceptions of a particular linguistic description, mixing AHP with QFD can be used to determine the strength of the relationships between customer requirements and technical measures (Partovi, 1999).

Further, AHP can be used with QFD to help define the degree of importance of the demanded quality (Myint, 2003) and help in correlations among the data in the matrices

(Partovi, 2001, 2007).

2.8.2 Fuzzy logic

The idea of fuzzy logic or fuzzy set was presented in 1965. This can model vagueness or uncertainty in the data in a formalized way. It approximates the characterization of phenomena that are too complex to be described in quantitative terms.

Fuzzy logic can handle fuzzy qualitative linguistic data. Because of its ambiguity, it is

17

hard to input human words and sentences directly into the system; for instance, “height” can be treated as linguistic variables if its values are “tall,” “not too tall,” “short,” and

“very short.” A linguistic variable can belong to more than one set. Someone who is

6 feet tall belongs to both the “tall” and “not too tall” group to different degrees.

Fuzzy logic is used in conjunction with QFD in three areas:

 Interpreting the customers’ voice;

 Filling the relationship matrix;

 Customer evaluation of competitive analysis.

Customer requirements are presented using the customers’ own words, which are often ambiguous and imply different meanings. These linguistic requirements are qualitative data, such as “the part size must be small.” In QFD, the engineers must translate these subjective needs into measurable, quantitative product features.

Determining the relationship between customer requirements and technical measures is also a difficult task. Fuzzy logic assists the QFD team in this subjective decision-making process. Additionally, the symbols used to fill in the relationship matrix are linguistic variables that can be converted to fuzzy numbers using fuzzy logic. A range of values can be used to represent a linguistic variable that forms a “strong,” “medium,” or “weak” relationship.

The third area of QFD that can exploit the use of fuzzy logic is competitive analysis. Since the data gathered from customers is considered a linguistic variable, it cannot be quantified easily with a linear scale; a conversion scale is used to convert linguistic terms into their fuzzy equivalents.

18

2.8.3 ANN

Artificial neural networks (ANN) are mathematical models inspired by the nervous system in the human brain. ANN is comprised of nodes called “neurons” connected through “weighted” connections. These are considered adaptive systems since they can learn from experience and do not rely on theoretical information only. ANN imposes some features that can benefit QFD, such as (1) the capability to deal with data both large and vague, adaptively learning from examples, (2) the ability to identify composite relations among input variables, and (3) decreased development time by discovering underlying associations.

ANN can be integrated with QFD to reduce the difficulty of analyzing huge amounts of data. ANN can learn from example and generalize functional relationships, which can help with determining the value in the relationship matrix. In fact, ANN has been used to automatically evaluate data by learning from example, as in machine- learning approaches (Zhang, 1996). The engineering solutions of the product can combine with ANN to predict weighting that represent customer satisfaction. The outcome will determine the value in the customer competitive analysis instead of making the customer subjectively evaluate competitors.

2.8.4 The Taguchi Method

Taguchi methods are blends of engineering and statistical approaches developed by Dr. Genichi Taguchi. The objective is to reach enhancements in the cost and quality of a product.

19

Achieving enhancements in product/process costs and quality is accomplished through design optimization. Taguchi wants to find the best combination of inputs or parameters (control factors) to reduce the sensitivity of engineering designs to uncontrollable factors (noise). The combination of design of experiments (DOE) with optimization of control parameters helps obtain “best results.” Dr. Taguchi has made three main contributions:

1. The quality loss function.

2. Orthogonal arrays.

3. Robustness.

Features in the Taguchi method that can benefit QFD include:

 Interactions among features can be modeled;

 The loss function can be used to set the target values;

 Relationship between needs can be identified;

 A product produced by the Taguchi method is robust against variations in

environmental conditions.

The Taguchi method can be exploited in the process planning matrix (the third phase of QFD) to build best operating conditions for manufacturing. Loss function can be used to determine technical benchmarking in house of quality (HOQ). The QFD team should collect customer data in a real environment where the customers live and work.

The performance and variation of a product/process can be found using different customer environments. The quality loss function curve can define an exact target value that shows how satisfied the customer in numerical values. QFD does not deal with

20

dynamic customer requirements. Taguchi’s inner–outer array table can be used to find the most robust technical measures to satisfy a range of customer importance ratings. The customer requirement is used as the outer array (noise) and the technical measures as the inner array. After that, the team looks at arrangements of the product, and a customer agreement index is placed in the matrix. The signal to noise (S/N) ratio is then calculated.

The bigger the value, the better; nominal is best, and smaller is better. The most robust parameters are determined through the value of the S/N ratio. The resulting matrix is robust against changes in customer requirements.

2.8.5 Statistically Extended QFD

An asymmetric fuzzy linear regression approach is used to estimate functional relationships (Fung, 2006). The least-squares regressions are combined into fuzzy linear regression. This makes two hybrid linear programming models with asymmetric triangular fuzzy coefficients that help determine the functional relationships under uncertainties. These coefficients are then extended to asymmetric trapezoidal fuzzy coefficients. The result is a pair of hybrid linear programming models with asymmetric trapezoidal fuzzy coefficients.

An evidential reasoning (ER) based technique is used for synthesizing various types of assessment information. ER can assist QFD team members in prioritizing design requirements while considering customer requirements and customer preferences (Chin et al., 2008).

A decision framework for enterprise resource planning (ERP) software selection was proposed by Karsak and Ozogul (2009) using QFD fuzzy linear regression and zero-

21

one goal-programming tools. The resulting framework takes into account demand characteristics and system characteristics. At the same time, relationships among company demands and ERP system characteristics, and the interactions among ERP system characteristics are integrated.

2.8.6 Dynamic QFD

A dynamic approach is introduced to transform customer needs into product characteristics (Adiano & Roth, 1994). The advantage of this method is in using feedback loops to integrate the updated customer satisfaction data and evolve requirements into manufacturing and related processes. Subsequently, an HOQ was applied at A&T to enable exhaustive quantitative analysis of how different thrusts and initiatives address separate elements within the criteria.

“QFD strategy house” is a modified method to combine intelligence on markets, customers, and technologies in strategy improvement by connecting marketing and manufacturing strategies. The alignment of these two strategies has shown to offer competitive advantage in the marketplace.

CHAPTER 3

THE QFD PROCESS

There are two popular types of QFD: Matrix of Matrices and the four-phase model. Matrix of matrices was created by Akao (1990). However, the model consists of about 30 tables, charts, matrices, or other diagrams. Hence, it is considered massive and extensive (Cohen, 1995). The four-phase model was developed by Hauser and Clausing

(1988), and American Supplier Institute (ASI) has adopted it as its commonly used model. The four-phase model was considered and used in this thesis.

3.1 Four-Phase Model

The QFD method is inherently flexible, and practitioners of QFD differ in their applications of QFD. It is more of an art than a scientific method (Özgener, 2003). A typical approach to the four-phase model of QFD is shown in Figure 3 .1:

22

23

Figure 3‎ .1. The four-phase model of QFD

In the four-phase model of QFD, a matrix is used in each phase to translate customer requirements from the initial planning stages through production control. Each phase, or matrix represents a more specific aspect of the product’s requirements. Each matrix consists of a vertical column called “WHATs” and a horizontal row called

“HOWs.” “WHATs” are customer requirements (CR); “HOWs” are ways of achieving them or the technical attributes (TR). At each stage, only the most important aspects from

“HOWs” are deployed into the next phase as “newWHATs” (Shahin, 2005). The first phase is called house of quality (HOQ). Each phase can be treated as an HOQ. These four phases are extended throughout the entire system’s development life cycle. Nevertheless, huge amounts of organization focus on HOQ only (Hauser & Clausing, 1988). This is due to the lack of detail on how to develop the subsequent QFD phases. Furthermore, the three phases of QFD have almost the same structures and analyzing methods of the HOQ phase (Chan & Wu, 2002).

The four phases are:

24

Phase 1 – Product Planning (House of Quality): Product planning (also called the house of quality) is led by the marketing department. Many organizations stop at this phase of a QFD process. In Phase 1, qualitative customer requirements and expectations are translated to design-independent, measurable characteristics of the product. In addition, the following aspects are documented: warranty data, competitive opportunities, product measurements, competing product measures, and the technical ability of the organization to meet each customer requirement. Gathering good and correct data from the customer in Phase1 is crucial to the success of the entire QFD process.

Phase 2 – Product Design (Parts Deployment and Planning): Led by the engineering department, creative and innovative team ideas are involved in this phase.

Product design concepts are created to fulfill the prioritized target values during this phase; part and component specifications are identified. Parts that are determined to be critical to satisfy customers’ needs are then prioritized and used as input for process planning, or Phase 3.

Phase 3 – Process Planning: This phase is led by manufacturing engineering.

Critical properties and parameters are transferred to detailed prioritized manufacturing processes, key process control, and improvement parameters. Manufacturing processes are then flowcharted; key process control and improvement parameters (or target values) are set.

Phase 4 – Process Control (Quality Control Chart or Production/Operation

Planning): Performance indicators and production instructions are created to monitor the production process, maintenance schedules, and skills training for operators. Moreover,

25

control and reaction plans are created to prevent failures. Thus, the final phase is led by the quality assurance department in conjunction with manufacturing to ensure manufacturing is implemented according to these exact instructions and that the quality of parts and process is maintained. (Creative Industries Research Institute)

3.2 House of Quality (HOQ)

The term house of quality comes from appearance of the matrix that looks like a roofed house. HOQ is the basic design tool of quality function deployment (Hauser

& Clausing, 1988). It is the first and most important of the QFD matrices. It relates customer qualitative needs to high-level internal measurable technical design requirements using a planning matrix. The outputs of the HOQ are the most important technical requirements in relation to both customer requirements and competitive analysis. This is beneficial to the engineers, as they can trace each requirement back to its source. Consequently, the engineers and developers guarantee that they have effectively translated the voice of the customer (Chan & Wu, 2002). An HOQ diagram with its six main parts is shown in Figure 3 .2.

26

Figure 3‎ .2. Brief description of the HOQ.

The House of Quality matrix consists of six main elements:

1. Customer requirements (WHATs).

2. Planning matrix.

3. Technical measurement (HOWs).

4. Relationship matrix between WHATs and HOWs.

5. Technical correlation matrix.

6. Technical matrix.

27

The sub-parts of HOQ are presented in Figure 3 .3. A detailed description of each of these elements follows (Chan & Wu, 2002; Mehrjerdi, 2010; Govers, 1996; Tapke et al., 2009):

Figure 3‎ .3. Detailed description of the HOQ.

28

3.2.1 Part A. Customer Requirements (WHATs)

Quality function deployment is derived with the customers. Determining the voice of the customer is a complex task that includes several steps: First, the HOQ team must identify the product’s customers, determine their requirements (affinity and tree diagrams can be used to organize these needs), and expose the relative importance of these needs as perceived by customers. It is important to be updated on changes to customers’ voice since it is a continuous process. Feedback must be gathered to ensure that trends of requirements are captured.

A1. Customer Identification. The first step is to identify the product’s customers. In general, there are three types of customers: internal customers, intermediate customers, and ultimate customers. Shareholders, managers, and employees are considered internal customers, while wholesale people and retailers are intermediate customers. Ultimate customers are the main customers, such as recipients of service, purchasers, and institutional purchasers.

A2. Customer Requirements (WHATs). The next step is to determine the customer requirements for the product. Customer requirements are also called voice of customers (VOC), customer attributes (CR), customer needs, or demanded quality. In this thesis, the term “customer requirements” is used.

There are many methods to collect customer requirements: surveys, focus groups, individual interviews, product in use, listening and observing, natural field contact, feedback, complaints, warranty data, sales records, and publications.

29

Individual face-to-face interviews are more cost effective than are focus groups; to collect 90–95% of the entire possible customer requirement, there should be 20–30 customers interviewed. Mail/telephone surveys are difficult to manage regarding the scope of responses and inadequacy of the response rate. Therefore, they are inappropriate for gathering qualitative data, such as customer requirements (Griffin & Hauser, 1993).

It must be noted that customers usually reveal their requirements and needs in terms of “how” the need can be satisfied and not in terms of “what” the need is. This bounds development alternatives. Therefore, analysts must ask “why” until they truly understand the exact need.

Frequently, customers express their requirements too generally or too detailed to be used directly as formal customer requirements. Further, the massive amount of interview notes, requirements documents, market research, and customer data need to be organized to express significant customer requirements. Affinity diagram or a tree-like hierarchical structure is useful to form various levels of customer requirements. Brief statements that capture crucial customer requirements are recorded onto cards. Then, a data dictionary is developed to describe these statements to avoid any misinterpretation.

After that, these cards are arranged into logical groupings or related needs. This helps remove any redundancy within the requirements. Customer requirements can usually be structured into a hierarchy of primary, secondary, and tertiary requirements.

30

3.2.2 The Kano Model

In addition to capturing “stated” or “spoken” customer requirements, “unstated” or “unspoken” requirements should be identified. The distinction between expressed requirements and implicit requirements is made by the Kano model in Figure 3 .4.

Dr. Kano developed the Kano model with students in Japan and reported their results in a paper called “Must Be Quality.” Kano model relates customer satisfaction to the degree to which product features (or requirements) are achieved. The expressed requirements are usually called “stated,” “spoken,” or “revealed” requirements. Implicit requirements or “not verbalized” requirements fall into categories: expected and exciting requirements. The three types of requirements based on Kano’s model are:

 Revealed requirements.

 Expected requirements.

 Exciting requirements.

Figure 3‎ .4. The Kano model.

31

Revealed requirements—also called “normal,” “basic,” and “desired” requirements or “satisfiers”—are those that customers usually ask for. For each revealed requirement, the more you provide, the happier the customers will be. The satisfiers are normally easy to measure and can be found in all the competitive products that provide benchmarks for competitive analysis.

Expected requirements—also called “assumed” requirements or “dissatisfying”— contain crucial product features that customers normally expect, such as having the safety regulations presented with the product. Normally, they are not included in the QFD matrix unless it is necessary to focus on one or more of these requirements. Implementing the expected requirements will reduce customer dissatisfaction, but it will not achieve real customer satisfaction. Expected requirements are usually invisible; the customer will not ask for them. But if they are unfulfilled, they become visible, and the customer will be absent, dissatisfied, and complaining.

Exciting requirements—also called “delighters”—are new capabilities or “out of ordinary” functions that will cause customer excitement and are perceived as superior value. Applying excitement requirements can lead to a major competitive opportunity and larger market share. These are determined by the engineer, marketing, or customer support representative. Further, observing customers use, maintaining products, and recognizing opportunities for improvement are other ways to obtain exciting requirements. Exciting requirements, as with expected requirements, are normally invisible. They become visible when they are fulfilled and result in customer satisfaction.

32

However, this type of requirement does not leave customers dissatisfied when left unfulfilled. It is represented by the top curve in Figure 3 .4.

As we can see from Figure 3 .4, the straight line represents basic or revealed requirements. The customer will be more satisfied if performance exceeds the desired requirements and dissatisfied if they fall short. This is exactly where QFD is strongest.

QFD makes invisible “unspoken” requirements and strategic advantages visible. It must be noted that a requirement will change over time from exciting to normal and then to essential, when customers will assume these requirements will be included in the product.

Therefore, engineers must look for new exciting requirements that would delight the customer.

Satisfiers (basic requirements), not delighters (exciting requirements), are often used in QFD. Exciting requirements are unique for each case and are not normally expressed by the customer. Engineers must work to discover these exciting requirements since they offer competitive advantage for companies. The customer and the company can help establish these delighters: Customers can be lead to reveal imaginative requirements for a product, and the development team can be creative in designing product features. This issue remains a challenge in QFD.

According to Chan and Wu (2002), an example of the Kano model lies within the story of two phone companies: Lucent Technologies and the Nortel Networks in the case of optical fiber telephone switches. Lucent Technologies had become much more popular than Nortel Networks; however, in 1995, Nortel decided “to build network gear that would zap data at speeds of 10 billion bits per second through a single strand of optical

33

fiber. Nortel’s phone company customers weren’t asking for anything nearly that fast, but they liked what they saw. Today, Nortel has 45% of the exploding optical transmission switch market. That compares with just 15% for Lucent, which decided in 1996 to develop a slower switch precisely because its customers weren’t asking for anything faster

A3. Relative Importance of WHATs. Customer requirements are diverse and have different priorities. All these requirements must be considered and balanced to build a successful product. The following step of QFD determines relative importance of the customer requirement. Relative importance shows how crucial fulfilling a requirement is to customer satisfaction. To make best use of the company resources, the development team would start working on the most important customer requirements and neglect the insignificant customer requirements. The customers are asked to provide numerical ratings for each WHAT item in terms of importance to the customer, using 5-, 7-, or 9- point scale or a 1–10 scale. These numbers will be used later in the planning matrix.

Adequate numbers of customers should be surveyed to provide statistical significance.

Thus, this quantitative information is usually gathered using mail or telephone surveys— not by focus groups or individual interviews, which are high in cost. Moreover, fuzzy methods are used to address the vagueness and subjectivity in people’s assessment.

3.2.3 Part B. Planning Matrix (WHYs)

Also called “WHYs” because they indicates why engineers should work on some

WHATs using other parts of HOQ, such as customer competitive evaluations, strategic goals, sales points, and strategic importance of WHATs. In Part A, qualitative customer

34

requirements are documented. Part B is about reporting quantitative data about the requirements. In the planning matrix, customer competitive assessments and evaluations of the company’s product are compared with its main performance on customer requirements. Looking at these comparative evaluations, the company can establish strategic goals for the product to gain better customer satisfaction. Also, sales points can be concluded specify the company’s competitive positions and opportunities. Strategic importance can come from information in Parts A and B.

B1. Customer Competitive Evaluation. At the beginning, competitors with product x—similar to z product being developed—must be identified. It is crucial to determine the company’s strengths and weaknesses in all aspects of a product and in comparison with its competitors to gain competitive advantage. This evaluation information can be gathered by asking customers to rate the relative performance of the company and its competitors on each WHAT and then combine the customers’ ratings.

Just as the relative importance of WHATs, competitive evaluation can be done using a suitable numerical scale. Also, mail and telephone surveys are useful to collect this type of information, as opposed to focus groups or individual interviews. It must be noted here that customers must rate only the product(s) they use and with which are quite familiar.

Hence, a larger number of customers are needed to obtain a sample that represents and maintains statistical significance. The resulting outcomes will assist the developer in knowing where the product is located on the market. Further, it can help to identify how to satisfy the customer.

35

Competitive evaluation for a new product can be a challenge. The QFD team can select the closest applications or make an in-house review of the best current offerings.

B2. Strategic Goals for WHATs. From the competitive evaluation, the QFD team knows the company’s performance and the competitors’ performance on each customer requirement (WHAT). In this step, the team sets goals for each WHAT. These goals must be numerical and consistent with the rating scale already developed. In addition, the goals must realistic and take into account program timing, resources, cost objectives, and available technology. Setting these goals will reveal the types of activities the company will follow to better satisfy customer requirements. Such activities include:

 Improve through QFD implementation;

 Hold/preserve your current position);

 Copy a competitor (this is a weak option);

 Reduce (dangerous, since you may overkill a customer need). (Chan & Wu,

2002)

B3. Sales Points of WHATs. Using the previous information, a company can determine sales points for customer requirements. A sales point describes the company’s capability to sell the product based on how well each customer requirement is met. When the company and its competitors are all doing poorly at a WHAT, the reason can be a bottleneck in technology that the company can improve the product by technological breakthroughs. Therefore, a sales point specifies an opportunity that will give the company a unique selling proposition. As a result, if there is an important WHAT, where each comparing company is rated poorly, then a “strong” sales point is reserved. A sales

36

point is “moderate” if either the importance rating or competitive opportunity is not high and a “no” sales point indicates no business opportunity. The ratings 1.5, 1.25, and 1 are used to indicate “strong,” “moderate,” and “no” sales points, respectively. Entropy methods can be used to gain important weights of a set of decision attributes to reveal the

WHATs’ competitive priorities.

B4. Strategic Importance of WHATs. Also called “final importance rating,”

“row total,” or “planning weight,” this can be acquired for each customer requirement

(WHAT) using the following formula:

The strategic importance is calculated by multiplying the strengths and weaknesses of the company against its competitors with customer priorities and sales point. The customer requirement with the maximum importance rating means high business opportunity to the company and, therefore, must be prioritized. Hence, the company will develop a strategy to improve their product and put its effort where it can get its maximum advantage.

3.2.4 Part C. Technical Measures (HOWs)

This part deals with technical measures (HOWs) also called “technical attributes,”

“voice of the engineer,” “technical attributes,” “technical specification,” “design characteristics,” “engineering characteristics,” or “technical descriptors” constructed by the product development team. A list of performance measures can be generated by

37

looking at improvements (Part B3) that need to be made. For more analysis and deployment, the units and directions of goodness or improvement of these HOWs are also determined.

C1. Technical Measures (HOWs). Transforming customer requirements into the language of business or “technical measures” (HOWs) is done in this step. In other words, the voice of the customer is translated into the voice of the engineer. They are referred to as “HOWs” because they are the answers to how customer requirements can be addressed or satisfied. HOWs are methods, company measures, design requirements, substitute quality characteristics, engineering characteristics, and attributes about the product or service that can be related to and measure customer needs (WHATs) and benchmarked against the competition. According to ASI, good HOWs should be measurable, global, and proactive. In practice, technical measures can usually be generated from current product standards. These HOWs may exist in the company and are already used to determine product specification; however, new measurements can be developed to ensure that the product is meeting customer requirements. HOWs can be selected using cause-and-effect diagram to ensure that the HOWs are the first orders causes for the WHATs. The Affinity Diagram method is a useful tool to a hierarchical structure that aids analysis and implementation.

It is important to note that technical measurements are not solutions. In addition, the team must ensure that it has at least one technical measure (HOW) for each customer requirement (WHAT).

38

C2. Units of HOWs. Each measure should be associated with a unit and a direction, which are the following two QFD steps. Defining the units of the HOWs explicitly helps improve clarity and completeness of the QFD. Examples of units include time in minutes, length in feet, capacity in gallons, energy in foot-pounds, resistance in pounds per square foot, process complexity in number of steps, quality in defects per thousand pieces or defects per million, and so on.

C3. Direction of Goodness of HOWs. Also called “direction of improvements,” there are three possible definitions for HOWs: the more the better (to increase), the less the better (to decrease), and target is best (to close to).

3.2.5 Part D. Relationship Matrix between WHATs and HOWs

The Relationship Matrix of WHATs versus HOWs is used to identify degree of relationship or linkage between each WHAT and each HOW or customer requirement and the performance measures designed to improve the product. It is placed in the center of HOQ and completed by the QFD team. It is an essential step in the QFD process since the concluding analysis stage relies heavily on the relationship of WHATs versus HOWs.

Because the development team defines the HOW, it is easier for them to fill the

Relationship Matrix in a column- or HOW-wise fashion to see how much each of the

HOWs satisfy each of the WHATs. Additionally, the QFD team can investigate the impact of each HOW on each WHAT, and then determine the degree of this impact as the relationship.

There are four relationship levels: no relationship, weak/possible relationship, medium/moderate relationship, and strong relationship with weights of (0, 1, 3, 9) or

39

(0, 1, 3, 5), respectively (the first scale is more commonly used because it allocates a much greater weight to the strong relationship, it seems more suitable.) While numeric values can be used, the relationships are typically indicated using symbols. A double circle or filled circle is used for a strong relationship, a single circle for a moderate relationship, and a triangle for a weak relationship, as represented in Figure 3 .5.

Relationships

Strong ●

Moderate ○

Weak ▽

Figure 3‎ .5. Relationship levels

The relationship symbol is written in the intersection cell. The team should review the Relationship Matrix, asking: Have all customer needs or requirement been addressed?

Are there product requirements or technical characteristics stated that don’t relate to customer needs?

3.2.6 Part E. Technical Correlation Matrix

The Technical Correlation Matrix is probably the least used. Technical measures often conflict with each other. The technical correlation matrix—more often referred to as the Roof—is the development team’s assessments of which HOWs are interrelated and

40

the strength of these relationships. This can be acquired through engineering analysis and experience. The objective is to identify the impacts that technical requirements have on each other; which “HOWs” items support one another and which are in conflict. This part, as Cohen (1995) mentions, is probably the most underexploited part of QFD, yet its potential benefits are great. Working to improve one may help a related requirement.

However, working to improve one requirement may negatively affect a related requirement.

This step is critical in identifying engineering tradeoffs or the co-relationship among HOWs. It is clear for the development team that changing one HOW will be affect other HOWs. The degrees of relationship and directions have tremendous impacts on the development effort. Each HOW is compared to others, one by one. For each pair of

HOWs, the QFD team must answer the following question: Does improving one requirement cause deterioration or improvement in another requirement?

There are five types of technical correlations used to represent the impact each

HOW has on the other: strong positive impact, moderate positive impact, no impact, moderate negative impact, and strong negative impact. These correlations are indicated using symbols of double-plus, plus, blank, minus, and double-minus symbols, respectively. Positive correlation indicate that those pairs of “HOWs” are closely related.

Negative correlation represents conditions that are likely to be bottlenecks in the design that require tradeoffs, special planning, or breakthrough attempts. Too many positive interactions suggest potential duplication in either the customer requirements or technical measures.

41

3.2.7 Part F. Technical Matrix

The purpose of the Technical Matrix is to provide an initial rank ordering of the technical measures’ relative importance based on information obtained from the preceding steps. To better understand the competition, a competitive technical assessment is conducted to compare the company’s performance and its competitors’ performance on each HOW. Additionally, using strategic targets, the technical difficulties to achieve these targets can be identified. After that, the strategic or final importance of the HOWs can be computed from the above information. Finally, only important HOWs are chosen to be inputs to the next phase of QFD.

F1. Relative Importance Rating of HOWs. The objective of relative importance rating is to measure the degree to which a HOW is related to all WHATs. These numbers reflect the importance of each HOW to the customer requirements or WHATs. Two elements affect the relative importance: final importance ratings of the WHATs and the relationships between the HOWs and the WHATs. Therefore, the relative importance rating is equal to the product of relationship rating and customer’s importance rating.

Numbers are then added in their respective columns to determine the importance for each technical measure (HOW) using the following formula:

42

Hence, the amount of a HOW’s relative importance is determined by the average over its relationship values with all the WHATs weighted by their final importance ratings. The results help in recognizing essential product requirements and in the tradeoff decision-making process.

F2. Competitive Technical Assessment. The objective of conducting competitive technical assessments is to evaluate a product’s technical performance and the performance of its competitors’ similar products on the HOWs. This process involves reverse engineering the competitors’ products to determine specific values for competitor technical measure to learn if these technical measures are better or worse than those of competitors. However, this task is not easy. Not all technical parameters of the competitors’ products can be acquired. Sometimes, purchasing and testing the competitors’ products can help. Nevertheless, the QFD team must strive to obtain such comparative information. Inadequate information can have a negative effect on the company’s market share. Still, gathering competitive information can be an obstacle. A team can carefully evaluate the company and its competitors to give reliable scores.

These scores must be consistent with that used in customer competitive evaluations.

F3. Strategic Targets for HOWs. Also called “target goals,” the purpose of this step is to integrate the results from Part F1 (HOWs prioritizations) and F2 (competitive technical assessments) into a set of performance targets to be used during design and implementation. These are also called “HOW MUCHs” of the technical “HOWs” items.

Design specifications and strategic targets are not the same: A target for a HOW represents a level of performance or guidance on the HOW the company believes is

43

required to be achieved for its product to become competitive in the market as well as objectively measure progress. The targets can act as a baseline against which to compare.

A goal for a technical measure should be high if company performance on this HOW is weak compared with the performance of its competitors’ products or if this HOW has initially high relative importance (meaning high impact on the customer requirement).

These goals are specific and measurable. Further, the targets should be reasonable based on the company’s technical resources.

F4. Technical Points of HOWs. Similar to the sale points used to analyze customer competitive evaluations, technical sales points should be obtained for the

HOWs. These sales points help indicate HOWs’ final strategic importance. However, few

QFD studies explicitly use this information to examine the HOWs’ final strategic importance as done in the customer competitive evaluations.

F5. Probability/Difficulty Factors. To establish the feasibility of each “HOW” performance, the team should identify the difficulty or probability to achieve it through engineering and cost analyses. Many factors affect the difficulty of a target, such as technology maturity, personnel technical qualifications, business risk, and manufacturing capability. A high score for a target indicates that it is competitive, risky, and profitable, while a low score indicates a conservative target. Again, the scores scale should be consistent with the scales used in previous parts.

F6. Strategic Importance of HOWs. Chan and Wu (2002) suggest an additional part—Strategic Importance of HOWs—to compute the final importance rating of each

HOW, a comprehensive measure for the HOW’s priority using the same method used to

44

obtain the WHATs’ final importance in Part B. They propose the following formula to compute each HOW’s final importance rating:

In conclusion, a technical measure with high relative importance ratings indicates several meanings: a strong relationship with an important customer requirement, a high score on the competitive evaluations, a great difference between the company’s current performance and what is needed to be achieved (the target), and an easy target to be accomplished must have a higher strategic importance, representing a market advantage for the company.

Only HOWs with high value of strategic importance entered into the second phase of QFD (Parts Deployment) as newWHATs. The process continues for the rest of QFD phases.

3.3 Numerical Example

The structure of QFD is well explained by the popular car door example (Hauser

& Clausing, 1988). In the following, we will apply the previous steps to build the HOQ.

Part A. Customer Requirements (WHATs). After identifying the customers, the next step is to collect customer requirements. The customers would describe their needs for a car door to be “easy to close” or “easy to clean” and allows “no wind sound.”

These needs can be gathered using various approaches, such as focus groups, listening

45

and observing, warranty data, and so on. It is vital to preserve customer phrases used to describe various products’ characteristics, such as: “easy to carry” or “greater speed” since they provides the development team with the customer-perceived quality that, if replaced by designers’ words, may mislead teams in tackling the problems. Customer requirements are usually organized using a tree or affinity diagram. These requirements are then structured into a hierarchy of primary, secondary, and tertiary requirements, as shown in Figure 3 .6. This helps remove redundancies among these requirements.

Asking the customer for input will not reveal all customer requirements. The

Kano model would assist in understanding customer satisfaction. Customers usually state some quality requirements. For example, if the car door is “unsafe in a side collision,” the customer would be dissatisfied even though he did not precisely express that when he asked for his input. This would be an “assumed” or “expected” requirement. Therefore, the team would add regality, retailers and vendors requirements, and so forth. “Exciting quality” are things that goes beyond the customer expectation such as “extra room for storing accessories.” Filling these requirements would increase customer satisfaction. The team should look for clues for “exciting quality” while gathering customer requirements.

After stating requirements, the customer then weights them. This is called

“relative importance” and helps the team determine the most important requirements that needs to be addressed. The weights (usually in terms of percentages) are recorded next to each customer requirement and then summed to a total of 100% (see Figure 3 .7).

46

Figure 3‎ .6. Bundles of customer requirements.

47

Relative Bundles Customer Requirements Importance

Easy to close from outside 7 Easy to open and close door Stays open on a hill 5

Doesn’t leak in rain 3 Isolation No road noise 2

A complete list totals 100%

Figure 3‎ .7. Relative importance of customer requirements.

Part B. Planning Matrix. The next step is to document the position of the company relative to its competitors. Customers are asked to rate the relative performance of the company and its competitors on each customer requirement (WHAT). This is the

“customer competitive assessment.” In Figure 3 .8, all cars are weak on “stays open on a hill.” Therefore, a company can take a competitive advantage on this requirement. On the other hand, the company’s car is the best among other vehicles on “no road noise”; the company must retain that. The competitive assessment helps the company create a strategic plan to achieve better customer satisfaction.

48

Figure 3‎ .8. Customer competitive assessments.

Part C. Technical Measures (HOWs). The subjective customer requirements are translated into objective measurable technical measures that are meaningful to the engineer. Additionally, the team must identify the direction of improvement (see Figure

3 .9). For example, “energy to close door” has a negative sign, meaning that it this negative should be reduced to increase customer satisfaction. A technical measure can affect more than one customer requirement. The resistance of the door seal, for instance, affects three customer requirements. If there is a technical measure that has no effect on any customer requirement, it is redundant. Conversely, an unaffected customer requirement by any technical measure implies a need to expand a car’s physical properties.

49

Figure 3‎ .9. Direction of improvement. Part D. Relationship Matrix between

WHATs and HOWs. Once a customer requirement and a technical measure are identified, it is time to determine the degree of relationship between them. The team must fill up the body of the HOQ to see how much each technical measure affects each customer requirement. The relationship degree is indicted by symbols (see Figure Figure

3 .10).

50

Figure 3‎ .10. Relationship matrix.

Part E. Technical Correlation Matrix. The Roof of the HOQ is used to determine the relationship between different technical measures (see Figure 3 .11). The team looks to see how the modification in one technical measure affects the others. The change of the gear ratio on a car window, for example, could produce a smaller window motor; however, it would make the window go up more slowly.

51

Figure 3‎ .11. Technical correlation matrix.

Engineers can benefit from the Roof in identifying the different product features to be improved collaterally. For instance, improving the window motor requires improving the hinges, weather stripping, and other product features. Another advantage of the Roof matrix is that it helps the team make tradeoffs decisions. “Energy to close the door,” for example, is negatively related to “door seal resistance” and “road noise reduction.”

52

Part F. Technical Matrix. After the relative importance of the technical measures is calculated, the engineers compare the company’s product to its competitors’ abilities in meeting the technical measures (see Figure 3 .12).

When engineers know the position of the company in the market among its competitors using the objective measure ranking, they can define the strategic targets for the HOWs. A target acts as a baseline for the company to achieve for its product to be competitive on the market. Some engineers add other parts to the HOQ, such as degree of technical difficulty (how hard or easy it is to make a change) and estimated cost.

53

Figure 3‎ .12. Technical measures.

3.3.1 The HOQ

The house of quality brings engineers, designers, marketing executives, and managers together to understand each other’s priorities and goals, as shown in Figure

3 .13.

54

Figure 3‎ .13. House of quality (HOQ).

Looking at the first customer requirement—“easy to close from outside”—our company’s car door seems to be harder to close than are other companies’ doors.

Additionally, this requirement has a high degree of importance to the customer. The center of the HOQ shows the technical measures affect “easy to close the door from outside,” “energy to close door,” “peak closing force,” and “door seal resistance.” The

55

engineers decide that “energy to close the door” and “peak closing force” are strongly positively related to this customer need. The Roof of the HOQ shows how these technical measures are related to each other: “energy to close door” and “peak closing force” are strongly positively related to one another; however, other technical attributes, such as

“door seals” and “window acoustic transmission,” are negatively related. After looking at all the different aspects, the team agrees that the advantages outweigh the costs. So, the new car door closing design will have a target of 7.5 foot-pounds of energy.

3.3.2 The Complete QFD

Hauser and Clausing (1988) state the need for the complete QFD phases using the car door example: “Suppose that our team decides that doors closing easily is a critical attribute and that a relevant engineering characteristic is closing energy. Setting a target value for closing energy gives us a goal, but it does not give us a door. To get a door, we need the right parts (frame, sheet metal, weather stripping, hinges, etc.), the right processes to manufacture the parts and assemble the product, and the right production plan to get it built

In QFD, the HOWs from one HOQ become the WHATs of the next HOQ to make the details of the product. For example, the technical measure “energy to close the door” of foot-pounds from the HOQ become the rows in the second phase of QFD, which is called “parts deployment house.” The columns are parts’ characteristics, such as thickness of the weather stripping.

These columns—such as “weather stripping thickness”—then turn into rows in a

“process planning house,” the third phase. The new columns or HOWs are important

56

process operations, such as “rpm of the extruder producing the weather stripping.”

Finally, these process operations become the WHATs in the fourth phase, production planning and production requirements. Items such as: “knob controls,” “operator training,” and “maintenance” become the HOWs.

The QFD starts with the voice of the customer and deploys it through the four phases until the manufacturing process. A 3.6 control knob setting produces speed of

100 rpm, which in turn provides a diameter for the weather stripping bulb that offers good sealing without excessive door closing force. These product specifications maximize customer satisfaction for dry, quiet car with an easy-to-close door.

CHAPTER 4

ATTEMPTS TO USE QFD IN SOFTWARE DEVELOPMENT

4.1 Zultner’s Software Quality Deployment (SQD) Approach

Zultner (1990) is one of the earliest authors to publish a paper about applying

QFD to software development. His model is considered a comprehensive detailed QFD that he called “software quality deployment” (SQD) (Zultner, 1990). He tried to apply

Akao’s extensive QFD on software development, but he believed that deploying quality can be made at different levels of complexity. It can be deployed using only four basic matrices, 30 matrices, even up to 150 matrices. These matrices are used to explore the relations between different dimensions, such as cost, customer demands, facility structure, and so on. SQD tries to solve the problems associated with software development of not properly defining customer requirements. Therefore, the emphasis is on deploying the customer before deploying the quality, as shown in Figure 4 .1.

In information deployment (Figure 4 .3), the software development has some equivalent phases to the four-phase model. There are five phases: Phase0, Phase1,

Phase2, Phase3, and Phase4. SQD starts with deploying the “voice of the customer” or what is called “customer deployment,” which corresponds to the HOQ in the conventional QFD. This first phase is accomplished through the use of Z matrices. To do 57

58

so, the “customer demands” or requirements must be identified. Since there are multiple classes of users and other stakeholders, they must be recognized, understood, and prioritized before working on the HOQ matrix. The additional matrix for classifying the customers is called Z-0 matrix, shown in Figure 4 .2.

Figure 4‎ .1.‎Zultner’s‎comprehensive‎approach.

Users

User Characteristic

Figure 4‎ .2. Z-0 matrix for classifying users.

59

Figure 4‎ .3.‎Zultner’s‎information‎deployment.

The demands of these various stakeholders are collected. Interviews, surveys, team analysis sessions, focus groups, trouble reports, problem logs, and compliments for

60

any existing systems are some of the methods used to gather the requirements. A refinement of these requirements must take place to ensure a clear, reliable statement of user expectations. A matrix is dedicated to organize all these requirements and the relationship between them in a hierarchical structure, along with their user segments.

The stakeholder requirements are then further refined. The analytic hierarchy process (AHP) can be used to prioritize these requirements. These priorities are called

“raw priorities” and can be adjusted by any adjustment factor, such as the number of users in each category. The resulting adjusted priorities are the ones deployed in the HOQ matrix. Raw priorities reveal what the users want most, while the adjusted priorities indicate those users we most want to satisfy.

The following phase translates user requirements into technical requirements, using the HOQ matrix. The method used here is similar to the one used by Hauser and

Clausing (1988) for manufacturing hardware. Nevertheless, Zultner’s model proposes the use of “WHYs” and “WHATs” in software as opposed to the “WHATs” and “HOWs” in the original HOQ matrix. In addition, competitive assessments are explored in more detail in several sub-matrices. As with customer requirements, the technical requirements are prioritized. These priorities are adjusted using adjusting factors, such as sales points and competitive comparison data. The weights of the technical requirements are calculated in the same way as calculated in the traditional HOQ.

Zultner modified the next step in QFD for use in software development. The technical requirements are mapped to data models and process models using a set of “T”- type matrices (Figure 4 .4). Entity relationship diagrams (ERD) and data flow diagrams

61

(DFD) are utilized to structure the data and process models. These entities are further refined into specific statements of what data are required but do not include how to implement them. There is an additional matrix used to map the relationships between entities and processes to guarantee consistency among diagrams. Competitive assessments are also broken into sub-matrices.

The process of SQD is continued to the successive matrices. The procedure of adapting QFD into software includes some modifications, such as replacing material by data, cost by time, and function by process. Zultner’s approach of QFD has other matrices that can be useful in software development at different levels; for example, the feasibility of applying new technologies can be analyzed. New concepts needed to implement these new technologies include associated customer requirements, technical requirements, and the entity types and processes required to meet the technical requirements.

Figure 4‎ .4.‎“T”-type matrix.

62

4.2 Blitz QFD

Richard Zultner (1995) proposed the “Blitz QFD” approach for use in very rapid software development. The concept is to provide the maximum gains from minimum effort. Speed and quality are major needs for software development. Time to get to market has a great impact on software success, as well as on satisfying the customer. A high value product will maximize the customer satisfaction. Therefore, Blitz QFD (Figure

4.5) focuses on finding critical items that would satisfy the customer with its high value and crucial tasks that are time-management. Unnecessary items are removed from Blitz

QFD to get to the market faster with minimum effort. Only requirements that have high value to the customer are deployed in Blitz QFD. This speeds up the process, as fewer numbers of items must be dealt with. Zultner claims that a Blitz QFD does not require the whole requirements to be implemented; rather, a sufficient subset is needed to satisfy the customer needs.

Figure ‎4.5. Blitz QFD.

63

Blitz QFD focuses entirely on the understanding, analyzing, and weighting of customer requirements. It includes seven steps:

1. Go to the Gemba (preparation phase): The Blitz QFD process starts with a

preparation phase called “Gemba,” which means: “the real place where the

product adds a value to the customer and solves its problems” (Jayaswal

& Patton, 2006). The Blitz QFD analysts must go to there to observe

customers and how they interact with their problems. Understanding the

context will discover opportunities that add value to the customer. Questions

are asked, such as: What does “success” mean in this project? Which

customer segments are critical to our success? If we understand what success

is, and who our customers are, where will our software add value to our

customers? This phase will not produce the customer requirements. Customers

would give us statements that must be analyzed to produce well-defined

requirements. The next step involves discovering customer needs.

2. Discover customer needs: Customers are not in the requirements profession;

they only give hints about their needs. To satisfy the customers, analysts need

to understand what they mean by their statements and why they are saying

what they are saying. It is the analyst’s job to discover the requirements

behind the customers’ words.

3. Structure customer needs: Understanding the way customers think about their

needs—the “customer needs structure”—is a powerful way to discover

unstated needs. Affinity diagrams are a useful tool in this case. Actual

64

customers can perform affinity diagrams by themselves to better understand

their own needs.

4. Analyze the customer needs structure: After receiving the affinity diagrams

from customers, the team must now understand them deeply, analyze their

structure, and fill in missing needs. It is important to understand why the items

are arranged the way they are. The team then would transform these affinity

diagrams into hierarchy diagrams to determine stated customer needs and

discover a substantial competitive advantage.

5. Prioritize customer needs: The team now must prioritize customer needs.

Identifying the priorities will produce the needs that will deliver the most

value to customers. The analytic hierarchy process (AHP) can be used for that

purpose.

6. Deploy high-value customer needs: The team can select the top N needs on

which to focus their best efforts. A maximum value table (MVT) can be

utilized to choose the highest-value customer needs. In those requirement lie

the satisfaction of the customer and, consequently, the success or failure of the

project.

7. Analyze (only) important relationships in detail: In this step, it is crucial to

understand how to perform the high-value activities in detail and how to avoid

failure in performing high-value activities. Three tools can help: work

breakdown structure (WBS), a project task table, and a failure modes and

effects analysis (FMEA) table. (Jayaswal & Patton, 2006)

65

Blitz QFD is similar to rapid application development (RAD) techniques in the senses that it focuses on customer satisfaction and does not waste time building something that is not necessary.

4.3 Shindo’s‎Approach

Shindo (1999) characterized software as an intangible product. This is why customers find it difficult to reveal quality requirements. Hence, the first step of Shindo’s approach is functional definition of the product by customers that includes all relevant data for the software being developed (Figure 4 .6). A matrix will hold both function and data and the relationships among them. This will focus the design on function and data.

The software is decomposed using the quantification method of type 3 (QM3) (Kihara,

1992) to gain independent subsystems producing well-structured function and data.

The function point method is used to specify each subsystem’s function, data, and interfaces. Functions with costs that exceed the budget for the project are then sorted out.

After that, each subsystem’s specific requirements are gathered from customers. Quality requirements are entered into the quality tables to identify performance values or quality levels for each function. In addition, engineering bottlenecks are determined through these quality tables. In addition, a database is established based on the QM3 table; algorithms are developed to the desired level of performance; cases are built based on failure modes and effects analysis (FMEA) and function tree analysis (FTA) to effectively test system integration.

Shindo’s (1999) model focuses on the definition of relevant data using QFD, which is a kind of object orientation to QFD.

66

Figure 4‎ .6.‎Shindo’s‎approach.

4.4 Ohmori’s‎Model‎

The Ohmori (1993) approach consists of a complex matrix-matrix-diagram to develop commercial individual software. There are 14 matrices to implement quality deployment, as described in the first two phases of the four-phase model. Ohmori’s model analyzes business systems through several activities that combine all tasks necessary to reach the organization’s goals. Since software is a part of this higher task system, the software function must support some of the system’s tasks. After identifying high-level functions, customer requirements called “software quality requirements” are recognized and set against the product functions (software additional functions) in the

Software-HOQ and (software) quality items in the classic HOQ (see Figure 4 .7).

67

An additional matrix is used to produce design points by deducing the importance of the quality elements for each product function. These design points show which quality elements have to be fulfilled at a higher degree when applying a particular product function. After that, functional product characteristics and individual software components, such as software subsystems or data files, are linked.

There are three phases in Ohmori’s model: a planning phase used to embed the software into a higher business system, a requirement engineering phase, and an analysis phase. The huge number of matrices is a consequence of taking into account quality elements concerning the business system as well as the business software.

Figure 4‎ .7.‎Ohmori’s‎model.

68

4.5 Herzwurm, Schockert, and Mellis PriFo Software QFD Model

In software engineering, QFD aims at product preference setting. The focusing aspects of QFD by means of the HOQ are more important than the deployment by a matrix sequence (Herzwurm, Schockert, & Mellis, 1996). This what motivates the authors to call their approach “PriFo” (prioritizing and focused) Software QFD. The

PriFo QFD team is a cross-functional team put together from various departments, such as development, design engineering, quality management, and marketing, along with customer representatives. The PriFo Software QFD model is also called “joint requirement engineering” (Herzwurm et al., 2000). The PriFo Software QFD Model requires that important changes to the results must be debated and discussed by the entire team. Multiple techniques (e.g., the Seven Management and Planning Tools and the

Seven Quality Tools) are used to gather information needed to build the matrices.

The first step in the PriFo QFD (Figure 4 .8) is the preplanning phase, which includes setting the project’s goals, discussing the schedule, cost planning, and putting together the QFD team. Moreover, the project’s content and customer groups are identified, and customer representatives are selected. It is all about brainstorming sessions and meetings to decide which people should in charge of the project. Ohmori’s matrices from the planning phase can be used to define the product. In addition, Zultner’s customer deployment strategies can be utilized to identify and weight the different customer groups.

In place of a customer survey, the team itself would determine customer needs.

These needs are then classified, structured using affinity and tree diagrams, and weighted

69

using AHP in the voice of the customer table. This is done by as many members of the customer groups as possible under the overall control of customer representatives. If there is any further development of a product, product customer representatives will evaluate these needs according to the level of satisfaction and fulfillment the requirements have already reached. A competitive analysis is costly because customers are not likely able to evaluate competitor’s products at a requirements level. Hence, more customer representatives would usually be consulted. Competitive analysis weighting and identifying satisfaction levels may end up involving a wide-ranging customer survey. The outcome of this process is the “table of customer requirements.”

70

Figure 4‎ .8. PriFo approach

In software, there are functional requirements (product functions) and nonfunctional requirements (quality elements). The table of customer requirements is used as an input to two tables: a software HOQ matrix representing function deployment and a classic HOQ matrix, as in the four-phase model. Similar to the identification of customer requirements, determining the product functions that will be used in the

Software-HOQ is done through the “voice of the engineer table.” The only difference here is that it is done by QFD team, especially developers. Determining the columns in

71

the classic HOQ (the measurable quality elements) takes another internal QFD meeting.

However, filling in the relationships between product characteristics and customer requirements in both matrices is normally done together with customer representatives. A further internal team meeting produces a “table of the most important product functions” and a “table of the most important quality elements.”

The development goals resulting from the product characteristics are linked in a third matrix, according to Ohmori (1999), and are inspected for potential synergy effects and conflicts. They are further narrowed down to two-dimensional design points. The most important product functions, the most important quality elements, and design points establish the basis for setting up a requirements specification as a consequence of the requirements engineering process.

4.6 Liu’s Software QFD

Liu (2000) modified the four-phase model of QFD for the software development process (Figure 4 .9). Software QFD—or SQFD—starts with the “requirement analysis” matrix. In this matrix, customer requirements represent the voice of the customer, and the system technical specification represents the voice of the engineers (the “WHATs” and the “HOWs”). Liu (2000) insisted that “technical features of the system [must] conform to customer requirements. Technical features that have nothing to do with customer’s requirements should be removed from the system specification”.

72

Figure 4‎ .9.‎Liu’s‎SQFD.

The next phase is called the “design phase,” which replaces the part-deployment phase of the four-phase QFD process. The functional and nonfunctional requirements result from the previous phase guidelines by the engineers in their developing of software architecture, module structure, data structures, and user interface. Then they are related in a matrix consisting of technical specifications and design characteristics.

The process deployment of the QFD process is substituted by the implementation phase in SQFD. Here, the design characteristics are correlated with the implementation strategy. Therefore, programming languages and tools are selected based on the design specifications.

The final phase of the QFD process—manufacturing deployment—appears as the testing phase in SQFD. A matrix is used to correlate implementation strategy to the testing strategy. In the testing phase, test methods are established, and testing is conducted to remove defects in the programs.

The SQFD approach developed by Liu (2000) shows a high-level view of the software engineering process. However, there is a light mismatch between the order of

73

phases in the model and real-life software projects. Further, it does not give any detail on implementation.

QFD was initially established to be used in manufacturing products that are

“hardware.” There are some differences between software and hardware that must be taken into consideration:

 Software is an abstract, complex, intangible, and unique product;

 Software is developed rather than manufactured. After developing the first

product, all copies of this software have insignificant cost because software

has no material-based costs;

 Time and data are important factors in software in the overall development

process;

 Communication in software is needed much more than in hardware since it is

a human and creative phenomenon;

 The nature of software makes it hard to control all parameters of the process;

 Technology evolves rapidly. This makes it difficult to reach the achievement

made in one product in all succeeding projects. (Koski, 2003)

4.7 Experiences with Software QFD

QFD has proven to be successful in the field of software development. In addition to the advantages of conventional QFD, there are specific benefits of applying QFD to software development:

74

1. Software QFD (SQFD) relates high-level customer requirements with detailed

system requirements in a coherent fashion (Barnett & Raja, 1995).

2. It integrates satisfaction of customer requirements into all activities of

developing the software, including software architecture design, data structure

design, coding, testing, and so on (Liu, 2000).

3. Traditional software development methods lack a clear identification of how

software designers impact what customers want. Moreover, the conflicts

between customer requirements are not detected in these models. SQFD has

proven to overcome these problems (Liu, 2000).

4. SQFD helps to enhance the communication among different team members,

which reduces the gap between customers and software developers and testers

(Liu, 2000).

5. SQFD has improved outsourcing quality and helped software manufacturers

achieve better competitiveness in the global market (Wei, Wang, & Wu,

2008).

6. Deploying the quality into every phase of software development leads to

fewer changes in requirements specification, design, and code, which in turn

leads to a reduction in the number of defects. Hence, this lowers the overall

cost by reducing rework and increasing productivity (Liu, 2000).

7. It produces high quality software that requires less maintenance, which allows

for budget dollars to be spent on developing new projects (Harty, 2001).

75

8. High quality software provides better market share with better quality and

lower price (Liu, 2000).

9. Better management of nonfunctional requirements. Often neglected in existing

software development methods (Karlesson, 1997).

10. “Traditional software engineering has generally focused on just removing the

‘dis-satisfiers,’ i.e., the defects—this approach is necessary, but not

sufficient!” (Puett III, 2003).

The disadvantages of SQFD are its complexity, time needed for preparing, carrying out, and then evaluating the meetings (Herzwurm & Schockert, 2003).

Haag (1992) analyzed 25 software development projects in six companies: Digital

Equipment, AT&T, Hewlett-Packard, Texas Instruments, IBM, and CSK. These companies gained much advantage from using SQFD to improve the quality of their products. However, the methods they use are not shared because of the competitive advantage they afford the company.

Haag and colleagues (1996) implemented a study about the application of QFD in software development. The study included 37 major software vendor companies, of which 16% identified themselves as users of software QFD (SQFD). The survey used combination of open-ended and closed questions to collect data. They compared the goals achieved by traditional approaches and SQFD. The survey contained 12 goals, and the companies rated the results achieved on a five-point Likert scale: “1” meaning the result was not being achieved, with “5” being the result achieved very well (Table 4.1). The results show that SQFD is superior to traditional approaches in most areas. Only in

76

systems developed within budget and systems developed on time did traditional approaches precede SQFD. However, the difference made to the results of traditional approaches is insignificant.

Table 4‎ .1.Comparison of Results Achieved between Traditional Approaches and SQFD

Mean Mean SQFD Results Achieved Traditional Rating Rating

Communication satisfactory with technical 3.7 4.09 Personnel

Communication satisfactory with users 3.6 4.06

User requirements met 3.6 4.00

Communication satisfactory with management 3.4 3.88

Systems developed within budget 3.4 3.26

Systems easy to maintain 3.4 3.42

Systems developed on time 3.3 3.18

Systems relatively error-free 3.3 3.95

Systems easy to modify 3.3 3.58

Programming time reduced 3.2 3.70

Testing time reduced 3.0 3.29

Documentation consistent and complete 2.7 3.87

77

In 1997, an empirical investigation of 16 QFD projects (among them, seven software projects) took place (Herzwurm et al., 1998). The developers were asked about their experiences with QFD. The application of QFD goals were categorized on product and on project levels. The results showed success of QFD in fulfilling special expectation in product development. The findings of product level and project level goals are shown in Figure 4 .10 and Figure 4 .11, respectively. The relative quality of applying QFD is high. In project level goals, QFD improves the cooperation of the persons involved.

Further, QFD is helpful with focusing on the substantial, which leads to a higher economy of the product development.

Figure 4‎ .10. Satisfaction of the developers with product-related goals.

78

Figure 4‎ .11. Satisfaction of the developers with project-related goals.

CHAPTER 5

IDENTIFY SOFTWARE ENGINEERING ACTIVITIES THAT ARE QFD STEPS

AND FILLING THE GAPS

The main concept of QFD is to take the voice of the customer and deploy it throughout the development life cycle until the final product is made. The flexibility inherited in QFD allows practitioners from various disciplines to apply it in developing their products. The application of QFD on the field of software development has been successful. However, there is little research dissemination due to competitive factors.

Moreover, software engineers think that SQFD is not structured the way traditional software development methods are.

There are many documented benefits of QFD. The software engineer can use

QFD as a framework for activities required to improve the quality of software. Since

QFD was originally proposed to develop high quality manufactured products, a few considerations must take place before applying it to software development.

We will use the famous waterfall model (Figure 5 .1) as a reference for the main phases the software engineer uses to develop software. The QFD model we will use is the original four-phase model (Hauser & Clausing, 1988) shown in Figure 5 .2. We will define each phase in each model, point out what the QFD tools can be used to benefit the software engineer, and what features QFD is missing to follow software engineering 79

80

practices. Finally, an enhancement of the SQFD model developed by Liu (2000) is provided, followed by an example of a software HOQ.

Figure 5‎ .1. Waterfall model.

Figure 5‎ .2. Four-phase model.

81

There are three main benefits that software engineers can learn from QFD:

1. The QFD builds quality into the product by taking the customer as a starting

point and making it drives the whole development process. QFD focuses on

maximizing customer satisfaction.

2. The matrix form of QFD makes the activities more traceable, manageable, and

controlled.

3. QFD is a team-building process. It provides a rich environment for

communication among customers and engineers.

5.1 Phase 1

5.1.1 Product Planning in QFD

The qualitative customer requirements and expectation are translated to design- independent, measurable, characteristics of the product. First, customer requirements are categorized based on the affinity diagrams. The customers then state their priorities and do a competitive assessment on the company’s product and that of its competitors. After that, the QFD team establishes the technical requirements to respond to customer requirements and develops the relationship between customer requirements and technical requirements. The next step is to implement an evaluation of competitors’ technical

82

requirements. Using all the relationship information and the competitive evaluation, a target goal is created so the developer can use it to guide all following development activities.

5.1.2 Requirement Phase in Software Engineering

Software requirements express the needs and constrains that are placed on a software product that contributes to the satisfaction of some real-world application

(Abran et al., 2001). Requirement engineering is the process used to accomplish this phase. According to Pressman (2009), there are seven distinct tasks of requirement engineering: inception, elicitation, elaboration, negotiation, specification, validation, and management.

1. Inception. The software engineer develops a basic understanding of the

problem, the customers involved in the project, and the environment in which

the software will be implemented. In addition, the business community

identifies the breadth and depth of the market.

2. Elicitation. The actual gathering requirement from the user occurs during this

task. Though it looks like a simple task, it is usually the most difficult in

requirement engineering. A good software engineering practice is to maintain

good communication between customers and developers.

3. Elaboration. Requirement acquired during elicitation is refined. To

understand the requirements and how they interact, the software engineer

develops a requirement analysis model. Elements of the requirement model

83

include: scenario-based elements, class-based elements, behavioral-based

elements, and flow-oriented elements. Use cases are the most used method of

representing the requirements. User scenarios are created to describe the

relationship between the end user and the system. The model may reference

use analysis patterns to solve problems that reoccur within specific application

domain.

4. Negotiation. The software engineer resolve conflicts in customer requirement

through negotiation. Customers are asked to prioritize their requirements. The

developer will determine their scope and stability and also assess their costs

and risks. The developer can then balance between their need, the budget

available, and the schedule that must be met to establish a feasible project plan

before resources are committed to the project. Some requirements will be

eliminated, combined, or modified.

5. Specification. A specification of the requirement is developed. Depending on

the system’s nature and complexity, the specification can be a document,

graphical model, mathematical model, user scenario, or any combination of

these. Requirement documents must be organized to provide minimum effort

in locating and reading them, and, if needed, make changes to them.

6. Validation. Validating the requirements means examining the work products,

such as specification for quality to ensure that the right system will be

developed.

84

7. Management. The software engineer must ensure that any changes in the

requirement are detected and then adopted by the system. Requirements must

be tracked to allow requirements to be managed and controlled.

Young (2001) specified the criteria of a good requirement:

Table 5‎ .1.Criteria of a Good Requirement

Criterion Description

Necessary Can the system meet the need without it?

Verifiable Can one ensure that the requirement is met in the system?

Attainable Can the requirement be met in the system under development?

Unambiguous Can the requirement be interpreted in more than one way?

Complete Are all conditions under which the requirement applies stated?

Consistent Can the requirement be met without affecting other requirements?

Traceable Is the source of the requirement known, and can the requirement be referenced throughout the system?

Allocated Can the requirement be allocated to an element of the system design where it can be implemented?

Concise Is the requirement stated simply and clearly?

Implementation free The requirement should state what must be done without indicating how

Standard construct Requirements should be stated to indicate whether or not they are imperative

85

Unique identifier Each requirement should have a unique identifying number

Abran and colleagues (2001) mentioned that requirements should be stated quantitatively when appropriate. Techniques used to validate requirements include requirement reviews, prototyping, model validation, and acceptance tests.

5.1.3 How Can a Software Engineer Get Benefits from QFD?

Handling nonfunctional requirements. Both functional and nonfunctional requirements should be taken into consideration to develop high quality software.

However, because of the “soft” nature of nonfunctional requirements, they are often neglected by the software engineer, which can dramatically affect the quality of the software (Chung et al., 2000). QFD does not distinguish between functional and nonfunctional requirements and transform these requirements into measurable quantities. Additionally, nonfunctional requirements such as “easy to use” are met only to a certain degree. This is what QFD does. It specifies the degree of each requirement that can be fulfilled (Karlsson,1997).

The Kano Model. The Kano model classified the requirement base on the customer satisfaction degree into three categories: revealed requirements, expected requirements, and exciting requirements. Looking at another dimension of the requirements uncovers omission, conflicts, and ambiguity. Classifying requirements from the customers’ viewpoint allows the developer to be in the shoes of the customer, therefore better understanding the needs and developing a high quality product that

86

will maximize customer satisfaction. The Kano model takes the developer beyond what the customer asked for and allows the developer to add new exciting requirements that will create delighted customers. This can offer the company competitive advantage.

Affinity Diagrams. Software engineers use hierarchical diagrams to structure requirements. However, since customer requirements are usually subjective, affinity diagrams can serve as a better tool. Affinity diagrams can be helpful in tracing the customer who produced the requirement. The affinity diagram is a tool used to group huge amount of data based on their natural interrelationships. The can be used especially when they are too widely dispersed (Patil, 2010). Establishing the affinity diagram requires three steps:

1. Phrase the customer requirements in a brief, concise statement and write each

of these requirements on cards.

2. Group the requirements: Cards are sorted by placing them into groups.

3. Select or create a title card: A card or word is chosen that summarizes the data

within each group.

Customer Competitive Assessment. Customers are asked to rate the company’s product and those of its competitors based on each customer requirement.

The customer ratings can be used to determine how the company stands in the market compared to other companies, as well as the company’s strengths and weaknesses.

87

This, therefore, can aid the developer in discovering gaps that must be filled by the new product.

Technical Requirements. Because the customer speaks one language and the engineer speaks another, the columns of the QFD are technical requirements that are derived from customer requirements. Technical requirements act as measures for customer requirements. This offers more management and control on the requirements as having a measured requirement: developers can know to what degree they are satisfying a given requirement. This also helps with fuzzy and nonfunctional requirement. The more they are quantified, the better.

Relationship Matrix. The relationship matrix between the customer requirements and the technical requirements provide a direct connection between what the customer asked for and how the engineers are going to satisfy the customers’ needs. This ensures that there is no requirement left out. Every requirement must be met by at least one technical requirement. If there is any technical requirement that has no relationship with any of the customer requirements, it will be removed from the matrix. This is actually defines the degree of relationship between each customer’s requirement and the performance measures designed to improve the product.

Units of Technical Requirements. A unit is defined for each technical requirement to improve its clarity: Seconds, feet, and numbers of defects are some examples of units.

Direction of Improvement. Another tool that can help the software engineer

88

manage technical requirements is the direction of improvement. Each technical requirement is associated with a direction of improvement, showing if lesser is better or greater is better. For example, the less response time, the better. Therefore, the aim is decreased response time.

The Roof Matrix. Technical measures often conflict with each other. Working to improve one requirement may negatively affect a related requirement or vice versa.

Each technical requirement is compared to all other requirements to see how they interrelate and how strong the relationships between them. This helps identify requirements that conflicts as well as engineering tradeoffs.

Importance Rating of Technical Requirements. In software engineering, customer requirements are rated by customers to develop prioritized requirements.

QFD uses these ratings along with the relationship matrix values to create an importance rating of technical requirements. The resulting targets present the most important technical requirements to be implemented to maximize customer satisfaction. This assists the developer in the tradeoff decision-making process.

Technical Competitive Assessment. Technical competitive assessment involves reverse engineering the competitors’ products for each technical requirement to determine if the company is better or worse than its competitors in terms of technical requirements. Comparing a company’s products’ technical performance with those of its competitors can generate a better market share.

Target Goals. QFD uses the competitive assessment information along with

89

the importance rating to establish a target goal that the company can use as guidance on how much it needs to be competitive in the market. These targets can act as a baseline against which to compare development progress.

Developing a Constrain. The resulting targets should be reasonable based on the resources of the company. The flexibility of QFD allows development of an imprecise goal programming (GP) approach (Cherif et al., 2010) to define the optimum target levels of ECs in QFD for under-resource limitations and considerations of market competition.

5.1.4 What is QFD Missing?

Establishing the Ground. The purpose of the first task in the requirement engineering–inception phase is to establish the ground for the project. By answering questions about the project scope, purpose, and need, the project is initiated. QFD does not define such a method for project identification.

Choosing the QFD Team. QFD requires that all activities to be done with a cross-functional team. However, QFD does not specify any method for choosing the team.

Units of Technical Requirements. Each technical requirement in the QFD is defined by its unit; however, not all software matrices have units.

Handling Requirements that Have No Relevant Measurement. Not all requirements can be measured to a degree of satisfaction. Some requirements are either met or not met, such as “printing an invoice.”

90

The Relationship Matrix. The transformation from customer requirements to tech requirements is a big step. Customer requirements can be vague and ambiguous.

It is not easy to transform them directly to a quantitative measurable technical requirement. Software engineers develop requirement modeling to better understand the requirements and how they interact. Requirements should be fully understood first:

What are the functions used by different classes of end users? QFD needs to integrate requirement modeling, especially use cases, into its matrix. Moreover, QFD does not provide any method to document the requirements.

Validation of the Requirements. QFD uses the customer requirements as a driver for the development activities. However, it assumes that these requirements are complete and accurate, which is not the case—especially in software development. In addition, poor requirement is a major reason for software requirements.

91

5.1.5 Suggestions to Improve QFD for Software Engineering

Using Opinion Mining Technique. Opinion mining is an emerging technique to collect requirements. Sentiment analysis (or opinion mining) is the use of natural language processing, text analysis, and computational linguistics to extract and mine text for customers’ opinions, complaints, and desires. This can be applied to Web documents such as blogs, product reviews, forums, or tweets. In addition to the use of opinion mining as a source of the voice of the customer (VOC), it can be used as to evaluate customer requirements in the competitive assessment part in the HOQ.

Considering the Engineers’ Perspective. In addition to gathering the requirements from customers, engineers can add their own requirements. The engineers would take the project definition and brainstorm requirements necessary to achieve the project objectives. The engineers can develop some requirements that the customer did not consider or those the engineers think are important to reach system goals. Moreover, the engineers can create some requirements that amaze the customer—the “exciting requirements” according to the Kano model. Then they can discuss these requirements with the customers.

This is where QFD has its strength, by reducing the gap between software engineers and the customers as more communication takes place between them.

Additionally, customers get to know what potential features can be added to improve the product (exciting requirements). Another source of exciting requirements or new

92

capabilities is observing the customers in working environments, looking for opportunities for improvement (Crow, 1994).

Rank2 Requirements and the Concept of Reuse, According to the Kano model, there are expected requirements that can be functions the customer expected or assumed to be implemented in the software, but the customer did not reveal them

(unspoken needs). These requirements can be extracts from domain analysis or past experience. “Domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain” (Pressman, 2009). Using domain analysis to solve common problems decreases time to market and development costs.

These requirements can be removed from the main QFD when large numbers of requirements are present, as it would complicate it. Therefore, the developer can focus on analyzing requirements for which the customer asked and concentrate on new ideas and more delighters or “exciting” features.

The software engineers can then develop Rank2 QFD that has these expected requirements. Rank2 QFD matrices can be used for future references, as these functions would be required by new releases of the product. The developer must keep updating the database to reflect changes in expected requirements. New requirements evolve every day, as software is a rapid development area. “Exciting requirements” or delighters become “expected requirements” after some time.

93

With huge numbers of requirements, the HOQ matrix can grow to be unmanageably large. Some practitioners recommend that the size of matrix be

3030. However, Karlsson (1997) mentioned that the recommended size of HOQ as a

3030 matrix can be problematic, as the QFD team tends to put more abstract requirements to fit the recommended size. A large number of requirements can be divided into subsystems, each containing 30 requirements, to limit such problems. Subsystems with larger number of high priority requirements can be chosen to be implemented before subsystems with low priority requirements.

Stability of a Requirement. Stability of a requirement refers to the likelihood of requirements to change. Some requirements are likely to change later in the development life cycle. We suggest inserting tags that would be associated with each requirement to indicate its stability status. A tag can have one of three values: “S” for stable requirement, “M” for moderate stable requirement, or “V” for volatile requirement. The system would alert the developer if there are any changes to the stability of a requirement occurred. A significant number of requirements will change during the development of software, either because of some analysis error or as a consequence of change in the environment (Abran et al., 2001). Therefore, the tags should be checked after each phase to adopt change in requirements. Flagging volatile requirements can help establish a design that is more tolerant of change.

Requirement Scope. A requirement’s scope is the range that this requirement affects the system. Some requirements (usually nonfunctional requirements), such as

94

performance, have a global scope in the sense that they have a great impact on multiple parts of the system. Narrow scope requirements affect smaller numbers of the system components. QFD can facilitate identifying the scope of a requirement through the relationship matrix. If the customer requirement has an influence on the technical requirement, the cell corresponding to where the column and row meet will have a number depending on the strength of that relation. A requirement that has relations with many technical requirements indicates that this customer requirement has a wider scope. In contrast, a requirement with fewer relations indicates a limited scope requirement. However, the software engineer must be cautious when defining the requirement: The requirements must be detailed as much as possible since a general

(more abstract) requirement tends to have relations with multiple technical requirements. The developer must also ensure that all requirements have the same level of abstraction (Karlsson, 1997).

Traceability of a Requirement. It is crucial for the software to have requirements that can be traceable. Tracing allows requirements to be controlled and managed. Tracing can be done either forwards or backwards. The requirements must be at least traceable back to its source that motivated it. Affinity diagrams can be helpful in tracing customers who produced the requirement. Backward traceability is most important when, for example, the developer wants to add or change a feature in the program. By looking at the code, the developer can make sure that changing any part does not conflict with a previous requirement. Forward traceability helps verify

95

that requirements are addressed and satisfied in design, implementation, and testing

(Abran et al., 2001). If traceability is effective, any change in the requirements can be easily monitored through the development life cycle. Additionally, it helps the developer perform an analysis for a proposed change to one of the requirements. QFD, with its sequence of matrices, offer a systematic way to trace requirements faster and more efficiently.

Validating the Requirements. According to Jones (2012), the highest delivered defects are due to requirements. The earlier that requirement errors are detected, the fewer defects that will be found in later phases of the product life cycle and the lower the costs in fixing them (Xiong & Wang, 2008). It is better to spend more time on requirements process at the beginning of the project to discover problems before committing resources to address these requirements. Spending little time at the beginning saves rework and recoding as it would reduce complaints and maintenance costs. Poor quality is cheaper until the end of the coding phase. After that, high quality is cheaper (Jones, 2012). Therefore, the requirement must be validated to ensure that the software engineer understood the requirement and that the requirement defines the right systems that improve customer satisfaction. It does not matter if the developer employs the best technology if it is not what the user needs. All the effort of design, code, and testing will become useless. It is assumed that the requirements given by the customer are accurate and complete.

96

We need to avoid what Pressman (2009) called “your worst nightmare. . . . A customer walks into your office, sits down, looks you straight in the eyes and says, ‘I know you think you understand what I said, but what you don’t understand is that what I said is not what I mean’”. Discovering defects in requirements early will prevent errors in requirements from propagating from one phase to the next. There are many techniques can be used to validate requirements.

Use of a prototype of the proposed system will validate a requirement. The engineer would develop a sample (prototype) of what the software will look like so the customers will see how their need would be implemented and whether that is what they expected. Moreover, a prototype helps customer understand some of the complex engineering requirements that are hard to explain abstractly. Further, engineers can test the exciting requirements to see the customers’ level of satisfaction of these new capabilities. Similarly, the engineers can discover new opportunities that can be added to the system after the customer has some “feeling” for the product. According to Young

(2001), many changes in the requirements do not occur until customers begin to see screens and outputs of the applications. A prototype has a greater importance in software than in hardware. This is due to the intangible nature of software, which makes it harder for the customer to express their needs. Moreover, a prototype helps clear the boundaries of a fuzzy requirement.

97

5.2 Phase 2

5.2.1 Parts Deployment in QFD

The second matrix in QFD is called “parts deployment.” The technical requirements are translated into critical subsystem, assembly, or part characteristics. The tasks are similar to the tasks involved in the previous matrix. The relationship between technical requirements and critical subsystem, assembly, or part characteristics are identified. Importance ratings and target levels are calculated.

5.2.2 Design Phase in Software Engineering

The software design process lies between software requirement analysis and software coding. The requirement models produced from the previous phase feed the design activity. The work product is a design model that consists of four designs: software architecture, data structure, interfaces, and components design. Design develops a representation for the system can be evaluated for quality.

1. Data/class design. Transform class models produced in the requirement phase

into design classes and the high level of abstraction data structure to

implement the software.

2. Software architectural design. Called high-level design, where top-level

structure of the system and the relation between them is developed to achieve

requirements defined for the system. It represents an overview of the system.

98

3. Interface design. The interface design consists of three elements: user

interface, external interface to other systems, and internal interfaces between

different components of the systems. Because it involves data and behavioral

description of the system, usage scenarios and behavioral models can be used

as input.

4. Component design. Each software architectural element is transformed into

detailed software components design. Class-based models, flow models, and

behavioral models are used to drive descriptions of component design.

5.2.3 How Can a Software Engineer Benefit from QFD?

The two first phases of QFD are similar to each other. Many of the tools useful to a software engineer are defined in Section 5.1.3.

5.2.4 What is QFD Missing?

Since the part deployment matrix is quite similar to the product planning matrix in the traditional QFD, the top aspect that QFD is missing is modeling. As with the requirement phase, the second phase of QFD does not provide any type of modeling for the design phase. Because there are no modeling activities in QFD, the design phase in software—if it is implemented in QFD—is missing its main input: the requirement model.

As with requirements, there are no clear methods to include design models in

QFD.

99

5.2.5 Suggestions to Improve QFD for Software Engineering

Cohesion and Coupling. If the second matrix in a software QFD can consist of requirement models as rows and columns of design models, the matrix form in QFD assists in defining cohesion for the design module. If a design model has many relations with different requirement models, it indicates that it is not focused on specific functions, which mean it has low coupling. Thus, engineers must rethink their design.

Design Models. Using the resulting models, the developer can proceed in decomposing the system into subsequent decomposition as a refinement of prior decomposition. A refined phase is then implemented to reflect the software detailed design. Here, the software engineer should look for low coupling.

5.3 Phase 3

5.3.1 Process Design Phase in QFD

Prioritized manufacturing processes, key process control and improvement parameters are developed. The manufacturing processes are then flowcharted; key process control and improvement parameters (or target values) are set.

5.3.2 Implementation Phase in Software Engineering

The third phase in software development cycle is the construction phase. After the design of the system has been chosen, a construction language must be selected to implement the design. Construction languages refer to all forms of communication

100

through which a human can specify an executable problem solution to a computer (Abran et al., 2001). The team can choose between configuration languages, toolkit languages, or programming languages—depending on the nature and complexity of the project. Each component of the system must be implemented with an executable piece of code. The work product of this phase is the source code and code documentation.

5.3.3 How Can a Software Engineer Benefit from QFD?

Again, the strength of QFD lies in the strong connection of the sequence of matrices that facilitate tracing. If the developer needs to change the code, that piece of code can be traced back to avoid modifying the code in a way that dissatisfies the customers by ignoring a main requirement: direction of improvement. After developing components of the software, these components must be put together to form the desired system. However, many problems occur during integration, and the system may not behave as planned. The direction of improvement and the Roof matrix can shed some light on what is expected to happen during integration.

5.3.4 What is QFD Missing?

Time in software replaces cost in hardware. The software must be implemented within limited available time. The most important requirements are delivered on the first release of the software. Others can be added later. The software must be released within the tight schedule; otherwise, the company might lose market share, the customer requirements changes, or technology evolves. It is acceptable to have some missing

101

requirements in the first releases of the software. In addition to building the source code to satisfy the requirement, software engineers must handle error conditions such as input validation.

5.4 Phase 4

5.4.1 Process/Quality Control in QFD

To ensure that the quality of processes is met, schedules are maintained, and performance indicators and production instructions are created. Moreover, control and reaction plans are made to prevent failures.

5.4.2 Testing Phase in Software Engineering

Different testing strategies are applicable for different software engineering approaches and at different points in time. Unit testing concentrates on each unit (e.g., component, class), integration testing focuses on design, and validation testing is used to validate the requirements. The whole system, comprised of the software and other systems, is tested using system testing. Various testing techniques are available, such as: random testing, object oriented testing, error guessing, protocol conformance testing, mutation testing, and so on. The work product: a test specification document that can be reviewed by software engineers for quality.

As we can see, the fourth phase in QFD is different than in software engineering practices. There are some differences between hardware verification and software testing.

According to Ur and Ziv (2002), hardware verification results in a higher quality product

102

than does software testing. This is due to the stable testing environment (human and tools) of hardware. Moreover, it is unacceptable for the customers to find bugs in the hardware after it is delivered (however, software is often released with a substantial number of bugs). Further, software testers tend to have fewer qualifications than the skills levels of people who verify hardware.

5.5 Phase 5

The QFD process has only four phases. The software life cycle has an additional phase—maintenance.

5.5.1 Maintenance Phase in Software Engineering

The IEEE standard defines software maintenance as: the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.

If there is an error discovered after the product is released, software is modified where hardware is replaced. In fact, change is inevitable in the software product.

Maintenance has to take place to fix some bugs, adopt the software to the evolving environment, enhance some features to meet changing needs of the customers, and add response to some requirements that were not satisfied due to limited resources. Since the software must change, the developers must build flexible software components.

Techniques such as information hiding make changing these components a lot easier.

103

5.6 An Enhanced Software QFD

Liu (2000) modified the four-phase model of QFD for the software development process. We purpose a further enhancement to his model: The purposed model shown in

Figure 5 .3 retains the four-phase model with the four matrices being the main matrices.

The sub-matrices are detailed matrices of activities usually done by software developers.

The main focus of this method is guaranteeing that the “right” requirements are chosen to be deployed in the whole development life cycle. Three important features of the requirements are managed: traceability, scope, and sustainability.

104

Figure 5‎ .3. Enhanced software QFD.

The first phase is project identification. The software engineer must develop a clear statement of the project to be developed and the problem at hand. What are the objectives? Goals? Benefits? Scope? Why should this project be implemented? What are the business needs? What is the environment in which the project will be implemented?

Is it outsourced?.The software engineers must answer such questions to develop a good understanding of the project. Once the engineers have identified the project, they can identify its customer and form a cross-functional team to represent different functions in the organization. Customers can range from recipients of service to retailers and stakeholders. The cross-functional team is involved in all phases of product development.

Each stakeholder has a different perspective of the system and its requirements. Having

105

the customers and the stakeholders participate in these discussions ensures that all members have same “image” of the software being developed. This will, therefore, have a great impact in minimizing the requirement conflict that the software engineer faces when collecting requirements from various types of users. Moreover, having the team communicate at an early stage of the project can increase collaboration among team members as well as understand the project’s complexity. It also allows for the software engineer to better understand the customers. It is better for the team to struggle with these issues at an early phase of the project development.

Once the team has a common about view of the product, the software engineers start collecting requirements. Many software products fail due to lack of correct requirements. No software process can keep delivery times, costs, and product quality under control if requirements are poorly defined and managed (Niazi & Shastry, 2003).

Boehm (1984) estimated that the cost of fixing the requirements errors late (e.g., during maintenance) can cost up to 200 times as much as correcting the errors during the requirements phase. Understanding the customer is vital to providing high quality software without cost overruns. However, current requirement analysis and specification methodologies struggle to identify how software designers should do impacts on what customers want. Moreover, conflicts among the customer requirements are not clearly detected in these methods (Liu, 2000). QFD can address some of these problems associated with failures in software development. The strength of QFD lies in user

106

involvement to produce complete, unambiguous, and non-redundant requirements. It is also useful in detecting requirements conflicts.

There are different methods for gathering the requirements, such as individual interviews, focus groups, mail/phone surveys, listening and observing, warranty data, and sales records. In addition, engineers can add their own requirements or add exciting requirements. An affinity diagram can be used to structure the requirements. After that, these requirements are ranked from the customers’ prospective. If there are large numbers of requirements, they can be divided to form subsystems to avoid having complex QFD matrices. A tag is attached to each requirement, stating its stability.

The next step is to validate the requirements. We suggest the use of a prototype of the proposed system to validate the requirement. The engineers would develop a sample

(prototype) of what the software will look like so the customers will see how their need is going to be implemented and whether it is what they expected. Moreover, a prototype will help customers understand some of the complex engineering requirements that were hard to explain abstractly. Further, engineers can test the exciting requirements to see customers’ level of satisfaction of these new capabilities. Similarly, engineers can discover new opportunity that can be added to the system after the customer has some

“feeling” for the product. According to Young (2001), many changes in the requirements do not occur until customer begins to see screens and outputs of the applications. A prototype has a greater importance in software than in hardware. This is due to the

107

intangible nature of software, making it harder for customers to express their needs.

Moreover, the prototype helps clear the boundaries of a fuzzy requirement.

Once the team has a complete set of requirements along with their priorities and tags, they can start filling the HOQ matrix. Competitive companies are identified, and the customers evaluate the product in terms of each requirement. After that, the engineers drive high level technical requirements—or what is called “system requirements”—from customer requirements. For each technical requirement, the engineer indicates the direction of improvement, defines the units (if applicable), compares them to other requirements one by one, and fills the Roof matrix.

At that point, the team fills the cells in the HOQ matrix, indicating the relationship between customer requirements and technical requirements. The engineers make a competitive assessment of the technical requirements, similar to what they did with the customer requirements. The result of customer and technical assessment should be consistent. If Company A, for example, is evaluated by the customer as the fastest company, it cannot be rated by engineers as having a slow response time compared to other companies. Finally, the technical targets are set to provide a baseline against which the developers can compare.

A subsequent of a refined matrix can be developed to drive more detailed requirements. HOQ consists of customer requirement  system requirement (high level requirement) matrix. The refined matrix is composed of system requirement as the rows  software requirement (low level requirement) as columns. The work product is the

108

requirements’ definition document for the high level requirement and software requirements’ specification documents that record the low level requirement. There is no clear-cut boundary, but it is unusual for requirement analyses to go beyond two or three levels of breakdown before moving to the design phase (Abran et al., 2001). For each requirement, the unified modeling language (UML) can be used to model the requirement.

Phase 2 is the design phase. Here, each system requirement is allocated to one or more software architecture component design (module). Any unnecessary components will be removed. The software design process lies between software requirement analysis and software coding. It is a two-step process: software architectural design called (high- level design) where top-level structure of the system is developed, and software detailed design where each component is built to be ready for the next phase of implementation

(Abran et al., 2001).

The design phase produces various models that form a kind of blueprint of the solution to be implemented. The relation between these modules and requirements are analyzed to consider different tradeoffs options. A good module has high cohesion and low coupling. The matrix form assists in defining cohesion and coupling for the design module.

Using the resulting models, the team can proceed by decomposing the system into subsequent decomposition as a refinement of prior decomposition. The refined phase is then implemented to reflect the software detailed design. Here, the software engineer

109

should strive for high cohesion. The project size and complexity determine the need for extra-refined matrices.

The output of this phase is a set of modules that demonstrates major design decisions. It is used as an input coding phase. Design specifications are also documented.

Software components that are most important to meet customers’ needs are deployed into the next matrix.

The third phase is the construction phase. After the design of the system has been chosen, a construction language must be selected to implement the design. Construction languages refer to all forms of communication through which a human can specify an executable problem solution to a computer (Abran et al., 2001). The team can choose from among configuration languages, toolkit languages, or programming languages— depending on the nature and complexity of the project. Each component of the system must be implemented with an executable piece of code. The work products of this phase is the source code and code documentation. Because only the most important aspects of each phase are deployed into the next matrix of QFD, the code produced in this phase presents the most important features for which the customers asked in the first place.

The final phase is the testing phase. Each block of code that was constructed to fulfill a requirement is tested. There are multiple factors that control the testing techniques to be used. Example of factors include the tester’s intuition, the code structure, the nature of the project, and so on.

110

5.7 A Numerical Example of HOQ

Suppose a company wants to develop software for a global positioning system

(GPS). The first step is to identify the project’s goals, scope, benefits, and its potential customers. After that, the customer requirements are collected using various methods.

Example of customer needs include “easy to use,” “fast,” and “accurate.” Engineers can add some requirements—such as “live traffic data”—that excite the customers and increase satisfaction. These requirements are categorized using an affinity diagram; for instance, the requirements “fast” and “accurate” can be classified within the same group.

After that, the customers express the importance of each requirement.

The next step is to validate the requirements using a prototype. If there is any change in the requirements, which is likely to happen, then the new or modified requirements are categorized and rated. The team can then continue to fill out the HOQ matrix with its different parts (illustrated in Figure 5 .4). At that point, competitors in the market are identified. A competitive assessment is done to see how customers perceive the company’s product against those of other competitors in the market. Rating used in this example are “1” for the worst and “5” for the best

The engineers would drive the technical requirements from the customer requirements, define their direction of improvement, and indicate their correlation to each other. For example, “response time” is a technical requirement derived to address the customer requirement “fast.” The less response time, the better. Therefore, we have the direction of improvement as a down arrow. There is a negative relationship between

111

“response time” and “memory size” and a strong positive relationship between “response time” and “receiver sensitivity,” which is recorded at the Roof of HOQ. Next, the team will fill the relationship matrix, indicating the degree of relation between customer and technical requirements. The company’s product and those of its competitors are evaluated in terms of technical requirements during the technical assessment. Finally, technical targets are calculated. Here, we are using the benchmarking method.

112

Figure 5‎ .4. GPS example.

The 1891.89 value, for example, is assigned as a target for the “response time” requirement as follows: First, all customer requirements that have a relationship with this

“response time” are identified; there are four of them: “fast,” “easy to use,” “up-to-date maps,” and “live traffic data.” For each of these customer requirements, we would find the best performing company. For “fast,” we have Company A as having the best

113

performance, with 3.5 out of 5. Then we calculate the ratio of improvement by dividing the maximum value by the best company’s value: 5/3.5 = 1.43. Company A has a value of 3000 milliseconds. So, to achieve the best product, the target value for the future product should be 3000/1.43 = 2.097. If it is the case with additional technical requirements, we will multiply by the ratio of improvement. As can be seen from the

Figure, a value of 1891.89 is assigned as the target value. This is because we have made the benchmarking calculation for all other customer requirements that have relations with

“response time” and chose the minimum value, since a minimum value is better. After filling the HOQ, a requirement document is produced, recording all requirement definitions. The QFD process continues with the team checking on the requirements after each phase to control the change in the requirements and develop a high quality product.

114

CHAPTER 6

CONCLUSION AND FUTURE WORK

There were four objectives specified at the beginning of this thesis: Chapters 2 addressed the first objective by presenting the concepts, definitions, and application areas of QFD. Chapter 3 contributed to the second objective, creating an understanding of the

QFD process. All parts and phases of QFD were discussed in detail. An example was provided to help the reader comprehend the QFD method. The following objective, presenting a review of documented attempts to apply QFD to software development, was accomplished in Chapter 4. In addition, a brief summary of the past successful application of QFD was included in that chapter. Finally, Chapter 5 contributed by matching QFD steps to the software development life cycle to uncover any software engineering activities not included in the QFD process. Similarly, this matching revealed the QFD tools that can be used to improve the quality of the software product.

The aim of this thesis has been to develop an understanding of the QFD, document various attempts and experiences of applying QFD in software development.

QFD is a systematic approach for capturing customer requirements and deploying them throughout different phases of product development until the final product is produced.

114

115

QFD was originally proposed to manufacture high quality hardware and products.

The flexibility of QFD allows it be applied in different industries. However, there are some differences between the development of software and the development a hardware.

To use QFD to develop software products, some considerations must be made to ensure that software engineering principles are applied.

Many studies have shown that poor requirements are the main factor in failure of software projects. In fact, requirements elicitation is considered the most difficult activity in the development process. Traditional methods of software development lack the direct connection between the customer voice and the engineering voice, not clearly identifying how software development tasks implement what customers want. Further, existing methodologies fail to identify and resolve conflicts among customer requirements.

Additionally, many nonfunctional requirements are neglected due to the difficulty of capturing them during normal software engineering activities. QFD aids the software engineers in improving the requirements elicitation process, thereby improving the software quality. Furthermore, QFD addresses the nonfunctional requirements by allowing the software engineer to specify the degree to which a requirement can be satisfied. Using the Kano model, QFD can go beyond customer satisfaction and add the exciting requirements that delight the customer and provide a bigger market share for the company.

116

There are number of tools QFD offers to deploy the quality throughout the development life cycle of the product. Customer and technical assessment provide a great benchmarking tool that aids engineers in discovering competitive advantages for the company. The direct of improvement of each technical requirement and the Roof matrix assist the engineer in detecting conflicts between technical requirements as well as identifying different tradeoffs. The use of a QFD team to fill out the matrices establishes a great communication environment to close the gap between customers and engineers.

Comparing the QFD steps with software engineering activities reveals some gaps that the QFD needs to fill to apply software engineering good practices. For example,

QFD relies mainly on customer requirements and uses them to drive all the preceding steps. However, it does not provide a way to validate these requirements. Also, because of the “soft” nature of software requirements, it is hard to produce technical requirements directly from customer requirements. As opposed to software engineering procedures,

QFD does not consider in its matrices the role of modeling the requirements nor modeling the design.

As an enhancement of the software QFD model, some suggestions were made to apply some software engineering principles. For example, the requirements are collected, prioritized, and then validated before they can be used in the HOQ matrix. Some requirements characteristics—such as scope, tractability, and sustainability—can be managed through the use of QFD. In the case of a huge number of requirements,

117

decomposing these requirements can make the QFD process more controllable.

Moreover, the engineers can add some requirements from their point of view.

Future research includes providing an iterative way to modify and update the requirements. Software is a changing environment, constantly evolving. QFD must provide a way to adapt that change. In addition, with the second QFD matrix, one can calculate coupling and cohesion using the relationship among different components: how are they related and the strength of these relations. Omitting the requirement modeling is a big gap in QFD. Including the modeling activity in SQFD will greatly improve the process of applying software engineering principles.

REFERENCES

Abran, A., Moore, J., Bourque, P., Dupuis, R., & Tripp, L. (2001). Guide to the software

engineering body of Knowledge–SWEBOK, trial version IEEE-Computer Society

Press.

Adiano, C., & Roth, A. V. (1994). Beyond the house of quality: Dynamic QFD.

Benchmarking for Quality Management & Technology, 1(1), 25-37.

Akao, Y. (1990). Quality function deployment: Integrating customer requirements into

product design.

Akao, Y. (1972). New product development and quality assurance–quality deployment

system. Standardization and Quality Control, 25(4), 7-14.

Akao, Y., & Mazur, G. H. (2003). The leading edge in QFD: Past, present and future.

International Journal of Quality & Reliability Management, 20(1), 20-35.

Andronikidis, A., Georgiou, C. A., Gotzamani, K. & Kamvysi, K.Integrating quantitative techniques with quality function deployment - quality_function.pdf Retrieved 6/24/2013,

2013,from

118

119

http://www.emeraldinsight.com/learning/management_thinking/articles/pdf/quality_funct ion.pdf

Barnett, W. D., & Raja, M. (1995). Application of QFD to the software development

process. International Journal of Quality & Reliability Management, 12(6), 24-42.

Bernal, M. L., Dornberger, U., Suvelza, M. A., & Byrnes, M. T. (2009). Quality function

deployment (qfd) for services.

Bijay K. Jayaswal, & Patton, P. C. (2006). Design for trustworthy software tools,

techniques, and methodology of developing robust software . Upper Saddle River,

N.J.: Prentice Hall.

Boehm, B. W. (1984). Software engineering economics. Software Engineering, IEEE

Transactions on, (1), 4-21.

Bouchereau, V., & Rowlands, H. (2000). Methods and techniques to help quality function

deployment (QFD). Benchmarking: An International Journal, 7(1), 8-20.

Carnevalli, J. A., & Miguel, P. C. (2008). Review, analysis and classification of the

literature on QFD—Types of research, difficulties and benefits. International

Journal of Production Economics, 114(2), 737-754.

120

Chan, L., & Wu, M. (2002). Quality function deployment: A comprehensive review of its

concepts and methods. Quality Engineering, 15(1), 23-35.

Chan, L., & Wu, M. (2002). Quality function deployment: A literature review. European

Journal of Operational Research, 143(3), 463-497.

Cherif, M. S., Chabchoub, H., & Aouni, B. (2010). Integrating customer's preferences in

the QFD planning process using a combined benchmarking and imprecise goal

programming model. International Transactions in Operational Research, 17(1), 85-

102.

Chin, K., Wang, Y., Yang, J., & Gary Poon, K. K. (2009). An evidential reasoning based

approach for quality function deployment under uncertainty. Expert Systems with

Applications, 36(3), 5684-5694.

Chung, L., Nixon, B., Yu, E., & Mylopoulos, J. (2000). Non-functional requirements.

Software Engineering,

Cohen, L., & Cohen, L. (1995). Quality function deployment: How to make QFD work

for you Addison-Wesley Reading, MA.

Creative Industries Research Institute. Microsoft word - quality function deployment.doc

- quality function deployment.pdf Retrieved 6/24/2013, 2013, from http://www.ciri.org.nz/downloads/Quality Function Deployment.pdf

121

Crow A.Kenneth. Microsoft word - quality function deployment.doc - quality_function_deployment.pdf Retrieved 6/24/2013, 2013, from http://www.ieee.li/tmc/quality_function_deployment.pdf row, K. (1994). Customer-focused development with QFD. Annual Quality Congress

Proceedings-American Society for Quality Control, 839-839.

Eureka, W. E., & Ryan, N. E. (1994). The customer-driven company: Managerial

perspective on quality function deployment ASI Press Dearborn, MI.

Fung, R. Y., Chen, Y., & Tang, J. (2006). Estimating the functional relationships for

quality function deployment under uncertainties. Fuzzy Sets and Systems, 157(1), 98-

120.

Govers, C. P. (1996). What and how about quality function deployment (QFD).

International Journal of Production Economics, 46, 575-585.

Griffin, A., & Hauser, J. R. (1993). The voice of the customer. Marketing Science, 12(1),

1-27.

Haag, S. E. (1992). A field study of the use of quality function deployment (QFD) as

applied to software development.

122

Haag, S., Raja, M., & Schkade, L. L. (1996). Quality function deployment usage in

software development. Communications of the ACM, 39(1), 41-49.

Harty, D. (2001). Quality function deployment-an overview of QFD and its applications

to software engineering. Lockheed Martin Information Systems,

Hauser, J. R., & Clausing, D. (1988). The house of quality.

Herzwurm, G., Ahlemeier, G., Schockert, S., & Mellis, W. (1998). Success factors of

QFD projects. Proceedings of the World Innovation and Strategy Conference, 27-41.

Herzwurm, G., & Schockert, S. (2003). The leading edge in QFD for software and

electronic business. International Journal of Quality & Reliability Management,

20(1), 36-55.

Herzwurm, G., Schockert, S., & Mellis, W. (1996). Determining the success of a QFD

project. Proceedings of the 8th QFD-Symposium, Novi, 131-150.

Herzwurm, G., Schockert, S., & Mellis, W. (1999). Higher customer satisfaction with

prioritizing and focused software quality function deployment. Proceedings of the

Sixth European Conference on Software Quality,

Herzwurm, G., Schockert, S., & Mellis, W. (2000). Joint requirements engineering

Vieweg.

123

Herzwurm, G., Schockert, S., & Pietsch, W. (2003). QFD for customer-focused

requirements engineering. Requirements Engineering Conference, 2003.

Proceedings. 11th IEEE International, 330-338.

Hill, A. (1992). New product introduction through QFD in a total quality environment.

First European Conference on Quality Function Deployment, Milano, impacture. White paper entitled: What is QFD? Retrieved 6/24/2013, 2013, from

http://www.impacture.com/qfdwhatis.htm

Jaiswal, E. S. (2012). A case study on quality function deployment (QFD). The Journal

of Mechanical and Civil Engineering, 3(2278-1684), 27-35.

Jnanesh, N., & Hebbar, C. K. (2008). Use of quality function deployment analysis in

curriculum development of engineering education and models for curriculum design

and delivery. Proceedings of the World Congress on Engineering and Computer

Science, 22-24.

Jones, C. (2012). Software quality in 2012: A survey of the state of the art. ().Software

Quality Group of New England.

Karlsson, J. (1997). Managing software requirements using quality function deployment.

Software Quality Journal, 6(4), 311-326.

124

Karsak, E. E., & Özogul, C. O. (2009). An integrated decision making approach for ERP

system selection. Expert Systems with Applications, 36(1), 660-667.

Kihara, T. (1992). Decomposing Software Requirements by using QFD and QMIII,

Kogure, M., & Akao, Y. (1983). Quality function deployment and CWQC in japan.

Quality Progress, 16(10), 25-29.

Koski, J. (2003). Quality Function Deployment in Requirements Engineering: A Review

and Case Studies,

Lillrank, P. M. (1990). Laatumaa: Johdatus japanin talouselämään laatujohtamisen

näkökulmasta Gaudeamus.

Liu, X. F. (2000). Software quality function deployment. Potentials, IEEE, 19(5), 14-16.

Lockamy, A., & Khurana, A. (1995). Quality function deployment: Total quality

management for new product design. International Journal of Quality & Reliability

Management, 12(6), 73-84.

Mazur, G .Http://www.mazur.net/works/qfd_definition.htm - qfd_definition.pdf

Retrieved 5/1/2013, 2013, from http://www.mazur.net/works/qfd_definition.pdf

Mazur, G.What is QFD? Retrieved 6/24/2013, 2013, from

http://www.qfdi.org/what_is_qfd/history_of_qfd.htm

125

Mazur, G.What is QFD? Retrieved 6/24/2013, 2013, from

http://www.qfdi.org/what_is_qfd/what_is_qfd.htm

Mehrjerdi, Y. Z. (2010). Quality function deployment and its extensions. International

Journal of Quality & Reliability Management, 27(6), 616-640.

Myint, S. (2003). A framework of an intelligent quality function deployment (IQFD) for

discrete assembly environment. Computers & Industrial Engineering, 45(2), 269-

283.

Niazi, M., & Shastry, S. (2003). Role of requirements engineering in software

development process: An empirical study. Multi Topic Conference, 2003. INMIC

2003. 7th International, 402-407.

Nishimura, H. (1972). Ship design and quality table. Quality Control, 23, 16-20.

Ohmori, A. (1993). Software quality deployment approach: Framework design,

methodology and example. Software Quality Journal, 3(4), 209-240.

Özgener, z. (2003). Quality function deployment: A teamwork approach. Total Quality

Management and Business Excellence, 14(9), 969-979.

Partovi, F. Y. (1999). A quality function deployment approach to strategic capital

budgeting. The Engineering Economist, 44(3), 239-260.

126

Partovi, F. Y. (2001). An analytic model to quantify strategic service vision.

International Journal of Service Industry Management, 12(5), 476-499.

Partovi, F. Y. (2007). An analytical model of process choice in the chemical industry.

International Journal of Production Economics, 105(1), 213-227.

Patil, M. M. J. (2010). Quality function deployment (QFD) for product design.

Pressman, R. (2009). Software engineering: A practitioner's approach (7 th ed.)

McGraw-Hill Higher Education.

Puett III, J. F. (2003). Holistic Framework for Establishing Interoperability of

Heterogeneous Software Development Tools,

Sawyer, P., & Kotonya, G. (2001). Software requirements. Swebok, , 9.

Shahin, A. (2005). Quality function deployment: A comprehensive review. Department

of Management, University of Isfahan, Iran,

Shindo, H. (1999). Application of QFD to software and QFD software tools. Pre-

Conference Workshops of the Fifth International Symposium on Quality Function

Deployment and the First Brazilian Conference on Management of Product

Development", Belo Horizonte, Brazil,

127

Squires, T.Description of the QFD process Retrieved 6/24/2013, 2013, from

http://www.masetllc.com/products/418.shtml

Tapke, J., Muller, A., Johnson, G., & Sleck, J. (2009). House of quality: Steps in

understanding the house of quality.

Ur, S., & Ziv, A. (2002). Cross-fertilization between hardware verification and software

testing. 6th IASTED International Conference on Software Engineering and

Applications (SEA2002),

Xie, M., Goh, T., & Xie, W. (1995). Prioritizing processes for better implementation of

statistical process control techniques. Engineering Management Conference,

1995.'Global Engineering Management: Emerging Trends in the Asia Pacific'.,

Proceedings of 1995 IEEE Annual International, 260-263.

Xiong, W., & Wang, X. (2008). Software requirements management using QFD: A

process perspective. Computational Intelligence and Design, 2008. ISCID'08.

International Symposium on, , 2 295-299.

Xiong, W., Wang, X., & Wu, Z. (2008). Study of a customer satisfaction-oriented model

for outsourcing software quality management using quality function deployment

(qfd). Wireless Communications, Networking and Mobile Computing, 2008.

WiCOM'08. 4th International Conference on, 1-5.

128

Young, R. R. (2001). Effective requirements practices Addison-Wesley Longman

Publishing Co., Inc.

Zairi, M., & Youssef, M. A. (1995). Quality function deployment: A main pillar for

successful total quality management and product development. International Journal

of Quality & Reliability Management, 12(6), 9-23.

Zave, P. (1997). Classification of research efforts in requirements engineering. ACM

Computing Surveys (CSUR), 29(4), 315-321.

Zhang, X., Bode, J., & Ren, S. (1996). Neural networks in quality function deployment.

Computers & Industrial Engineering, 31(3), 669-673.

Zultner, R. E. (1994). Software quality function deployment. Annual Quality Congress

Proceedings-American Society for Quality Control, 783-783.

Zultner, R. E. (1995). Blitz QFD: Better, faster, and cheaper forms of QFD. American

Programmer, 8, 24-24.