This... is the Quality Problem: too many enigmatic statements! In fact, the definition has even changed over time; the concept has shifted from the old definitions (still in use today by many) that refer to 'curing' product problems to the newer definitions (accepted as 'best practice') that refer to 'preventing' product problems.
These platitudes and proclamations are difficult to relate to meaningful guidelines for product developers because they represent imprecise concepts, which are mapped all over the areas of market, user, business, product, design, testing, manufacturing, distribution and support. How can a product developer make sense of it all? How can Quality be defined in a manner that can be concretely applied to the operations of product development so as to be useful to the marketing, engineering and manufacturing efforts?
At the ideational level Quality starts with a company philosophy. This needs to be a proclamation from an executive level that requires implementing a process, which results in providing assurance to customers that a product exactly meets it's written and spoken claims.
An international standard in use today, which tenders such a Quality philosophy, is the ISO 9001-2000 Quality Management System. Refer to http://www.iso.org/iso/en/iso9000-14000/understand/qmp.html for further information on this corporate-wide management system. This standard is not mandated by law, but is demanded by many purchasers and should be considered by any product development group as a prerequisite for producing quality products. By itself, such a quality management system does not, in itself, ensure a quality product - that is the subject of this discussion.
One of the misunderstandings many product developers have about product quality is that no one agency or authority sets the Quality standards for their product. The market place, users' expectations and corporate philosophy are actually the progenitors of quality requirements.
Regulatory agencies, various laws and some authorities (e.g. UL, FCC, CE, ISO and FDA, RoHS, etc.) do specify some rules regarding specific product attributes, such as interference with the environment, safety, user interface and health interactions. See:
However... as a product developer, you and your company are the ones who must define and assure the quality aspects for your product - not someone else. Various product development processes (see reference 3) also provide some tactical approaches to achieving a quality product.
To start the demystification of the Quality Problem, Quality concepts will be apportioned to various parts of the product development enterprise. Once this is done we will be able to move into the province of useful, objective actions.
Even though the treatment of Quality herein is at a rather simple level (the forest, not the trees), enough Quality concepts are presented in such a way that the product developer can grasp (1) what issues are important and (2) how they can be used in the development process. Quality engineers can carry on the details of their own discipline as required.
