What is quality?


Before attempting to describe what quality is, let's look at some other descriptions of quality:

“Quality is the ongoing process of building and sustaining relationships by assessing, anticipating, and fulfilling stated and implied needs.“ - Richard E. Winder

“... It's OK for anyone to use words any way they wish. That's their privilege. But those of us who have to make quality happen must have a definition that's manageable and measurable. 'Goodness' is neither. I have always defined quality as 'conformance to requirements'; the ISO 9000 procedures use that definition also. ...” - Philip B. Crosby

Crosby 's understanding of the quality concept is a binary value function: quality value is either present or absent in a product. This description, with all its apparently simplistic approach, has the great advantage of being quite easy to implement in a development process or in a manufacturing model.

Joseph M. Juran defines quality of a product as “meeting customer's expectations”, with two main components:
  1. fitness for use;
  2. freedom from failures.

W. Edwards Deming describes the quality as an attribute of a product which may be defined only by the customer. His approach puts emphasis on three product characteristics as pertaining to quality of a product and the process used to obtain it:

  1. Fitness for the targeted market niche;
  2. Controlled variability translated in predictable uniformity;
  3. Manageable costs.

Other “Definition of Quality: "WOW!" RATIONALE: Suppose you were with your 'soul mate', 'significant other', 'spouse', etc. and after a relationship that person looked longingly into your eyes and said "That met the requirements!" or "There were no defects there!" or "That had all the value I wanted!" or "The degree of excellence was acceptable!. Wouldn't you rather have that person look into your eyes and say "WOW!"?” [Anonymous]

Description vs. Definition

I will not attempt to really define quality. My opinion is that we cannot formulate a definition of the quality concept which is at the same time rigorous [Note 1], complete, and directly applicable to the development process. So I will give only an approximate and incomplete description of the quality concept which suits my attempt to solve some of the quality assurance problems a software development organization is facing.[Note 2]

So if we chose to think about quality as:

We can describe quality as:

Quality of a product is an attribute that reflects the level of fulfillment of its end users' needs, associated with its level of harmlessness to anyone or anything that is a part of our environment. [Note 3]

Quality Descriptions Comparison


Quality reflects [attribute]

Quality relates to [stakeholder]


Meeting expectations ( 1. fitness for use; 2. freedom from failures)



As defined by the customer



Conformance to requirements

Customer (implicitly)


Ability to satisfy stated and implied needs

Not mentioned


Ability to satisfy specified requirements

Not mentioned

V. Gherea

1. Level of needs fulfillment

Users' community

2. Level of harmlessness

Everyone and everything


  1. By the term 'rigorous definition' I mean the classic concept of definition – the genus-differentia type of definition, or what logicians call: Definitio fit per genus proximum et differentiam specificam.
  2. Actually all the authors who define quality are doing the same descriptive exercise, only they chose to name it 'definition' rather than 'description'. (It seems that the term definition has a more post-modernistic/academic distinction ... ☺ ...)
  3. The 'level of harmlessness' characteristic of quality, may be implicitly included in the 'fulfillment of needs' part, but I feel that it makes the description less clear.
  1. Quality is pertaining to all the user's relevant needs. It means that the developing team should consider all the stated, implied, perceived, deduced, inferred or assumed needs – all of them.
    Note: These users' needs should be collected, determined, analyzed, selected, agreed upon, and then translated in some form of requirements specifications.
  2. The “non-technical” needs as: time to delivery, estimated price, or version, release and licensing policies should be also considered during user's needs collection and analysis process.
  3. Independently of the business model, the main goal of maximizing the quality of a product (for a given investment in the product's development, manufacturing and distribution) is to build and to maintain a good business relationship between the product vendor and the users' community. The bottom line is that only such a relationship will secure a constant revenue to the owners of the development organization over time and will ensure business stability. To build such a relation the best thing is to relate to users' community real needs rather than to some “artificial” specs.
  4. The product should be and should do everything that it is supposed to be and to do respectively, and nothing else; or, at least, nothing else that is perceived as harmful.
  5. This approach to define quality as: “users' needs fulfillment”, as opposed to the “conformance to requirements” or to “customer's expectations/definition”, makes the end user the beneficiary of the product rather than the customer (who can be a different stakeholder with other perceptions), or some product manager inside the development organization, who is even more distant form the end user by interests and understanding.
  6. It is a good practice to list these needs in the order of their importance as the user understands it, and it is also useful to associate to each of them an estimate of feasibility and an evaluation of the development risks. The time invested in this listing will be fully recovered throughout the requirements elicitation process and during development planning activities.
  7. The comparison of product's features and attributes with the users' needs and the product's harmlessness should be a continuous process over the product's life cycle.
  8. This approach to the quality description will be validated only if the final acceptance tests (as a minimum) will close the verification loop with the users' needs, rather than the “classic” practice to base the final tests on the requirements specifications only.

careers | contact | dallya