Formalism On

On Formalism in Specifications-

Bertrand Meyer, University ofCalifornia, Santa Barbara

A critique of anatural-language specification, pecification is the software life- followed by presentation of a mathematical Scyclephase concerned with precise alternative, demonstrates definition of the tasks to be performed the weakness of by the system. Althoughsoftware en- natural language gineering textbooks emphasize its ne-

A.-> *s4C. naturallanguage cessity, the specification phase is often and the strength overlooked in practice. Or, morepre- offormalism cisely, it is confused with either the in requirements preceding phase, definition of system

specifications. objectives,orthe following phase, de- sign. In the firstcase, considered here in particular, a natural-language re- quirements document is deemed suf- ficient to proceed tosystem design- without further specification activity.

This article emphasizes the draw- backs of such an informal approach and shows the usefulness of formal specifications. To avoid possible mis- understanding, however, let's clarify onepointatthe outset: Wein no way advocate formal specifications as a

replacement for natural-language re- quirements; rather,^weview themasa

complement to natural-language de- scriptionsand, as will be illustrated by anexample,as anaid inimprovingthe quality of natural-language specifica- tions.

Readers already convinced of the benefits offormalspecificationsmight find in this article some useful argu- ments to reinforce their viewpoint.

Readers notsharing this viewwill, ^we hope, find some interesting ideas to

ponder.

The sevensins of the specifier

The study of requirements ^docu-

- = °cS('1W - ments, as they areroutinely produced inindustry,yieldsrecurringpatternsof

0740-7459/85/0001/0006$01.00 ^- 1985 IEEE

6 ^IEEESOFTWARE

deficiencies. Table I listssevenclasses of deficiencies that we have found to be both common and particularly damaging to the quality of require- ments.

The classification is interesting for tworeasons.First, byshowingthepit- falls ofnatural-languagerequirements documents, itgivessomeweighttothe thesis that formal specifications are needed as an intermediate step be- tween requirements and design. Sec- ond, since natural-language require- ments are necessary whether or not oneacceptsthe thesisthatthey should becomplemented with formalspecifi- cations, it provideswriters of suchre- quirements with a checklist of com- mon mistakes. Writersof most kinds ofsoftwaredocumentation(userman- uals,programminglanguagemanuals, etc.) should find this list useful; we'll demonstrateits usethroughan exam- ple that exhibits all the defects except the last one.

Arequirements document

The reader is invited to study, in light of the previous list, some of the sof,ware documentation available to him. We could do the same hereand discuss actual requirements docu- ments, taken from industrial software projects, as we did in a previous ver- sion of this article. Butsuchadiscus- sion is not entirely satisfactory; the readermay feel thattheexamplescho- sen are not representative. Also, one sometimeshearsthe remarkthatnoth- ing is inherently wrong with natural- languagespecifications.All one hasto do, the argument continues, is to be

ThE@ so00ftff U War\--EIN---I'\

oigintedwth . W

Roye(Maaging000ff00;Ethe VaIld0000S005SSt0

Table 1.

The seven sins of thespecifier.

Noise:

Silence:

Otuerspecification:

Contradiction:

Ainhiguity.

Forwardreference:

Wishfiulthinking:

Thepresence in the text of an element thatdocsnot carry infornmation relevant to any feature of the problem. Variants: redundanc,v;remnorse.

The existence of a feature of the problem that is not covered byany element of the text.

The presence in the text of an element that cor- responds not to a feature of the problem but to features of a possible solution.

The presence in the text of two ormore elements thatdefineafeatureof thesysteminanincompati- ble way.

Thepresence in the text of an element that makes it possible to interpret afeature of'theproblem in at least twodiffterent ways.

The presence in the text of an element that uses features of the problem not defined until later in the text.

Thepresence in the text of an element that defines a feature of the problem in such away that a can- didate solution cannot realistically be validated with respect to this feature.

I

0

5,

Formal sm

careful whenwritingthemorhirepeo- ple withgoodwriting skills. Although well-writtenrequirementsareobvious- ly preferable to poorly written ones, wedoubt that they solve the problem.

In ourview,natural-languagedescrip- tions ofany significant system, even onesofgoodquality,exhibit deficien- cies that make themunacceptable for rigorous softwaredevelopment.

To supportthisview, wehavecho- senasingleexample,which,although openly academicin nature,is especial- lysuitable because itwasexplicitly and carefully designed to be a "good"

natural-language specification. This example is the specification of awell- known text-processing problem. The problem firstappeared in a 1969 paper by Peter Naur where itwasdescribed asreproduced here in Figure1.

Naur's paper was on a method for program construction and program proving; thus, theproblem statement inFigure 1 wasaccompaniedby a pro- gramand byaproof that the program indeedsatisfiedtherequirements.

The problem appeared again in a paper by Goodenough and Gerhart, which had two successive versions.

Both versions included acriticism of Naur'soriginal specification.

Goodenough and Gerhart's work was on program testing. To explain why a paper on program testing in- cluded acriticism of Naur's text, it is necessary to review the methodologi- cal dispute surroundingthevery con- cept oftesting. Some researchers dis- misstestingasamethod forvalidating software becausea testcancoveronly a fraction ofsignificant cases. In the

words of E. W. Dijkstra,2 "Testing canbeaveryeffectiveway toshow the presence of bugs, but it is hopelessly inadequate for showing their absence."

Thus, in the view of such critics, tes- ting is futile; the only acceptableway to validate a program is to prove its correctnessmathematically.

Since Goodenough and Gerhart were discussing test data selection methods,they felt compelledtorefute thisaprioriobjectiontoanyresearch ontesting. They dealtwith itbyshow- ing significant errors in programs whose "proofs" had been published.

AmongtheexampleswasNaur'spro- gram, in which they found seven er- rors-someminor,someserious.

Goodenough and Gerhart found seven errors-some minor, someserious-in

Naur's program.

Our purposehere isnot to enter the testing-versus-proving controversy.

The Naur-Goodenough/Gerhartprob- lemis interesting, however, because it exhibits in aparticularly clear fashion someof thedifficulties associated with natural-language specifications.Good- enough andGerhart mention that the trouble with Naur's paper was partly dueto inadequate specification; since theirpaperproposedareplacementfor Naur'sprogram,theygave a corrected specification. This specification was preparedwithparticular care and was changed as the paper was rewritten.

Apparently somebody criticized the initial version, since the last version contains the following footnote:

Making these specifications precise is difficultandisanexcellentexample of thespecificationtask.Thespecifications here should be compared withthose in ouroriginalpaper.

Thus, when we examine the final specification,it isonlyfairtoconsider itnotas animperfectdocumentwrit- ten under the schedule constraints usually imposed on softwareprojects inindustry, but asthe secondversion of a carefully thought-out text, de- scribingwhat isreallyatoyproblem, unplagued by any of the numerous special considerations that often ob- scure real-lifeproblems. Ifa natural- language specification ofa program- ming problem has ever been written withcare,thisisit.Yet,as weshall see, itisnotwithout itsownshadows.

Figure 2 (see p. 11) gives Good- enough and Gerhart's final specifi- cation,which should be readcarefully

atthispoint.For the remainder of this article, numbers in parentheses-for example, (21)-refertolines oftextas numbered inFigure2.

Analysis of thespecification

The first thingone noticesin look- ing at Goodenough and Gerhart's specification is its length: about four times that of Naur'soriginal byasim- ple character count. Clearly, the ^au- thorswenttogreatpainstoleave noth- ingoutandtoeliminate allambiguity.

As weshallsee,thisoverzealous effort actually introduced problems. In any case,suchlength seemsinappropriate

IEEESOFTWARE 8

Rococo interior withfashionablepairdancing:

engraving byGravelot, 1770.

The Bettmann Archive

forspecifyingaproblemthat,afterall, looksfairly simpletotheunprejudiced observer.

Before embarking on a more de- tailedanalysis of this text, we should emphasizethat theaim of the game is not to criticize this particular paper;

the official subject matter of Good- enough and Gerhart's work was test- ing, not specification, and the pre- scription period has expired anyway.

We take the paper as an example be- cause it provides a particularly com- pact basis for the study of common mistakes.

Noise."Noise" elementsareidenti- fied by solid underlines in Figure 2.

Noise is not necessarily abad thingin itself; infact, itcanplaythesamerole as comments inprograms. Often, how- ever, noise elements actually obscure the text. When firstencounteringsuch anelement, the reader thinks it brings new information, but upon closerex- amination, he realizes thatthe element only repeats known information in new terms. The reader must thus ask himself nonessential questions, which divertattentionfrom thetruly difficult aspects of the problem.

Here, afraction ofasecond is needed torealize thata"nonemptysequence"

of characters (8) is the same thing as

"one or more" characters (9). These twoexpressionsappearwithinaline of each other; theauthors' aimwas, pre- sumably, toavoidarepetition. One is indeed taught in elementary writing courses that repetitions should be avoided, and no doubt this is agood rule as far as literary writing is con-

Figure 1. Naur'soriginalstatementofawell-knowntext-processing problem.

Givena textconsistingofwordsseparatedby BLANKSorbyNL(newline) characters,convertit to aline-by-lineforminaccordancewiththefollowing rules:

(1) line breaks must be madeonlywhere thegiventexthasBLANKorNL;

(2)eachline isfilled asfar aspossible,aslongas (3)no line willcontainmore than MAXPOScharacters.

References on the Naur-Goodenough /Gerhart problem Original reference, Naur:

Peter Naur,"Programming by Action Clusters," BIT, Vol. 9, No. 3, 1969, pp.

250-258.

Firstversion, Goodenough and Gerhart:

John B. Goodenough and Susan Gerhart, "Towards a Theory of Test Data Selection," Proc. ThirdInt'lConf. ReliableSoftware, Los Angeles, 1975, pp.

493-510. Alsopublished in IEEE Trans.SoftwareEngineering, Vol.SE-I,No.2, June 1975, pp. 156-173.

Revisedversion, Goodenough and Gerhart:

JohnB. Goodenough and Susan Gerhart, "Towards a Theory of Test: Data Selection Criteria," in Current Trends inProgrammingMethodology, Vol. 2, Raymond T. Yeh, ed.,Prentice-Hall, Englewood Cliffs, N.J., 1977, pp. 44-79.

Another paper that uses the same problem as an example:

Glenford J. Myers, "A Controlled Experiment in Program Testing and Code Walkthroughs/Inspections," Comm. ACM, Vol. 21, No. 9, Sept. 1978, pp.

760-768.

Formalism

cerned. In atechnical document, how- ever, the rule to observe is exactly the opposite-namely, the same concept shouldalways be denoted by the same words, lest thereaderbeconfused.

An interesting variant of noise is remorse, a restriction to the descrip- tion of acertain specification element made not where the element is defined but whereit is used, as if thespecifier suddenly regretted his initial defini- tion. Anexample here is "the output text,ifany" (20). Up to this point, the specification freely used the notion of outputtext(12,17); nowhere was there anyhint that suchatextmight not ex- ist. If thereader wondered about this problem, the specification did not pro- vide an answer. Now, suddenly, when the discussion is focusing on some- thing else, the reader is "reminded"

that theremight benosuchthing as an output text, butnoprecise criterion is given as to when there is and when there isn't.

Another instance of remorse is the late definition of the "line" concept (24), to which wewill return. Wewill meet again the tendency to say too much, which generates noise, as a sourceof contradiction andambiguity.

Silence.Inspiteof all hisefforts,the specifieroftenleaves,along withover- documentedelements, undefinedfea- tures. Commonly, these features ^are fairlyobviousto acommunityof ap- plication specialists, whoare closeto theinitial customers, buttheywill be moreobscuretothoseoutside this cir- cle. An example is the concept of

"line," which isnotreally definedex-

ceptin aparenthetical bit ofremorse toward the end of thetext(24),where it is described asasequenceof characters

"between successive NLcharacters."

(Bythe way, are those characters part of theline?)

Aninteresting point here is the cul- turalbackground necessaryto under- stand this concept. InASCII-oriented environments, "New Line" isachar- acter;thus, people workingonASCII environments(DEC machines, forex- ample)willprobablyunderstandeasily the specification's basic hypothesis -namely, thatNLis treated as an or- dinary character uponinput but trig- gers a carriage return upon output.

These concepts areforeign, however, tosomebody workinginanEBCDIC environment, especially on IBM OS systems,onwhich files are made up of asequenceof "records"(correspond- ing, forexample, to lines), each made upofasequenceof characters.Aper- soncomingfromsuchanenvironment would not have written the above speci- fication and willprobablyhavetrouble understanding it.

Besides, thelatedefinition of line is plainly wrong. It applies onlytolines that areneitherat the verybeginning nor atthe veryend of thetext. Inboth these cases,aline isnot"betweensuc- cessive NL characters" but between thebeginningof the fileandanNL,or between an NL and the end of the file-that is, between an NL and an ET. Ifwe accept the authors' defini- tion,the first and lastlines of theout- put maybe ofarbitrarylength;infact, anoutputcontainingnoNLatallisac-

ceptableregardless ofitslength, since

it does not havelines accordingtothe definitiongiven! This is obviously ab- surd and not whatthe authorshad in mind, but the use ofnatural language leadsnaturally to suchslips of the pen.

Anotherinteresting silence concerns thevariable Alarm. Line 16 specifies that this variable should be set to TRUEin case of an error, butnothing is said about what happens to it in other cases. Theanswerisobvious,of course; but the matter can only be brushed aside as minor by program- mers who have never run into a bug dueto anuninitialized variable. ^{. .}

It must be pointed out that Good- enough and Gerhart corrected a nota- ble silence in Naur'soriginal descrip- tion. Naur'stextdoesnotexplain what should be done with consecutive groups ofmorethanonebreak character; this is oneof the seven errorsanalyzed in Goodenough and Gerhart's paper.

Their specification corrects it by re- quiringthat such groups be reduced to asinglebreakcharacter in the output.

Although something had to be done abouttheproblem,notethatthissolu- tionis, ^tosomeextent,obtainedatthe expense ofsimplicity. Eliminatingre- dundant break characters anddividing a textinto linesare twounrelated prob- lems; merging them into a single specifi- cationcomplicatesthe wholeaffair.

It is probably better to deal with thesetworequirementsseparately,and this is what we do in the formal specificationgivenbelow.Someof the currenttrends inprogramming meth- odology emphasize this approach- most notably under the influence of the Unix programming environment,

IEEESOFTWARE 10

Ball at the homeofaGermanbaron;

engraving circa 1750.

TheBettmann Archive

which, at least in principle, favors tools that are simpleand composable rather thanlargeand multipurpose.

Contradictions. There is another problem with the concept of line.

Given atype t, oneshoulddistinguish between the types seq[tJ, whose ele- ments arefinitesequences of objectsof type t, and seq [seq [t]], whose ele- ments are sequences of sequences of objectsoftype t. Suchaconfusioncan befound inFigure 2, wherewearefirst told(I) that the input isa"stream,"or sequence, of characters and later (10) thatit "canbeviewed" asa sequence of wordsandbreaks. AsanyLisppro- grammer knows, the sequences

<a b acca>

[sequence of objects]

and

< <a> <ba> <cca> >

[sequence ofsequences ofobjects]

are not thesame. Note that thesame problem with respect to the output is redeemed onlybyambiguity; the type of theoutputisnot clear:

* Is itseq[CHAR] as(21-22)seems toimply?

* Is it seq [WORD]-that is, seq [seq [CHAR]]-as (12-13) in- dicates?

* Or is it evenseq[LINE] -that is, seq[seq[seq[CHAR]]]-ifwe con- sider alineas asequence of words andbreaks?

Thus,asentencethatatfirstappears to be only noise (9-11) yields a con- tradiction within a few lines (13-14):

"Theprogram's output shouldbethe same sequence of words as in the in-

Figure2.Goodenough andGerhart'sfinal specificationoftheoriginal prob- lemstatementinFigure 1.Analysisof thistext,overprinted inblue,isaccord- ingto thefollowing key:

Noise Ambiguity

Remorse Overspecification

Contradiction Forward reference

1 The program's input is a stream of characters whose end is 2 signaled withaspecialend-of-text character, ET. Thereisexactly 3 one ETcharacterin each input stream. Characters are classified

4 as

5 * breakcharacters-BL (blank)and NL (new line);

6 * nonbreakcharacters-all others except ET;

7 *theend-of-text indicator-ET.

8 A word is a nonempty sequence of nonbreak characters. A 9 break is a sequenceof one ormore break characters. Thus, the 10 inputcanbeviewedasasequence of wordsseparated bybreaks, 11 with possibly leading and trailing breaks, and ending with ET.

12 Theprogram's output should be the samesequenceof words 13 as in the input, with the exception that an oversize word (i.e., a 14 wordcontaining more than MAXPOScharacters, where MAXPOS 15 is^apositive integer) should cause an error exit from the program 16 (i.e., avariable, Alarm, should have the value TRUE). Up to the 17 pointofanerror,theprogram's output should have thefollowing 18 properties:

19 1.Anew line should start only between words andat the be- 20 ginning of theoutput text, if any.

21 2.Abreakinthe input isreducedto asingle breakcharacter in 22 intheoutput.

23 3.As many words as possible should be placed on each line 24 (i.e., between successiveNLcharacters).

25 4. No line may contain more than MAXPOScharacters (words

26 and BLs).

Formalism

put." Thislast comment is remarkable since neither the input nor the output is a sequence of words. Worse yet, even ifwe parse the input into a se- quence of words, this sequence is not sufficient to determine the output one also needs two binary informa- tions: whether there is a leading and/or atrailing break.

The same sentence (9-11), in its overzealous effort to leave no stone unturned,ends up introducing another contradiction. An unbiased reader would bepuzzled. How can the input

"end with [the character] ET" (11) andat thesametime havea "trailing break" (11)? "Trailing," precisely, means "at the end"! What's the last character ifthere isa"trailing" break:

ET orabreakcharacter?

Amoreexperiencedreader, such as aprogrammer, will havenodifficulty resolving this contradiction; his experi- encewilltellhimthat "end" markers follow "trailing" characters. Butthis reliance onintuition and knowledge of the application domain can be par- ticularly damaging when transposed to large requirements documents, which will be handed down to a group of systemdesignersandimplementorsof diversebackgrounds and abilities.

Overspecification. Overspecifica- tion inrequirementscanbeannoyingly closetosilence. The reader is told too much about the solution while he is desperately tryingtograsp theproblem and figureout-by himself-features notcoveredby the text.Overspecifica- tion istypically,although certainlynot exclusively, found in requirements 12

documents written by programmers.

Psychologically, this is understand- able. Animplementation-levelconcept is good, concrete, technical stuff, whereas true requirements deal with muchlesstangible material.To acom- puter specialist, a stack is easier to visualize than, say, the flow of infor- mation in a company or the needs of a radaroperator. Thus, many specifiers have anatural tendencytocling to pro- gramming concepts. There isaprice to payforthis:Implementationdecisions taken too early may turn out to be wrong, and important problem fea- turescan beoverlooked.

The example textcontains an over- specification right from the first sentence:the notion of the end-of-text characterET.Theonlyreasonfor the presenceofthis notion is Goodenough andGerhart's desiretocorrect Naur's originalprogram. Input-output facili- ties of the versionofAlgol 60 used by Naur (and, for fairness, by Good- enough and Gerhart) do not provide forend-of-file detectionwhenreading, so one must assumethepresence ofa special characterattheend of the file tomake upfor thisdeficiency. But ET is animplementation detail and should notbe included inanabstractspecifi- cation.Conceptually, the input is a fi- nite sequence of characters; it should betransformed intoanoutput thatisa sequenceof lines or,dependingonthe interpretation chosen, a sequence of characters.Itisaprogrammer'sviceto insist that finite sequences bespecially markedatthe end.

Why does theETcharacter receive such emphasis in Goodenough and

Gerhart'sspecification? Thereasonis one of the errors in Naur's original program,which would go into an in- finite loop unless the inputwasincor- rect (that is, contained an oversize word).Upon closerexamination, how- ever, a case can be made for Naur's solution(without the other errors, of course). Itisnot sounrealistictocon- sider therequiredprogramas apoten- tially infinite process, which takes charactersasinputandproduceslines as output, working somewhat like a device handler (for instance one that drives a printer) in an operating sys- tem.Suchaninterpretation should,of course, be clearly described in the specification, which was not thecase withNaur's text. Thatdecisionwould belessarbitrarythantheonetakenby Goodenough and Gerhart: their inclu- sion of ETchanges the datastructure at the specification level to accom- modate the programming language usedattheimplementationstage.

Theunacceptabilityof thechangeis further evidenced by the fact that the output does not satisfy the require- ment ontheinput.Isitrealistictoex- pectanexistingfiletobeterminatedby anexplicitmarker? If itis,theoutput producedby the program should satis- fythat condition; however, examina- tion of thespecification, which is not

completely clear on this matter, and, as a final criterion, of the proposed program, shows that ET will not be passed on to the output file. Assume that we want to write another pro- gram, for, say, right-justifying the text, that will take Goodenough and Gerhart's output(in"pipe"mode'ala

IEEESOFTWARE

Unix). Indesigning that program, we will not be able to make the same assumption on its input. Thus, the overspecification has opened the way toseriousinconsistencies.

Another overspecification in the textis theconceptof"errorexit"(16), which causes a "variable," Alarm, to have thevalueTRUE.Clearly,theno- tionofavariablebelongstothe world ofprograms, not specifications. This pieceofoverspecification would have been lessshockingif theproblem had been defined as the task ofwriting a procedure, with Alarm as one of its parameters, or as one of the "excep- tions" (in the sense ofClu orAda) it might raise. A variable is internal to the program unit towhich itbelongs, whereas thespecification ofaparam- eter oranexceptioncanbegivenrela- tivetothe environment of that unit.

Theproblem of the Alarm variable is less innocuous than it seems. One reason forshock at meeting the refer- ence to this variable in a sequential reading of thetextisthat thedefinition of theerrorcase(the one inwhichthere is an oversize word) looks like over- specification untilone seesthe lastsen- tence (25-26), 10 lines down, which gives the basic line-size constraint, MAXPOS. The world is really stand- ing upside down here. Clearly, the constraint on word size is a conse- quence of the constraint on line size, and the definition of the error case cannot be understood until the latter constraint has been introduced.

We seehere one of the major defi- ciencies plaguing requirements docu- ments of more significant size: early

I ^{1 2 3 4 5 6 7 8 9 10}

1 U N I X I S A

2 T R A D E M A R K

3 0 F B E L L

4 L A B 0 R A T 0 R I E S

11 ^{1 2 3 4 5 6 7 8 9 10}

Figure3. Output requirement (MAXPOS = 10).

inclusion of detaileddescriptions of er- rorhandling,interwoven with descrip- tions ofnormal cases,whichareusual- ly much simpler. Here the matter is even worse; error processing is de- scribed before the reader has had a chancetorecognize theproblem-that is,before gaining anunderstanding of normal processing. Failure to clearly separatenormal cases from erroneous ones makes thedocument much harder tounderstand.

Mathematically, a program that performsaninput-to-outputtransfor- mation often corresponds to the im- plementation of a partial function, which is not defined for some argu- ments of the input domain. Error pro-

cessing thenconsists in "completing"

the function with alternate results, such as error messages, for those arguments. This completion should notbe confused with thedefinition of thefunction in its normalcases.Here, aswe'llseelaterina formal specifica- tion, failure to accommodate words larger than MAXPOS is a conse- quenceof therequirements for normal processing, which can be proved, as a theorem, from the definition of the function.

Ambiguities.Errorprocessingraises anambiguityintheexampletext(Fig- ure 3). The requirement that the out- puttextsatisfypropertiesIto 4"upto