Ieee

from the editor
Editor in Chief: Steve McConnell
I

Construx Software

I

software@construx.com

Real Quality For Real Engineers
Steve McConnell

F

or decades, experts have struggled to define quality. Edwards Deming said that the only definition of quality that mattered was the consumer’s.1 Joseph Juran said that quality was fitness for use.2 Philip Crosby provided the strictest definition of quality as “conformance to requirements.”3 Conformance to requirements Although they differ on the details, quality experts agree that the customer’s view of requirements is critically important. For that reason, I’ve found Crosby’s definition of “conformance to requirements” to be the most useful definition in examining software quality. Taking into account many software projects’ tendency to elicit some but not all of the customer’s complete requirements, “requirements” cannot be interpreted solely as the written requirements. Requirements must also include implicit requirements—those that the customer assumes regardless of whether the development team happens to write them down. Thus, the working definition of quality that I use is “conformance to requirements, both stated and implied.” The “ities” of software quality In addition to specific functional requirements, software quality is also affected by common nonfunctional characteristics that are often referred to as the “ities.” The ities that affect software’s internal quality (quality
Copyright © 2002 Steven C. McConnell. All Rights Reserved.

visible to the software’s developers) include maintainability, flexibility, portability, reusability, readability, scalability, testability, and understandability. The ities that affect the software’s external quality (visible to the customer) include usability, reliability, adaptability, and integrity, as well as correctness, accuracy, efficiency, and robustness.4 Some of these characteristics overlap, but all have different shades of meaning that are desired...