EDIT'ORIAL uality and dependability of large software systems are among the most com- mon topics in discussions about computers. Organi- zations, both public and private, have invested huge sums in research to develop methodologies for produc- ing software of quality and depend- ability. Schools have devoted large efforts to curricula in the engineer- ing of software. Yet many people remain dissatisfied with the prog- ress of the field over the past de- cade. The methodologies currently employed to produce "software of quality" are based on the notion that quality is strongly related to rigor in the specifications and texts that appear throughout the soft- ware design process. According to this view, quality will be achieved when software is produced by a process consisting of four stages: obtain a clear and comprehensive requirements statement, construct a formal specification from the re- quirements, derive the programs from the specification, and demon- strate convincingly that the imple- mented program meets the specifi- cation. Program construction techniques that maintain tight rela- tionships between program struc- ture and dynamic behavior are con- sidered to be essential Readability, modularity, modifiability, style, adequacy of comments, and good tests are considered to be important guidelines. Failure to achieve soft- ware of quality is attributed not to possible limitations in the process itself, but to inadequate knowledge. WHAT IS SO~WARE QUaL|TY? Once the process is completed, the designer delivers the software to the customer and declares the job done. I claim that this understanding is too limited to enable us as a disci- pline to systematically fulfill prom- ises to deliver software of quality and dependability. I propose to reframe the question, from "What is software quality?" to "How do we satisfy the customers of our soft- ware?" By making concerns of cus- tomer satisfaction central among Peter j. Denning the criteria for judging software, new actions will appear for making reliable and. dependable software. Our current understanding treats quality as a property that can be built into a system by following certain rules and procedures. But this understanding inclines us to forget that "quality" and "depend- ability" are assessments others make based on their experience with how well the software helps them do their work. The question on the minds of the users of soft- ware is not, "Is this software well structured?" but "Does this soft- ware help me get more work done? Can I depend on it?" The greater the level of satisfaction, the more likely the customer is to say the soft- ware is of good quality and is de- pendable. An immediate and obvi- ous consequence of this shift of the question is that the software de- signer does not declare that the job is done. Instead, the customer de- dares satisfaction (or dissatisfac- tion) with what the software de- signer has delivered. The job of the software designer is not done until the customer has declared satisfac- tion. One can distinguish three levels at which a customer can declare sat- isfaction: 1. A// ~ prom/sts wtrt /~//d. The customer assesses that the pro- ducer has delivered exactly what was promised and agreed to. This might be called 'basic integrity'. 2. No negative consequences were pro- duted. The customer uses the prod- uct for a while and encounters no unforeseen problems that causedisruption and perhaps serious losses. The customer assesses that the product's design has been well thought out and that it anticipates problems that were not apparent at the outset. That this level is distinct from the previous one can be seen in the common anecdotes, "This is what I asked for, but it's not what I want!" and "It does what they promised but I wish I'd have asked about what it would do in this situa- tion!" 3. The customer is delighted. At this level the product produces no neg- ative consequences and, in fact, goes well beyond the customer's expectations and produces new, unexpected, positive effects. The customer expresses great delight with the product and often pro- motes it among others. The cus- tomer says the producer is a part- ner, understands the organization, and contributes to the well-being of the customer. With the new eyes given by these distinctions, I offer several observa- tions. (a) There is a level of satisfaction lower than the first level in the pre- ceding list; I call it 'cynical satisfac- tion'. We see a lot of it in the com- puter industry. Many producers repeatedly make extravagant and hyperbolic claims about their wares. Virtually all software licenses ex- plicitly disclaim any warranty or other responsibility by the pro- ducer. Customers have learned to discount the claims and purchase the software anyway. They find ways to use the software to make their work more productive. They say they are satisfied "once you fac- tor out the producer's claims and factor in reality." But this is not a stable situation, for the cynical cus- tomers will transfer to another pro- ducer as soon as a more realistic offer is made. (b) The first level has been made unnecessarily difficult to achieve because the language used to de- scribe business and organizational By muk~ng conc~rn~ of ~mon~ ~he cr~eF~o fo~ iudg~ng new ac~on~ wi|l appear for mukmng re|NQbMe ~n~ ~o~ware~ processes is different from the lan- guages currently used for formal specifications. For example, busi- ness processes are cyclic and com- prise networks linked by requests their participants make of other people; formal specifications use logic notation to describe input- output relationships of software components. Business processes have deadlines and are triggered by time-dependent events; tem- porality is difficult to express in the notation systems used for formal specifications. The customer and designer would be in a better posi- tion to know they are in agreement if the language of the specifications contained the same distinctions as the language of business processes. (e) Formal specifications are a language for specifying interfaces