23-04-2010, 02:28 PM
[attachment=3355]
QUALITY FUNCTION DEPLOYMENT
Presented By:
Vijay
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?
QFD - History
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 seminar 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.
QFD - Definition
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.
QFD - Benefits
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
The House of Quality
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.
House of Quality Summary
Inputs:
Customer requirements
Technical requirements
Customer priorities
Market reality / competitive analysis
Organizationâ„¢s strengths & weaknesses
Outputs
Prioritized technical requirements
Measurable, testable goals
House of Quality Pros and Cons
Pros:
Generates specific technical requirements
Requirements are traceable
Follows a repeatable, quantitative process
Effectively translates Voice of the Customer
Records rationale for each technical requirement
Cons:
Time-consuming process for >10 requirements
Data storage, manipulation and maintenance costs
Very dependent on customer requirement gathering
Inflexible to changing requirements; must recalculate
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.
