This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: On Formalism in Specifications- BertrandMeyer, University of California, SantaBarbara A critiqueofa natural-language specification, pecificationisthesoftwarelife- followedbypresentationofamathematical Scycle phaseconcernedwithprecise alternative,demonstrates definition ofthetaskstobeperformed theweaknessof bythe system.Althoughsoftwareen- naturallanguage gineering textbooks emphasize its ne- A .-> *s4C. naturallanguage cessity,thespecificationphaseisoften andthe strength overlooked in practice. Or, more pre- offormalism cisely,itis confused witheitherthe in requirements precedingphase,definitionofsystem specifications. objectives, or thefollowingphase,de- sign.Inthefirstcase, consideredhere in particular, a natural-language re- quirementsdocument isdeemed suf- ficienttoproceedtosystemdesign- withoutfurther specificationactivity. This articleemphasizes the draw- backsofsuchan informalapproach and shows theusefulness of formal specifications. To avoid possiblemis- understanding, however, let'sclarify onepointattheoutset:We innoway advocate formal specifications as a replacementfornatural-language re- quirements; rather, we viewthemasa complement to natural-language de- scriptionsand,aswillbeillustratedby an example, asanaidin improving the qualityofnatural-languagespecifica- tions. Readers already convinced of the benefitsofformalspecificationsmight findinthisarticle some useful argu- ments to reinforce their viewpoint. Readersnot sharingthisviewwill, we hope, find some interesting ideasto ponder. Theseven sins ofthe specifier The study of requirements docu-- = ° cS('1W- ments,astheyareroutinelyproduced in industry,yieldsrecurringpatterns of 0740-7459/85/0001/0006$01.00- 1985 IEEE 6 IEEESOFTWARE deficiencies.Table Ilistssevenclasses ofdeficienciesthatwe havefoundto be both common and particularly damaging to the qualityof require- ments. The classificationis interestingfor tworeasons. First,byshowingthepit- fallsof natural-languagerequirements documents,it gives some weighttothe thesis that formal specificationsare needed as an intermediate step be- tween requirementsand design.Sec- ond, since natural-language require- ments are necessary whether or not oneacceptsthethesisthattheyshould becomplementedwithformal specifi- cations,itprovideswritersofsuchre- quirements with a checklistofcom- mon mistakes.Writersofmost kinds ofsoftwaredocumentation(userman- uals, programminglanguagemanuals, etc.)shouldfindthislistuseful;we'll demonstrateitsusethroughanexam- plethatexhibitsallthedefectsexcept thelastone. Arequirementsdocument The reader isinvited tostudy, in lightofthepreviouslist,someofthe sof,ware documentation availableto him.We coulddothesamehereand discuss actual requirements docu- ments,takenfromindustrialsoftware projects,aswedidinapreviousver- sionofthisarticle. Butsuchadiscus- sionisnot entirelysatisfactory; the readermayfeelthattheexamplescho- senarenotrepresentative.Also,one sometimeshearstheremarkthatnoth- ingisinherentlywrong withnatural- languagespecifications.Allonehastolanguagespecifications....
View Full Document
This note was uploaded on 01/09/2012 for the course EMP EMP5117 taught by Professor Bohehm during the Fall '11 term at University of Ottawa.
- Fall '11