Download as ZIP, PPTX
Uploaded byguy_davis
Quality Function Deployment
The document discusses Quality Function Deployment (QFD), a requirements management technique that involves translating customer needs into technical requirements and product design criteria. It covers the basic concepts and phases of QFD, including how to build a House of Quality matrix to prioritize requirements. The document also compares QFD to other software development life cycles such as Cleanroom, SASD, JAD, PD, RAD, SSM, RUP, and XP.
More Related Content
Similar to Quality Function Deployment
Editor's Notes
- #2 Quality Function Deployment (QFD) is a technique for requirements engineering borne out of the quality movement in the 1980’s. It didn’t originate as a requirements engineering technique. It originated in Mitsubishi’s Heavy Industries Kobe shipyard in Japan in the late 1960’s [Madu, 1999] and since then, expanded into use in other industries and for various purposes. This chapter introduces the “original” QFD concepts and applies them to software requirements engineering processes. To do this, we rely on research and original work from various sources around the world – attesting to QFD’s popularity. The key concept behind QFD is satisfying the customer – and that concept still applies today, in fact, we can hardly believe that there was a time when we wouldn’t try to satisfy the customer as the first and most critical priority.
- #3 Quality Function Deployment (QFD) is a technique for requirements engineering borne out of the quality movement in the 1980’s. It didn’t originate as a requirements engineering technique. It originated in Mitsubishi’s Heavy Industries Kobe shipyard in Japan in the late 1960’s [Madu, 1999] and since then, expanded into use in other industries and for various purposes. This chapter introduces the “original” QFD concepts and applies them to software requirements engineering processes. To do this, we rely on research and original work from various sources around the world – attesting to QFD’s popularity. The key concept behind QFD is satisfying the customer – and that concept still applies today, in fact, we can hardly believe that there was a time when we wouldn’t try to satisfy the customer as the first and most critical priority.
- #4 These objectives stem from our belief that few software organizations actually practice “complete” QFD – it is more likely that they will use concepts or even some tools from QFD to help them perform specific requirements engineering tasks. What are those concepts and tools that software people find useful? To answer this question, we have to start at the ground level and learn the basics of QFD first. Then we can learn how to apply those concepts and tools to software and specifically to requirements engineering.
- #5 Our basic intent is to support your work as a requirements engineer with concepts and practices from QFD, in other words, to take what we can from QFD and apply it in our requirements engineering practice. In order to do this, we will briefly review the following: Definition – what is QFD? Benefits – why QFD? History – where did QFD come from? Software Engineering Context – how does QFD fit into SE? Requirements Engineering Context – how does QFD fit into RE?
- #6 Since it’s been used in a wide variety of industries and over a number of decades, QFD has several definitions. Whatever you do, don’t interpret QFD as being solely the House of Quality. There is more to it than that: American Supplier Institute: “A system for translating consumer requirements into appropriate company requirements at each stage from research and development to engineering and manufacturing to marketing/sales and distribution.” [ASI, 1989]. Akao: “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]. Note that both definitions (as well as any others that you will read) mention the term “consumer”, also known as the “customer.” QFD is part of the quality revolution, but also part of the customer revolution in the 1980’s. The bottom line: QFD includes methods, tools, and techniques to support satisfying your customer.
- #8 The main benefits of QFD are: Improved Customer Satisfaction Reduced Development Time Improved Internal Communications Better Documentation of Key Issues Save Money Some additional benefits are: Improved morale, organizational harmony Improved efficiency Reduction in design changes Increased competitiveness High market acceptance Problems are easier to identify
- #9 1966 – Bridgestone Tire Corporation, process assurance items table 1967 – Akao writes about QFD 1972 – Mitsubishi’s Heavy Industries Kobe shipyard – quality chart (evolved into the House of Quality) 1978 – Toyota Autobody 1983 – First QFD Seminar (Japan) 1990’s – American automotive industry adopts QFD 1996 – survey indicates that QFD is used more in the U.S. than in Japan, based on surveying companies that participated in QFD seminars and conferences. There were several core ideas that evolved into QFD, over a number of years. Many people assume that QFD started at Mitsubishi, or that it was an invention of Toyota Motor Corp, however, according to [Akao, 1997] this isn’t quite true.
- #10 QFD relates to software engineering just like it would any other engineering discipline. Software engineering requires the same emphasis on customer satisfaction, benefits the same way from having cross-functional teams, and suffers from the same issues with quality. Organizations that embraced Total Quality Management (TQM) were more likely to also embrace Software Quality Function Deployment, or SQFD [Haag et al, 1996]. SQFD is primarily a requirements engineering technique as opposed to a complete life cycle, although Betts speculated on translating the traditional QFD phases to phases in the software life cycle. [Betts, 1995]. We will investigate the QFD traditional phases and Betts’ idea on a subsequent slide.
- #11 In a requirements engineering context, the primary benefit of using SQFD concepts is that you gain the “voice of the customer” early in the development process. Any foundational software development life cycle depends on solid requirements, so you can see how valuable this might be. In addition, concepts borrowed from the QFD “customer value” concept lead Wiegers to optimize his requirements prioritization scheme (a variant of AHS) [Wiegers, 1999]. We conclude that SQFD is all about requirements engineering, even though QFD itself is more of a holistic view of a product development process.
- #12 In order to gain another perspective on QFD, it makes sense that we place QFD in context of other software development life cycles, life cycles that are more common in software organizations. “Few software organizations seem to be willing to undertake the rigor of QFD or TQM.” [Wiegers, 1999]. This section introduces the 4 phases of QFD and then goes into SQFD in more detail.
- #13 “Quality function deployment is a process of listening to the ‘voice of the customer,’ identifying the customer’s needs, and incorporating those needs in the design and production of goods and services” [Madu, 1999]. This quote emphasizes the role of QFD in the entire production scheme, not just at the beginning. QFD is NOT equal to the House of Quality! We will, however, focus on the House of Quality since it is most relevant to requirements engineering. But as a take-away message, be remindful of the fact that QFD revises the design and production stages of product and service delivery. Note how the “hows” from one phase become the “whats” of the subsequent phase. Think of these phases as more iterative than waterfall. The House of Quality (HOQ) – The HOQ is a blueprint for product development [Madu, 1999]. It’s called a “house” because of it’s physical appearance. Note that the HOQ goes by the name “quality chart” outside of North America [Akao, 1997]. Customer requirements, technical requirements, requirements prioritization, design targets, all merge onto the HOQ through a multi-step process. The HOQ is the focus of section 3 in this presentation.
- #14 This represents Betts’ attempt at translating the four phases of QFD to software. This is NOT the SQFD approach but rather tries to match the holistic spirit of the original QFD to come up with a complete life cycle for software development based on QFD principles. In this approach, the customer voice drives the determination of measurable objectives, and in turn the measurable objectives drive the high level design, etc. This way, the customer voice ultimately drives the entire software development process. Note that “process planning” is one of the phases in this approach. This is remindful of Zultner’s approach for using TQM/QFD in software development projects. Zultner emphasizes that project teams should identify their own process improvement goals and design targets, in the greater context of the organization’s goals for improvement [Zultner, 1993].
- #15 This diagram represents the QFD House of Quality concepts applied to requirements engineering, or SQFD. “SQFD is a front-end requirements elicitation technique, adaptable to any software engineering methodology, that quantifiably solicits and defines critical customer requirements” [Haag, 1996]. Step 1 – Customer requirements are solicited and recorded Step 2 – Customer requirements are converted to technical and measurable statements and recorded Step 3 – Customers identify the correlations between technical requirements and their own verbatim statements of requirement Step 4 – Customer requirement priorities are established Step 5 – Applying weights and priorities to determine the technical product specification priorities (this is a calculation)
- #16 The House of Quality is a central tool of QFD, it translates customer requirements, market research and benchmarking data into prioritized engineering targets to be met by a new product design. Benchmarking: comparing performance in market of your own and other products against design measures helps define the real level of performance in relationship to the desired level. The HOQ is broken into 6 steps shown above.
- #17 Customer Requirements – HOWS 1st & most important; documents a structured list of a product’s customers requirements described in their own words – Voice of Customer Information is gathered through conversations with the customer. They describe their needs and problems as they pertain to the desired product. Use an Affinity and Tree Diagram to structure the requirements before placing them into the Customer Requirements section of the HOQ.
- #18 Affinity Diagram – each customer statement is written on to a separate card, cards are arranged into groups with perceived associations From each group a title card is chosen which encapsulates the meaning contained within that group and those titles are sorted again. Completed affinity diagram can then be used as the basis of a tree diagram, constructed from the top down. Structure is documented in the customer requirement part of the HOQ. In this example, the blue grouping falls under Usability, the orange grouping falls under Performance and the Attractive card is left in a category by itself
- #20 Planning Matrix 1)quantifies the customer’s requirements priorities 2)quantifies perceptions of the performance of existing products 3)allows priorities to be adjusted based on the issues that concern the design team Measures used are gathered from customer’s using a questionnaire and shown in a column alongside the customer requirement description. One of the better methods (but more involved) for prioritizing is the Analytical Hierarchy Process (SENG 611) where requirements are paired and the customer picks the most important of the pair. Requirement Importance Weighting - shows the relative importance of each of the customer’s requirements from their perspective – most important measure
- #21 Customer Satisfaction – how existing products fulfill their requirements Planned Satisfaction Rating – illustrates the desired satisfaction of customer requirements to be achieved by the desired product Improvement Ratio – divide planned performance by performance core of existing product Sales Point - a weight added to the requirements that can be used to help market the product Overall Weighting – multiplication of importance weight by improvement ratio by sales point
- #22 Customer Satisfaction should be shown for the existing product and competitors’ products. It should be noted… upon looking at different examples of the planning matrix there were different formulas for computing the improvement ratio. Two example formulas found were: Improvement Ratio = Planned Satisfaction / Customer Satisfaction (a.k.a)Planned Performance / Existing Performance OR Improvement Ratio = (Planned Satisfaction / Customer Satisfaction) * .2 + 1 The sales point is given as a value between 1.0 and 1.5, although the justification for this has not been determined. As long as the values are consistent across all computations, it is merely a scale to add weight to a priority.
- #23 Technical Requirements – WHATS A.K.A. Engineering characteristics, Voice of the Company. It describes the product in terms of the company. Structured set of relevant & measurable product characteristics. QFD design team identifies all measurable characteristics of the product which they consider are related to meeting the specified customer requirements. May have more than one technical requirement to convey one customer requirement. Also may use affinity and tree diagrams to interpret the characteristics. Include an additional row to illustrate direction of change which is considered to result in improvement of product performance.
- #24 Goal : To translate customer requirements into technical requirements for the new product. Description This section is the central portion of the House of Quality. It can be very time consuming to complete as one must make m * n comparisons where m is the number of customer requirements and n is the number of technical requirements. For each combination, the QFD team must ask “How significant is technical requirement A in satisfying customer requirement B?”
- #25 Steps: For each combination of customer and technical requirement, the level of interrelationship is recorded. Use a relative scale of high, medium, low, and none. Each ranking is assigned a numeric value such as high – 9, medium – 3, low – 1, none – 0.
- #26 Step 5: Roof – Feature to feature comparison The triangular “roof” matrix of the House of Quality is used to determine the effects that the technical requirements have on each other. This is most important for identifying engineering trade-offs. These are situations where the improvement in one requirement results in the detoriation of another. Taking these situations into account during the requirements stage is crucial for a successful system design.
- #27 Roof Steps: Determine whether an improvement in a requirement would require increasing or decreasing it’s measure. For each combination, determine whether improving one requirement will be supporting or a tradeoff for the other requirement This step also provides the QFD team with places where a focused design improvement could lead to gains in a number of different requirements. As well, by revealing the presence of engineering trade-offs, it offers opportunities for innovations to avoid the compromise entirely.
- #28 Goal: The purpose of the last step is to integrate the results from all the previous steps into a set of useable targets to be used during design and implementation. The crucial difference between QFD and more traditional approaches is that QFD generates targets based on a repeatable, statistical analysis.
- #29 Technical Priorities A prioritization of the technical requirements can be accomplished by summing the product of the interrelationship weightings with the overall weighting assigned during the Planning step. Steps For each technical requirement’s column, sum the product of the customer requirement’s overall weighting with the interrelation value(0-9).
- #30 Competitive Benchmarking Each of the important technical requirements can be evaluated against the existing product system (if previous version exists) and against competitor systems. Matrix values are simply the measure of the technical requirement. This could be a binary or numeric descriptor. The goal is to determine the relative positions of existing products with regard to each of the identified technical requirements.
- #31 Final Targets The output from the House of Quality is a set of targets for the important technical requirements. The results from all the stages of the House of Quality are used to generate these targets. QFD team draws on customer’s needs, competition’s performance, and organization’s current performance to determine these targets.
- #34 These are really the advantages and disadvantages of QFD itself, at least from requirements management perspective. The general criticism of QFD is that it is a costly approach, required a “big requirements up-front” phase; this has the effect of pushing the team to use a waterfall software development life cycle as opposed to an iterative one.
- #35 Our last topic is a brief comparison between QFD and the rest of the life cycles that we will discuss in this class. Note the acronyms – isn’t that a sign of intelligence? The more acronyms you use the more intelligence you have?  Here’s an explanation of each acronym: XP – Extreme Programming SASD – Structured Analysis and Structured Design SSM – Software Systems Method. PD – Participatory Design RAD – Rapid Application Development JAD – Joint Application Design RUP – Rational Unified Process CLEANROOM – That’s not an acronym, but thanks for asking And just in case you missed our presentation, QFD – Quality Function Deployment
- #36 What they share: Emphasis on quality Emphasis on statistical process control Emphasis on customer feedback Emphasis on quantitative methods What differs: Mathematical emphasis in Cleanroom QFD requires cross-functional teams
- #37 What QFD and SASD share: Philosophy of identifying “what” the system must do before describing “how” it will do it The idea of structuring requirements What differs: Plethora of possible notations for SASD (Gane-Sarson, Yourdon/DeMarco, SSADM IV, etc. while QFD doesn’t require models other than the HOQ QFD is iterative, while SASD tends to be practiced using a waterfall life cycle QFD is mostly a group session technique, focusing on cross-functional teams, while SASD doesn’t require cross-functional teams (although an organization could apply it that way)
- #38 What QFD and JAD share: Both are group session techniques Both require facilitators Both require the project team to work with the customer What differs: JAD is not a quality-focused technique but a communication-focused technique, there is a subtle difference there To use JAD, the customer has to be able to visualize the software since they participate directly. This isn’t necessarily true for QFD.
- #39 Participatory design is a group session where developers, business representatives, and users work together to design a solution. There is a strong emphasis on usability in most participatory design sessions. What QFD and PD share: Emphasis on end users (customers) What differs: PD has a social context – initially developed so that unions could have input into technology introduced into the workplace PD has a usability focus, while QFD treats usability as a requirement if the customer voice says it is a requirement
- #40 A way of developing a system by completing a working part, implementing it, and adding more working parts every few months, instead of waiting to finish the entire project before putting the system into use. Otherwise, changes take place so fast in the computer industry that an application can be obsolete by the time it is implemented. Development tools such as visual programming and computer-assisted software engineering help with Rapid Application Development [computeruser.com, 2001] What QFD and RAD share: They are both group sessions What differs: Quality versus speed RAD uses time-boxing to prevent scope creep, QFD has no such counterpart
- #41 “Soft Systems Methodology (S.S.M.) is, in reality, a set of methodologies. Each methodology is represented by a set of ideas (concepts) structured in such a way that their use is appropriate to the situation being analyzed. The use of Soft Systems Methodology as a powerful problem-solving tool requires this flexibility. Each situation is unique and hence methodology must be tailored to fit the situation and also the style of the analyst using it.” [Wilson, 2001]. What QFD and SSM share: Emphasis on the problem They are both group session techniques They are both iterative Where they differ: There is a problem-solving orientation to SSM as opposed to product-development orientation to QFD There is a knowledge capture/knowledge management undertone to SSM that doesn’t exist in QFD
- #42 RUP stands for Rational Unified Process™, a commercial methodology available from Rational Corporation (makers of Rational Rose™). We’re including this comparison here simply because it is a methodology that you will most likely come across in your career. What QFD and RUP share: Both rely on iterative development process RUP relies on customer requirements as the basis for the remainder of the project Many different roles (types of personnel) involved in the project at the same time What differs: RUP is configurable to being either more lightweight or more heavyweight, depending on your needs, even to the point of going waterfall if necessary RUP relies on use cases as the framework for managing requirements, nothing like the HOQ RUP requires the use of the Unified Modeling Language (UML) while QFD doesn’t require any models
- #43 XP, or eXtreme Programming, is a lightweight development methodology aimed at delivering high-quality software by de-emphasizing documentation and modeling for the sake of face-to-face communications with the customer, and numerous short iterations to deliver the desired application. What QFD and XP share: Emphasis on the customer, and the customer’s role in the project Release planning in XP feels like an affinity analysis exercise (tactile process; they actually use index cards) Emphasis on prioritizing requirements User stories – verbatim customer requirements? Both are iterative What differs: HOQ, and the ensuing calculations; never heard of in an XP project After the customer voice is captured, customers have little to do with the rest of the process; while in XP, customers remain involved as testing resources Release timing; QFD delivers the product in a big bang, while XP demands that teams release software early and often
- #44 Back to our original question, then. To what extent will QFD improve your requirements engineering and requirement management practices? Here are some questions from Wieger’s requirements practice self-assessment that we believe you could answer in a more positive manner if you used QFD concepts and tools: 3. How are sources for obtaining voice-of-the-customer input identified? [Chapter 7] a) Development already knows what to build. b) Marketing feels they can provide the user’s perspective. c) Focus groups of typical users are surveyed or interviewed. d) Specific individuals who can represent different user classes participate on the project, with agreed-upon responsibilities and authority.
- #45 11.How are priorities for individual features or requirements established? [Chapter 13] a) All of them are important, or we wouldn’t have written them down in the first place. b) The customers tell us which requirements are most important to them. c) All requirements are labeled as high, medium, or low priority by consensus among customers. d) We use an analytical process to evaluate the value, cost, and risk associated with each use case, feature, or functional requirement and help us make priority decisions. 15.How are software requirements traced back to their origin? [Chapter 19] a) They aren’t. b) We know where many of the requirements came from. c) All requirements have an identified origin. d) We have full two-way tracing between every software requirement and some voice-of-the-customer statement, system requirement, use case, standard, regulation, architectural need, or other origin.
- #46 17.How are the requirements used as a basis for design? [Chapter 15] (a) If we had requirements, we might refer to them during programming. (b) The requirements documents describe the solution we intend to implement. (c) Each functional requirement is traced into a design element. (d) Designers inspect the SRS to make sure it can be used as the basis for design. We have full two-way traceability between individual functional requirements and design elements.
- #47 The tool we looked at was called QFD Designer Business Improvement Software. It consists templates to create: House Of Quality : 4 different templates including different parts of the house. Voice of the Customer : Market Segment Analysis including demographics, customer use cases, verbatim statements. Product or Service Department Business Planning Six Sigma (best practices) Failure Analysis Includes icons to better represent relationships. Capability to add or delete requirements under a given segment. Capability to add or delete computations based on user needs & wants. Graphs required improvement.
- #48 References [Akao, 1990] Akao, Yoji (1990). Quality Function Deployment: Integrating Customer Requirements into Product Design. [Akao, 1997] Akao, Yoji (1997). QFD: Past, Present and Future. Available on-line at http://www.qfdi.org/QFD_History.pdf. [ASI, 2000] American Supplier Institute (2000) http://www.amsup.com/qfd/index.htm. [computeruser.com, 2001] ComputerUser.com Inc. High-Tech Dictionary Definition http://www.computeruser.com/resources/dictionary/definition.html? lookup=4256. [Haag et al., 1996] Haag, S., Raja, M.K., and Schkade, L.L. (1996). Quality Function Deployment Usage in Software Development. Communications of the ACM , 39(1). Available on-line through the University of Calgary portal to the ACM Digital Library. [Macauley, 1996] Macaulay, L.A. (1996). Requirements Engineering. Springer-Verlag Limited: London, 1996. [Madu, 1999] Madu, Christian M. (1999). House of Quality in a Minute. Fairfield, CT: Chi Publishers. [Mazur, 2001] Mazur, Glen (2001). http://www.mazur.net. [Ronin, 2001] Ronin International Corporation. Enterprise Unified Process Available on-line at http://www.ronin-intl.com/publications/unifiedProcess.htm. [SAIC, 2001] SAIC, Inc. (2001). The DoD Software Technology for Adaptable, Reliable Systems ( STARS ) program. Cleanroom Software Engineering Tutorial. Available at http://www.asset.com/stars/loral/cleanroom/tutorial/cleanroom.html. [Wells, 2001] Wells, Don (2001). Extreme programming web site. Available on-line at http://www.extremeprogramming.org/. [Wiegers, 1999]. Wiegers, Karl (1999). Software Requirements . Redmond, WA: Microsoft Press. [Wilson, 2001] Wilson, B (2001) Soft Systems Methodology web pages. Available on-line at http://www.softsystemsmethodology.co.uk/overview.htm. [Zultner, 1987] Zultner, R. E. (1987) Software Quality Deployment – Adapting QFD to Software, Proceeedings of 13th Rocky Mountain Quality Conference.