RequirementsEngineering Lectura Tecnica

7/30/2019 RequirementsEngineering Lectura Tecnica

1/5

We now betterunderstand how to writerelatively unambiguous,

complete, consistentrequirements. But we

generally dont. Why isthere such a wide gapbetween the state of

the art and the state ofthe practice?

PE1HSlAUniversityof Texas at Arlington

ALAN DAVISUniversityof Colorado

at C olorado SpringsDAVID KUNGUniversityof Texas at Arlington

n the early 1970s, research-Irs began thinking abouthow to s olicit, collect, analyze,and formally specify systemand software requirements.Twenty years later, althoughwe have improved our under-standing of how to w rite rela-tively unam biguous,complete,and consistent requirements,we gen erally dont.For the m ost part, the stateof the practice is that require-ments engineering producesone large document, w ritten ina natural language, that fewpeople bother to read. Projectsthat do read and follow thedocument often build systemsthat d o not satisfy needs. Wh atare we doing wrong? Wh y isthere such a wide gap betweenthe state of the art and the stateof the practice?CRUCIAL PROCESS STEP

Th e quality of a softwareproduct is only as good as theprocess that creates it. Re-quirem ents engineering is oneof the m ost crucial steps in thlscreation process. Without awell-writ ten requirementsspecification, developers don o t k n o w w h a t t o b u i l d ,customers do not know whatto expect, and there is no way

to validate that the system asbuilt satisfies the require-ments.Requirements engineeringis the disciplined applicationofproven principles, methods,tools, and notations to de-scribe a prop osed systems in-tended behavior and its associ-ated constraints.It includes allactivities relating to the+ identification and docu-mentation of customer anduser needs,+creation of a documentthat describes the external be-havior and the associated con-straints that will satisfy thoseneeds,+analysis and validation ofthe requirements document toensure consistency, complete-ness, and feasibility,and+ evolution of needs.T he primary output of re-quirements engineering is arequirements specification. Ifit describes both h ardwa re andsoftware , t isa system require-ments specification. If it de-scribes only software, it is asoftware requireme nts specifi-cation. In either case, a re-quireme nts specification mu stweat the system as a black box.It must delineate inputs, out-puts, the functional require-ments that show external be-h av i o r i n t e rms o f i n p u t ,output, and their relationships,and nonfunctional require-

REQUIREMENTSments and their constraints,including performance, porta-bility, and reliability.T h e software requirementsspecification should be inter-nally consistent; consistentwith existing documen ts; cor-rect and com plete with respectto satisfymg needs; under-standable to users, customers,designers, and testers; and ca-pable of serving as a basis forboth design and test.STATEOF THE PRACTICE

Most software-develop-men t o rg an i za ti o n s ag reethere should be a s et of activi-ties called requirements engi-neering and that their successis vital to the success of the en-tire project.So why is the state of thepractice no better than it is?Th ere are several reasons, notall of them obvious:+ Reguimnents alp dzficultto u~zcoue~:oday we are auto-mating virtually every kmd oftask - ome that were for-mer ly done manual ly andsome that have never beendone before. In either kind ofapplication, it is difficult if n otimpossible o uncover require-ments, regardless of the tech-niques you use. No one cansee a brand new system in its

I E E E S O F T W A R E 07407459/93/1100/0075/$03 00D IEEE 7 5


2/5

entirety. Even if someonecould, the description is alwaysincomplete at the start. Usersand developers must resort totrial and error to identify prob-lems and solutions.+Require-

1980s,many requirements en-gineers embraced structuredanalysis. But this technique,whch describes interactionsthat occur in the real world oram ong software components,does not let you

ments change.Because no userc a n c o m e u pwith a completelist of require-m e n t s a t t h eoutset, the re-quirements getad d ed an dchanged as th e

v isual ize theoverall systemsbehavior dy-R W J M M S namicallv andBECAUSEARE FLUID, IT tends to fead toIS HARD TO Premature de-sign.N o w m a nyprojects are em-bracing object-ESTABLISHuser begins tounderstand the system and hisor her real needs. Tha t is whywe always have requirementschanges. But , the p ro jectschedule is seldom adjusted toreflect these modifications.Fluid requirements make itdifficult to establish a baselinefrom which to design and test.Finally, it is hard to justifyspending resources to make arequirements specificationperfect,because it will soonchange anyway. T h s is thebiggest problem facing re-quirements engineering, andthere is asyet no technology oovercome it. T h s characteris-tic is often used as an excuse toeither eliminate or scale backrequirements-engineering ef-fort.+Some method being usedare inappropriate. In their per-sistent quest for a silver bullet,engineers and managers arerepeatedly drawn toward pop-ular b ut inappropriate tech-niques. In the 1970s and early

oriented tech-niques. Although object-ori-ented techniques are practicaland effective for design andcodmg, it is not clear what theycan do for requirements engi-neering. Object-oriente d anal-ysis is an effective way to d e-scribe entities in the real w orldand their interactions, but ithas yet to be demonstrated aseffective for documenting asystems external behavior as ablack box.+There is over-reliance onCASE tools. Computer-aidedsoftware-engineering ools areoften sold as panaceas. Theseexaggerated claims have cre-ated a false sense of trust,which could infl ict untolddamage on the software ndus-try. CASE tools are as impor-tant to developers (includingrequirem ents writers) as wordprocessors are to authors.However, you must no t rely onrequi rements-eng ineer ingtools withou tfirst understand-ing and establishing require-ments-engineering principles,t ech n i q u es , an d p ro cess .Futhermore you must haverealistic expectations of thetools. T he difference between

word processors and CASEtools is that the former are notsold as tools that wdl changehow well you write.+ Training is insuficient.Mos t software engineers knowonly a f ewrequirements-engi-neering notations, techniques,and tools. Only a fraction ofthem have received the propermining to apply these to real-world proble ms. Additionally,very few software engineersare trained in the applicationdomain. Hence, it is difficultfor them to perform require-ments engineering on a spe-cific project. As a result, re-q u i r e m e n t s - e n g i n e e r i n gnotations, techniques, andtools are often misused, crest-ing the impression that re-quirem ents engineering is nei-ther useful nor effective andreducing confidence in the re -sults of requirements-engi-neering research. Effective re-q u i r emen t s en g i n ee r i n gmeans that you must knowmany no tat ions and tech-niques. Unfortunately, todaymost trainingemphasizes spe-cific ones, and thus com muni-ca t es k n o w-h o w wi t h o u tteaching know-when. This islike instru cting carpenters inhow to use a drill press and tell-ing them they can build anypiece of furniturewith it.+Prpject schedule is alwaysunrealktizlly tight. Because ofeithe r lack of planning o r un-reasonable customer dem and,many projects start with insuf-ficient time to do a decent job.Sometimes, even the allocatedtime is reduced while the proj-ect is underway. It is also

customary to reduce the timeset apart to analyze require-ments, to get started designingand codmg, which kequentlyleads to disaster.+Developen lack c m j h ein requirements engineering.Ma ny large projec ts have failedin spite of using modern re-quirements-engineering tech-niques. Cu rrently, there is noco n v i n c in g ev i d en ce t h a tmodern requirements engi-neering mproves productivityand quality, although the goalof understanding user needsearly is obviously a worthyone.+Communication barriersseparate helopenandmen.Re-quirements engineering iscommunication-intensive.Users and developers have dif-ferent vocabularies, profes-sional backgrounds, and tastes.Developers usually want moreprecise specifications; usersprefer natural language. Se-lecting either results inmisun-derstandmg and confusion. Apartial solution is to use form almodels to augment, not re-place, natural language.

STATEOF RESEARCHO n the basis of our investi-gation, we found the followingresearch areas to have signifi-cant payoff potential. T h e rel-ative time-fi-ame du ring wh chwe expect them to have majoreffect on practice ranges fromshort to long term.Improving natural-language

all research in requirementsengineering today deals withthe intro duction of more for-mality into the process. Th ereis a large gap between the sta teof the practice (informal natu -ral language) and the state of

spedficcllkns (short-tenn). Almost

7 6 N O V E M B E R 1993


3/5

the research (formal models).More research must be doneto provide natural-languagewriters with insight into howthey can improve their docu-ments without formal models.Although user needs truly aredifficult to d eterm ine, we stillneed guidmg principles to re-duce the ambiguity nherent ina natural-language documentwhen it is written.Rober t Balzer has suc-ceeded in removing someshortcomings by experiment-ing with partial translationko m English nto more formalmodels. Barry Boehm andAlan Davis and colleagues3h av e i d en t i f i ed t h e a t t r i -b u t e s t h a t a requirementswriting team should look forwhen they reviewa natural-Ian-p a g e specification. Pei Hsiaand colleagues have pionee redscenario-based analysis: w h c hcan augment both natural-and form al-language specifi-cations.

Rapid prototyping and require-ments animation (short-term). Inthe context of requirementsengineering, prototyping isthe c onstruction of an execut-able system model to enhanceunderstanding of the problemand identify appropriate andfeasible e xternal behav iors forpossible solutions. Prototyp-ing is an effective tool to re-duce risk on software projectsby early focus on feasibilityanalysis, identification of realrequirements, and eliminationof unnecessary equ irements.The most popular proto-typing approaches are thethrowaway approach and theev o l u t i o n ary ap p ro ach .Throwaway prototypes areconstructed relatively quickly

and inexpensively and are dis-carded afterward. T he advan-tage of t h ~ s pproach is rapidfeedback. Evolutionary proto-types are constructed in a qual-ity mann er and are evolved it-eratively into a productionsystem. T he advantage of thisapproac h is that noth ing is dis-carded.As L u q i a n d W i n s t o nRoyce have pointed out, thehighest payoff will come k omresearch improving+ languages for rapid pro-totype generation,+ reuse capability o makeprototype generation from re-usable components more fea-sible, and+ tools that ge nerate userinterfaces.Rapid prototyping of soft-ware systems includes func-tional, user-interface, and per-formance aspects. Functionalprototyping is usually ac-complished by executablespecifications, which can beautomatically translated intoexecutable prototypes. User-interface prototypin g s usuallyaccomplished by computer-aided tools that capture he in-tended human-machme inter-action and generate code thatimplements such interactions.Performance prototyping isoften accomplished by ana-lytic, probabilistic,and/or sim-ulation models that predict adesigns performance and itsimplementation alternatives.To improve its technologytransfer, rapid prototypingmust be assisted by tools forrequirements analysis, designand prototype gene ration. Al-though some exper imentshave shown its feasibility, a

I E E E S O F T W A R E

great deal of research and de-velopment remain before thlstechnology realizes its full po-tential.Requirements clustering (mid-term). Requirements clusteringfor increme ntalsoftwaredeliv-ery ha s shown promise? Itclusters related requirementsto form the subsystems that ex-hibit certain desired proper-ties. For exam ple, if you wantto decomposea system into in-dependent subsystems, youmu st identify all the basic andessential requirements hat arevital to all subsystems beforeyou can partition the re st of therequirements. f the purpose is

to deliver software sy stems likehighways, one segment a t atime, then you must establishproper criteria for clusteringsets ofrequirements o supportsuch subsys-tems. Require-ments clusteringis used to defineseparately deliv-erab le incre-ments.Case studieshave demon-strated the feasi-bility of require-ments clusteringi n b o t h t h estructured andobject-oriented

the ability to gene rate system-test plans from a requirementsspecification. Faced with anNP-hard problem, only heu-ristic approaches work. M anyresearch ef for t s have at -tempted to address h s , bu tnone have proved viable inproduct ion env i ronments .Perhaps one reason is thattodays specifications arentformal enough.The second challenge isour inability to monitor howwell requirem ents are coveredduring system test. T he indus-try has many code-coverageanalyzers but non e for require -ments coverage.The h r d challenge is todevelop tools that automati-cally m aintain trac eability ma-trixes that map requirementsto tests. Numerous commer-cially available tools help youmaintain suchtraces, but nonecan or will beWE NEED able to do thlsGUIDANCE automatically,a n d n o n e ofON HOW TO them are hk edWRITE AN to programsthatU N A M B W S t:yire-NATURAL- A recent de-

LANGUAGE v e l o p men t i nscenario-basedDOCUMENT. p r o o y p i n gparadigms. Fur-ther studies in requirementsclustering should take intoconsideration how to deal withrequirements change and howto incorporate such changeinto already defined incre-ments.

Requirements-based testing(mid-term). Th i s a r ea p o sesmany challenges. T he first is

suggests hat ani n t e r m e d i a t eform may be used to solvethese problems. Because sce-narios are the end users per-spective of a system: they canalso serve as a basis for accep -tance testing. An intermediateform alleviates the traceabilityproblem by having the usersidentify links between scena r-ios and requirements, andsolves the test-planning pro b-lem by using scenarios as test

77


4/5

templates for requirements.More study needs to be doneto substantiate hese promises.Computer-clided requirements

engineering (mid-term). M a n ygraphical ed i to rs are nowavailable unde r the CA SE um-brella, most of which supp ort asmall set ofrequire men ts ota-tions. Those that do supportmultiple nota-t ions p rov idel i t t le consis-tency checkingo r a u t o m a t i ctranslation be-t ween n o t a -tions. Also withfew exceptions,CASE tools arebased primarilyon dataflow dia-grams, one ofthe most infor-mal (and thusleast effective)notations avail-able. More re-

what makes them reusable,how can we stor e and retrievethem, and how do we write arequirements specificationthat givesus the highest prob-ability of creating or reusingexistingrequirements compo-nents?T he most significant workthus Edl. in requirements reusecame out of the 1993 IEEE In-t e r n a t i o n a lSymposium onTHE $(OPE Req u i r emen t sOF FORMAL E n g i n e e r i n g( t h e p ro ceed -METHODS ings are avail-

BROADENED, At the sympo-AND THEY s i u m, Al i s t e rSutcl i f fe andSHOULD BE N e i l M a i d e nWE MORE described howto retrieve re-P R A C M L q u i r e m e n sANDUSER- based on do-main knowl-FRlENDLX edge, and Kevin

SHOULD BE $k&Fr:L:

search is neededto find CASEtechnology that can supportmultiple sets ofno tations,con-sistency checking across multi-ple notations, and automatictranslation between them.T h e major advances inCASE technology during thelast few years have been in thequality of the user interfaceand the addition of new nota-tions with syntax-sensitiveedi-tors. The May 1990, March1992, and May 1992 issues ofIEEE Sqibare provide excel-lent coverage of the state of theresearch in CASE technology.Requiements reuse (mid-term).Mu ch research is underway indesign and code reuse. Moreresearch is needed on the ad-vantages and the necessarymethods for requirementsreuse. For example, what arerequirements components, .:

Ryan and BrianM at h ews d e -scribed how to use conceptualgraphs to retrieve similar con-cepts.Research into methods (mid-

term). We need controlled ex-perimen ts with systematic datacollection to dem onstrate thatmethods work. We believethat complex system develop-men t probably requires severalrequirements-engineeringmethods. To make this mean-ingful, we need a taxonomy ofrequirements notations thathighlights the similarities anddifferences among them. Spe-cifically, we must understandprecisely how diverse nota-tions overlap semantically,

whichwillmake it easier to doconsisten cy checking across,and translation amo ng, them.Knowledge engneerhg (long-

term). Requirements engineer-ing is a knowledge-intensiveprocess. Knowledge that isuseful in requirements engi-n ee r i n g i n c l u d es g en era lknowledge of requirementsanalysis and specification aswell as application-specific,model-specific, and process-specific knowledge.Knowledge-based require-ments engineering is con-cerned with applying knowl-edge-based techniques to theproblems of identifjm g,speci-fymg, verifjm g, and validatingsof tware requ i rem ents fo rlarge, complex systems. Re-search challenges in h s reainclude the acquisition, repre-sentation, and manipulation ofknowledge about all of theabove.In domain modeling, re-quirements engineering hasrecently begun dealing withthe use of domain-specificknowledge to derive or vali-date requirements specifica-tions. Research into automat-i n g t h e acq u i s i t i o n o fcust om ed requirements alsolooks promising. Automatedtranslation of informal, natu-ral-language specificationsinto more rigorous, formalspecifications has m ade som eearly progress.

Formal methods (long-term).Research in formal methodsand their associated formalreasoning c apabilities has po-tential for a long-term effecton requirements engineering.In many engineering fields,mathematical models and de-clarative languages are used in

7 8

the requirements and designphases. Formal m ethods havea sound mathematical basis,often given by a form al specifi-cation language.The potential advantagesof using a formal method in-clude+ promoting a deeper un-derstanding of the functional-ity and behavior of complexsystems,+ p ro mo t i n g accu ra t e ,precise, and unambiguous re-quirem ents specifications;+allowing rigorous analy-sis of system, specification, andimplementation properties,such as consistency, complete-ness, realizability, and co rrect-ness; and+ a l l o wi n g co mp u t e r -aided manipulation.T h e most well-known for-mal methods are Spec, Z , Vi-enna D efinition Me thod, andLarch. L k e all formal meth-ods, these systems have asound mathematical basis.They have been applied tospecifications of medium-sized, nontrivial problems, es-pecially the fun ctional behav-io r of sequential programs,abstract data types, and hard-ware?Curren t research on formalmethods has focused mainlyon developing formal specifi-cation languages for represen-tation. Manipulation is oftenn eg l ec t ed. Lo n g - t e rm r e-search goals n formal metho dsshould include developingpractically applicable reason-ing m ethods, expanding theirscope and scale of applicationto more complex systems, andfinding the means to maketheir representations moreuser-friendly. As pointed outby Jeane tte Wing , the chal-

N O V E M B E R 1 9 9 3


5/5

lenges for formal methods in-clude+specifying nonfunc tionalrequirements such as reliabil-ity, safety, critical timing c on-s t rain ts , performance andhuman factors;+ co mb i n i n g d i f f e r en tmethods, such as a domain-specific method with a do-main-independent method, o ran informal method with a for-mal method;+ building more usableand more reliable tools to ef-fectively and efficientlym anip-da te and analyze formal spec-ifications;+ building reusable speci-fication libraries to increasethe productivity and quality offormal methods;+ i n t eg ra t i n g fo rmalmethods with the entire soft-ware-developmentprocess;+demonstrating that ex-isting techtuques scale up tohandle real-world problemsand scaling up the te ch qu esthemselves; and+ training more people inthe use of formal methods.A unified framework (long-term). Curren t ly no fo rmalfoundation or m odel for non-

functional requirements hasbeen found. Hence, problemsin functional equireme nts andnonfunctional requirementshave to be dealt with sepa-rately.How ever, piecemeal so-lutions do n ot necessarily workwell overall. Therefore, wemust establish a unified fram e-work to integrate require-ments-engineering principlesand concepts and to avoidfragmentation.

esearch in improvingRnatural-language specifi-cation, and rapid prototypingshould provide quick resultsand be readily transferable.However, research in knowl-edge engineering and formalmethods requires longer termcommitments and substantialeffort to bring about practicalresults- nd they may not bereadily transferable o practice.We m ust learn from experi-ence that technology transferin requirem ents engineering isexceptionally slow. Two ave-nues may be the best routes tosuccessful tec hnology transfer:Incvemental changes in tech-niques, whc h provide graduali m p r o v e m e n t a n d radicalchanges in tech que s, w hchimply revolution and thus re-quire significant evidence ofwor th, utility, and applicabilitybecause the r i sk i s muchhgher. T he requirements-en-gineering community has yetto be exposed to the latter case,in its short 2 5-year life. +Pei Hsia is aprofesqor ofcomputer-aci-e nc e c n gneermg at theUniversity ofTexas at k-hngron,andan associateeditor-rn-

chief of IEEE Sojhume.His research in-terests include requirements engineer-ing, software-developmentparadigms,rapid protogping, languages,an d co n -putation complexity.science from the U niversity ofTexas atAustin. I Ie is a memhcr of the A C U ,Sigma Xi, Scienafic Research Society,and Phi Beta Delta I Ionor Society forInternational S cholars, and a seniormember of the IEEE.Engineering Dept., Umve nity of Texas,PO Bo x 190li,.Arhngton,TX76019-00 15; CSnet hsia~evax.ar l .utexas .edu.

Hsia received a PhD in computer

His address is Computer Science

ACKNOWLEDGMENTSThis report was developed out ofworkshops in 1991 and 1992 whose partici-pants were members of the IEEE S0f)Wai-e editorial and industry advisory boards.Th e requireme nts-engineering subgroup included the authors plus Art Hersh,Software Producnvity Consortium ; Gunter Koch, 2i Consult; and Shari Pfleeger,City University of London.REFERENCES1. R. Baker, et al., Informality n Program ,EEE Tra7u.SoJham Eng.,Mar.

2. B. B oeh m, Verierifyingand Validating Software Requireme nts and Design3. A Davis et al., Identifiing and Measuring Quality in Sofnvare Require-

1978,pp. 94-103.Specifications, EEE Sofixwe, Jan. 1984, pp.ij-8X.men= Specification,Prac. So j haw M e t r i c s Synzp.,I EEE C S Press, Los A -amito?, Calif., 1993,pp. 131-152.

3. P. Hsia and A. Gupt a, Incremental Del ive g Using Abstract Data Types andRequirem ents Clustering, P7-0~.ntl Con$ Syrtms ntegmtimz, I EEE CSPress, Los Alamitos, Calif., 1992, pp. 137-.50.

5 . Luqi and W Royce, Status Report: Computer-Aided Prototping, IEEESofn.are, Nov. 1992, pp. 77-81.

6. VV Wang et al., Scenario-Driven Requirenients-.~alysisMethod,PivcI i d Con5 $ y z m r Integmtion, IEEE CS Press,Los Alamitos, Calif., 1992,pp.127-136.quirements, tech. report, Com puter Science Dept., Univ. of Colorado, Col-orado Springs, 1993.Con6Sptm nteptzoiz, I EEE CS Press, Los Alamitos, Calif., 1992,pp. 127-136.

7 . A Davis, K. Jordan, and 1.Nakajima,-4Canonical Representation for Re-

8. H. Rubeilstein and R. Waters, The Requiremeno:Apprentice, p1-or. tztl

9. V Berr,ins and Luqi, S o j h u e Engiiiewingn,ith 4b,sn;?l t i oz r , Addison-Wesley,Reading, M ass., 1991.10. J. UTng, A pecifiers ntroduction t o Formal Methods, Complrtm;Sept.

~ 1990, pp. 8-24

Alan M.Davis 15 aprofessor ofcomputerscience andEl Pomarchairof soh-\\are engi-neermg at theUnirersity of

Colorado at Colorado Sp rings and a tthe Colorado Institute for TechnologyTransfer and Implementation, and anassociate editor ofIEE E [email protected] Ie isthe author ofSofitzlr Regnn+mnzts:Ob-

jects, Foundations, aid States (Prentice-Hall, 1993) and the author or coauthorofmore than 40 papers on software andrequirements engineering. He s also as-sociate editor of3ozmzulof~+tm~smiSo&a,u.from the State University of New Yorkat Albany, and a nM S and a PhD incomputer science from the Unive rsityof Illinois at Urbana-Ch ampaign. H e isa senior rneniber of the I EEE.

Da\

Documents

RequirementsEngineering Lectura Tecnica