QFD IN SOFTWARE ENGINEERING. A thesis submitted. to Kent State University in partial. fulfillment of the requirements for the

Transcription

1 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

2 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

3 TABLE OF CONTENT LIST OF FIGURES... VII LIST OF TABLES... IX ACKNOWLEDGEMENTS... X CHAPTER 1 INTRODUCTION Background Objectives of the Study Research Problem Scope of the Study Organization of Thesis... 3 CHAPTER 2 QFD OVERVIEW Definitions of QFD Difference between QFD and Other Quality Methodologies Brief History Benefits of QFD Objectives of QFD Applications of QFD Problems and Limitations of QFD Quantitative Approaches of QFD iii

4 2.8.1 AHP Fuzzy logic ANN The Taguchi Method Statistically Extended QFD Dynamic QFD CHAPTER 3 THE QFD PROCESS Four-Phase Model House of Quality (HOQ) Part A. Customer Requirements (WHATs) The Kano Model Part B. Planning Matrix (WHYs) Part C. Technical Measures (HOWs) Part D. Relationship Matrix between WHATs and HOWs Part E. Technical Correlation Matrix Part F. Technical Matrix Numerical Example The HOQ The Complete QFD CHAPTER 4 ATTEMPTS TO USE QFD IN SOFTWARE DEVELOPMENT Zultner s Software Quality Deployment (SQD) Approach iv

5 4.2 Blitz QFD Shindo s Approach Ohmori s Model Herzwurm, Schockert, and Mellis PriFo Software QFD Model Liu s Software QFD Experiences with Software QFD CHAPTER 5 IDENTIFY SOFTWARE ENGINEERING ACTIVITIES THAT ARE QFD STEPS AND FILLIING THE GAPS Phase Product Planning in QFD Requirement Phase in Software Engineering How Can a Software Engineer Get Benefits from QFD? What is QFD Missing? Suggestions to Improve QFD for Software Engineering Phase Parts Deployment in QFD Design Phase in Software Engineering How Can a Software Engineer Benefit from QFD? What is QFD Missing? Suggestions to Improve QFD for Software Engineering v

6 5.3 Phase Process Design Phase in QFD Implementation Phase in Software Engineering How Can a Software Engineer Benefit from QFD? What is QFD Missing? Phase Process/Quality Control in QFD Testing Phase in Software Engineering Phase Maintenance Phase in Software Engineering An Enhanced Software QFD A Numerical Example of HOQ CHAPTER 6 CONCLUSION AND FUTURE WORK REFERENCES vi

7 LIST OF FIGURES Figure 2.1. Interpretation of Japanese characters for QFD Figure 2.2. Japanese automakers with QFD made fewer changes than did U.S. companies without QFD Figure 3.1. The four-phase model of QFD Figure 3.2. Brief description of the HOQ Figure 3.3. Detailed description of the HOQ Figure 3.4. The Kano model Figure 3.5. Relationship levels Figure 3.6. Bundles of customer requirements Figure 3.7. Relative importance of customer requirements Figure 3.8. Customer competitive assessments Figure 3.9. Direction of improvement Figure Relationship matrix Figure Technical correlation matrix Figure Technical measures Figure House of quality (HOQ) Figure 4.1. Zultner s comprehensive approach vii

8 Figure 4.2. Z-0 matrix for classifying users Figure 4.3. Zultner s information deployment Figure 4.4. T -type matrix Figure 4.5. Blitz QFD Figure 4.6. Shindo s approach Figure 4.7. Ohmori s model Figure 4.8. PriFo approach Figure 4.9. Liu s SQFD Figure Satisfaction of the developers with product-related goals Figure Satisfaction of the developers with project-related goals Figure 5.1. Waterfall model Figure 5.2. Four-phase model Figure 5.3. Enhanced software QFD Figure 5.4. GPS example viii

9 LIST OF TABLES Table 2.1.Summary of QFD Applications in Software Systems Table 4.1.Comparison of Results Achieved between Traditional Approaches and SQFD Table 5.1.Criteria of a Good Requirement ix

10 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

11 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

12 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

13 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.

14 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

15 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

16 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).

17 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).

18 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 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 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

19 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;

20 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.

21 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;

22 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.

23 13 Table 2.1.Summary of QFD Applications in Software Systems Counts Application area Authors 1 Software 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), 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) 2 Decision support systems Sarkis and Liles (1995) 3 Expert systems Ngai and Chow (1999) 4 Human machine interface Nibbelke et al. (2001) 5 Information systems Chang and Lin (1991), Erikkson and McFadden (1993), Han et al.(1998) 6 Integrated systems Wasserman et al. (1989) 7 Management Eyob (1998)

24 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;

25 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.

26 AHP Developed in 1980, the analytical hierarchy process is a multi-criteria decisionmaking 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 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) Fuzzy logic The idea of fuzzy logic or fuzzy set was presented in 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

27 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.

28 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 machinelearning 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 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.

29 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

30 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 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-

31 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 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.

32 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

33 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:

34 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,

35 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.

36 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.

37 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.

38 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.

39 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 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.

40 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.

41 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.

42 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

43 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 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

44 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.

45 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

46 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 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

47 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).

48 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) 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

49 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? 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

50 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.

51 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:

52 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

53 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

54 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

55 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).

56 Figure 3.6. Bundles of customer requirements. 46

57 47 Bundles Customer Requirements Relative Importance Easy to open and close door Easy to close from outside 7 Stays open on a hill 5 Isolation Doesn t leak in rain 3 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.

58 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.

59 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).

60 50 Figure 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.

61 51 Figure 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.

62 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.

63 53 Figure Technical measures 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.

64 54 Figure 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

65 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 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

66 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.

67 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

68 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.

69 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

70 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

71 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.

72 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.

73 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

74 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)

75 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.

76 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).

77 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.

78 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

79 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.

80 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

81 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.

82 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

83 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:

84 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).

85 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

86 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 Results Achieved Mean Traditional Rating Mean SQFD Rating Communication satisfactory with Personnel technical Communication satisfactory with users User requirements met Communication satisfactory with management Systems developed within budget Systems easy to maintain Systems developed on time Systems relatively error-free Systems easy to modify Programming time reduced Testing time reduced Documentation consistent and complete

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 Satisfaction of the developers with product-related goals.

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

89 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

90 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.