On Formalism in Specifications= Bertrand Meyer, University Of california, santa Barbara A crilique of a natural ~ language specification, pecification is the software life· followed by presentation of a mathematical Scycle phase concerned wit h precise alternative, demonstrates definition of tile tasks to be performed the weakness of by the system. Allhough soflwarc ell­ gineering textbooks emphasize it s ne­ natural language I.:essi!y. the specification phase is often and the strength overlooked in practice. Or, m OTe pre­ of formalism cisely. it is confused with eit her the in requirements preceding phase. definition of system specifications. objectivC$, or Ihe following phase, de­ sign. tn the first case, considered here in particular. a natural-language re­ qllin>mellfs dOCllmen' is deemed suf+ licient !O proceed to system dcsign­ without further specification :Ictivity. This article emphasizes the draw­ backs of such an informal al>Droach and shows the usefu lness of formal specifications. To avoid possible mis­ undefstanding. however. let's clarify one point at the outset: We in no way advocate forlllal specifications as a replucement for natural-language re­ quirements; ralher. we view them as a cOlllplelllell( to natural-language de­ script ions and. as will be illustrated by an example. as an aid in improving the quality of natural-language spccifica- 110 m. Readers already convinced of the benefits of fOfma l s(X'Cificat ions might find in this article some useful argu­ Illent s to reinforce their viewpoinl. Readers not sharing Ihis view will, we hope, find some interesting ideas to ponder. The seven sins of the specifier The study of requirements docu­ menlS, as they arc routinely produced in industry, yields recurring patterns of 6 O7;tO.74}918510001 / 0006S01 ,00 198,S 1(::1::1'. IEEE SOFTWARE Requirements \ \ Specification \ Global :Ware \ -- DESIGN llfe cyde Detailed \ This "water- fall model" of the \ Implemen'ation \ software life cycle originated with W. w. deficiencies. Table I li sts sevcn classes Royce ("Managing the \ Validation of deficiencies that we have found 10 Development of Large Solt­ be both common and particularly ware Systems: Concepts and \ Techniques," Wescon Proc .. Aug. damaging to the quality of require­ Distribution 1970), but many variants have been \ ments. published. A well-known one is in \ The classilication is interesting for Boehm (1975). The IEEE Standard on Soft­ two reasons. First. by showing the pit­ ware Quality Assurance (Standard P732) also \LI_ope_"_,,o_n--l fall s of natural-language requirements defines a variant. documents, it gives some weight to the thesi5 that formal specificat ions arc needed as an intermediate step be­ tween requirements and design. Sec­ ond. since natural-language require­ ments arc necessary whether or nOl one accepts the thesis that they should Table L be complemented with formal specifi­ T hc sc\'cn ~ in \ of Iht' ~ P<'cificr . cations, it provides writers of such re­ quirements with a checklist o f CO Ill­ Noise: The presence in the tC'I; t of an element tlHl t does not mon mistakes. Writers of Illost kinds carry information relevant to any fealU rc of the of software documentation (user man­ I'roblem. Variants: redllndallcy; remorse. uals, rrogr;lmming language manuals, etc.) should find this li st useful; we'll Silem'e: T he existence of a fea ture of the problem that i~ demonstrate its use through an exalll­ not covered by any clement of the IC'l;1. ple that exhibit s all the defe<.:ts cxcert Overlpecijica/ion : Thc presence in the ICxt an clcment that cor­ the last one. or re,>po nds not 10 a feature of the I'roblem but to fea tures of a possi ble .. olution. A requirements document The reader is invited to st udy. 111 COl/fradiclion: The presence in the te'\ t of two or more clements li ght of the rrevious li st. some of the thm defi ne a feature of the system in an incompati­ soft wan: documentation available to ble way. him . We could do the same here and A mbiguilY: T he pre~e n c(' in the t(''I; t of an clement thaI !l1a ~ es it discuss actual requiremen ts docu­ pos5ible to interpret a feat ure of the problem in at ments, taken from indll ~ trial son ware lea~ t two different ways . projccts. as we did in a prcvious ver­ sion of this article. I But such a discus­ Forward reference: The p r c~e n cc in the text of an clcment that uses sion is not cntirely satisfactory; the fea tures of the I'roblem not defined until later in reader Illay fccl that the examples cho­ the text. scn are not representative. Also. one Wish/ ul/hinkin$;: The presencc in the text of an d emcnt that defines sometimes hears the remark that noth­ a feature o f the problcm in such a way that a can­ ing is inherently wrong with natural­ didate sol ution ca nnot rea lis tica ll y be val idated language specil'ications. All one has to wit h respect to this fea ture. do, the argument continues. is to be January 1985 7 Formalism careful when writing them or hire peo­ words of E. W. Dijkstra,2 "Tt"Sting Apparently somebody criticized the ple with good writing sk ills. Although ca n be a very effective way to show the initial version, since the last version well-written requirements arc obvious­ presence of bugs, but it is hopelessly contains the following footnote: inadequate for showing their absence." ly preferable to poorly written ones, Making these specifications precise is we doubt that they solve the problem. Thus, in the view of such critics, tes­ difficult and is an excellent example of In OUT vicw, natural-language descrip­ ting is futile; the only acceptable way the specification task. The specifications tions of any significant system, even 10 validate a program is to prove its here should be compared with those in ones of good quality, exhibit deficien­ correctness mathematically. OUT original paper. cies that make them unacceptable for Since Goodenough and Gerhart Thus, when we examine the final rigorous software development. were discussing lest data selection specification. it is only fair to consider To support this view, we have cho­ methods, they felt compelled to refute it nOl as an imperfcct document writ­ sen a single example, which, although this a priori objection to any research ten under the schedule constraints openly academic in nalUre. is especial­ on testing. They dealt wilh it by show­ usually imposed on software projects ly suitable because it was ex plicitly and ing significant errors in programs in industry, but as the second version carefully designed to be a ';good" whose "proofs" had been published. of a carefully lhought-out text, de­ natural-language spc(;ification. This Among the examples was Naur's pro­ scribing what is really a toy problem, example is the specificat ion of a well­ gram, in which they found seven er­ unplagued by any of the numerous known texl-processing problem. The rors-some minor, some serious. special considerations that often ob­ problem first appeared in a 1969 paper scure real-life problems. If a natural­ by Peter NauT where it was described language specification of a program­ as reproduced here in Figure I. Goodenough and Gerhart ming problem has ever been written Naur's paper was on a method for found seven errors-some with care, this is it. Yet, as we shall see, program construction and program it is nOl without its own shadows. proving; Ihus, the problem statement minor, some serious-in Figure 2 (sec p. I J) gives Good­ in Figure I was accompanied by a pro­ Naur's program. enough and Gerhart's final specifi­ gram and by a proof that the program cation, which should be read carefully indeed satislicd the requiremems. at this point. For the remainder of this The problem appeared again in a Our purpose here is not to enter the article, numbers in parentheses-for paper by Goodenough and Gerhart, testing-versus-proving cont roversy. example, (21)- refer to lines of text as which had two successive versions. The Naur-Goodenough/Gerhart prob­ numbered in Figure 2. Both versions included a crit icism of lem is interesting, however. because it Naur's original specificat ion . exhibits in a panicularly clear fashion Analysis of the speeification Goodenough and Gerhart's work some of the diflicuhies associated with The first thing one notices in look­ was on program testing. To explain natural-language speci fications. Good­ ing at Goodenough and Gerhart's wh y a paper on program testing in ­ enough and Gerhart mention thaI the specification is its lengt h: about four cluded a l: riticism of Naur's text, it is trouble with Naur's paper was partly times that of Naur's original by a sim­ necessary to review the methodologi­ due to inadequate specification; since ple character count. Clearly. the au­ cal dispute surrounding the very con­ their paper proposed a replacement for thors went to great pains to leave noth­ cept of testing. Some researchers dis­ Naur's program, they gave a corrected ing out and to eliminate a ll ambiguity. miss testing as a method for validating specification. This spedlication was As we shall sec, Ihis overzealous effort software because a 1t'S1 can cover only prepared with particular care and was actually introduced problems. In any a fraction of significant cases. In the changed as the paper was rewritten. case, such length seems inappropriate B tEEE SOFTWARE Rococo interior with fashionable pair dancing; engraving by Gravelol.