The IEEE and ISO 9000 define quality as "fitness for purpose," which mirrors Philip Crosby's (1979) widely accepted definition of quality as "conformance to requirements." However, for a project manager planning a new project, the ISO 9000  definition does not provide a detailed basis for software quality planning.
Although many people seem comfortable accepting these definitions, they miss an important related question: Whose requirements and whose purpose?
Based on Jim McCall and Mike Matsumoto's (1980) work, our group has been using the following definition of business product and software quality. Quality is an agreed combination of the following quality attributes:
As in many other quality models, the various attributes can be positively or negatively related. For example, although improving maintainability does improve flexibility, the improvement of efficiency can lead to a lowering of usability, maintainability, flexibility, security, and auditability. The positive “negative relationship is identified by the fact that many of the quality attributes share common criteria. For example, flexibility and maintainability share four common criteria. As discussed later in this chapter, you and your team must identify potential conflicts in the product's quality requirements and resolve them before the project begins.
Some pragmatists also add deadlines and cost as a measure of software quality. However, these are constraints, not quality requirements. Many business people faced with cost-reduction pressures and increasing competition based on market windows have been prepared to sacrifice the software quality attributes just listed to simply get a low-quality software solution on time and in budget. Cost and deadlines clearly have a negative relationship with all other software quality attributes.
Although Crosby's admonition that "quality is free" is true in respect to the costs of rework , many computer people have learned that certain software quality attributes are very expensive. The development of a GUI system with full online help and extensive manuals for users, administrators, and power users could incur 50% to 100% additional effort when compared to a similar data and function requirement with a minimum requirement for usability.
In other words, the formalization of software quality attributes reveals the fact that software quality has inherent conflicts. These are exacerbated by the existence of many external people or groups (stakeholders) that have differing views on the required quality for a particular software system. As shown in Figure 10.2, these groups have specialized and often narrow views of the required software quality.
Figure 10.2. Product quality: A conflicting client community
For one particular system, the internal audit department may be concerned about controls and audit trails, whereas the data center may be concerned with reliability, efficiency, and maintainability. Communications may be concerned only with network efficiency and standards may be interested in the following of development standards during the system life cycle. Senior management is focused on deadlines and the business people want usability and reliability. Faced with conflicting quality requirements, it is understandable for project managers and the teams to simply ignore the conflict and impose their own quality requirements on the project!
The process of product quality planning must recognize these conflicts and provide two structured and negotiated outcomes : What is the required quality and what processes are to be in place during the development process to ensure the negotiated quality is delivered. This is the essence of project quality deployment (PQD).