What is Quality Software?

Like any discussion of quality, one must first recognize that quality is never a single attribute but a collection of attributes and their relative presence in the item of interest. When we speak of a car that we believe is of high quality, we generally do not mean one where it has a beautiful interior and exterior with flawless fit and finish but suffers from poor acceleration and breakdowns. Yet a small, inexpensive car may have relatively poor performance but a superb dependability record and prosaic but serviceable interior amenities can be seen as a car of quality, although usually stated a good value. What the first example lacks is a good balancing of the various attributes in the vehicle while the second offers good tradeoffs that allow its purpose for use to more nearly fit our needs. So quality is not a single attribute but some collection of attributes that reflect the decisions a designer made when during the design process.

Software is no different. Microsoft has properly taken heat for creating operating systems that seem to regularly crash causing confusion and pain for the consumers who must use them while simultaneously loading them with features that only some minority of the consumers want or need. The driver behind the feature bloat is the marketing engine which is interested in growing market share and selling new products to replace the older while the cause of the software errors is a rush to market and a corporate culture that does not value engineering excellence over profits. What results is a product that is shaped by the forces at work in the design and build. It is a combination of various attributes including price, dependability, functionality and performance in some relative levels. At least at the Software Engineering Institute at CMU, those attributes of software systems are called qualities.

There are different categories of qualities and their treatment varies. For example, the one quality that has historically gotten most of the attention has been functionality. Since this is vital and the very essence of correct functioning, that is no surprise. This owes to the fact that in the decomposition from need to solution a software engineer must eventually express the solution in for the formalism of a mathematical function since that is what a machine will execute. However cost is a much more difficult attribute to tie determine since it is bound up in business processes, management, markets and economics. There are a group of qualities that can be grouped together under the heading of qualities in use. Performance, reliability, usability, security, and availability are qualities in use since they are directly observed by the user. There are another group of qualities that are not seen by the user but are important to the owner of the software system. They include buildability, maintainability, testability and modifiability to name just a few.

What we have just started exploring is a taxonomy of software system qualities. (from wikipedia, "Taxonomy (from Ancient Greek: τάξις taxis "arrangement" and Ancient Greek: νομία nomia "method"^[1]) is the practice and scienceof classification. Taxonomy uses taxonomic units, known as taxa (singular taxon). In addition, the word is also used as a count noun: a taxonomy, or taxonomic scheme, is a particular classification ("the taxonomy of ..."), arranged in a hierarchical structure. Typically this is organized by supertype-subtype relationships, also called generalization-specialization relationships, or less formally, parent-child relationships. In such an inheritance relationship, the subtype by definition has the same properties, behaviors, and constraints as the supertype plus one or more additional properties, behaviors, or constraints. For example: car is a subtype ofvehicle, so any car is also a vehicle, but not every vehicle is a car. Therefore a type needs to satisfy more constraints to be a car than to be a vehicle.")

It is always tempting to develop a complete taxonomy. However we will see later that while interesting from an academic perspective, it is unnecessary for the practice of requirements gathering.

Traditionally all of these qualities, except functionality, were grouped under the heading of non-functional requirements. While functional requirements have been gathered with some success in the past, non-functional requirements were largely ignored. We shall see that this has been a stumbling block to achieving Quality software since many design decisions are predicated more on the basis of the non-functional requirements than they are on functional requirements.

So the Quality (big Q) of a software system is the fitness for purpose of the system as measured by the gap between the various qualities (little q, or attributes) of the system and the client's needs.