The expression requirements were used in our description of the process of transforming VOC into required quality using a primitive data transformation sheet, so you might be wondering just what the difference is between requirements and required quality.
Once you start analyzing VOC data, you will notice that it comprises a mixture of varying requirements. Not surprisingly, customers sometimes ask for the impossible. Ask people about what they require from a wallet, and there is always at least one person who will answer: “I want a magic grab-bag that will hold everything I own.”
It would be a big mistake, however, just to consider that information useless and throw it away without first thinking about why that person chose to express himself in that manner. A little thought could reveal that what the person is looking for isn’t necessarily a wallet that will hold everything he owns as much as a wallet from which he can easily withdraw the things that he needs when they are needed.
Consumers are individuals and therefore have individual needs. Some will ask for a product to have new functionality while others will have requests that a product becomes easier to obtain either by having a more economical price or by having a greater number of sales channels and retail outlets. Parts manufacturers have clients who bring drawings and specification sheets indicating standards that specify quality characteristics. Many times customers come with the added requirement of a firm deadline for delivery.
Since we use a primitive data transformation sheet to organize these diverse requests, the first thing we do is make a list of requirements. After that, we see which of these requirements is concerned with product quality, and we extract those into a list of the required quality.
First of all, set aside requests about cost or pricing, about production capacity or delivery deadlines, and about reliability. For the time being, focus exclusively on quality. Occasionally there are those who simply can’t stand to separate things this way. It’s perfectly all right to create a requirement deployment table that contains every single item in your requirement list, but I have to warn you that dealing with such a large volume of data will make it difficult to see the big picture.
The whole point of QFD is to break things down before analyzing them. That is why we make a list of all the apparent requirements, organize them into categories, and extract those concerned with quality into a list of the required quality, and then create a required quality deployment table before beginning our study of quality. Only after that is done do we establish design quality and begin to study the cost and timeframe involved.
4M Analysis Process
The purpose of this procedure is to define the steps to do a 4M …
