REQUIREMENTS

We now better understand how to write relatively unambiguous, complete, consistent requirements. But we generally dont. Why is there such a wide gap between the state of the art and the state of the practice?
PE1 HSlA
University of Texas at Arlington

ALAN DAVIS University of Colorado at Colorado Springs

n the early 1970s, researchers began thinking about how to solicit, collect, analyze, and formally specify system and software requirements. Twenty years later, although we have improved our understanding of how to write relativelyunambiguous,complete, and consistent requirements, we generallydont. For the most part, the state of the practice is that requirements engineering produces one large document, written in a natural language, that few people bother to read. Projects that do read and follow the document often build systems that do not satisfy needs. What are we doing wrong? Why is there such a wide gap between the state of the art and the state of the practice?
CRUCIAL PROCESSSTEP

The quality of a software product is only as good as the process that creates it. Requirements engineering is one of the most crucial steps in thls creation process. Without a well-written requirements specification, developers do not know what t o build, customers do not know what to expect, and there is no way

to validate that the system as built satisfies the requirements. Requirements engineering is the disciplined applicationof proven principles, methods, tools, and notations to describe a proposed systems intended behavior and its associated constraints. It includes all activitiesrelating to the + identification and documentation of customer and user needs, + creation of a document that describes the external behavior and the associated constraints that will satisfy those needs, + analysis and validation of the requirements document to ensure consistency,completeness, and feasibility,and + evolution of needs. The primary output of requirements engineering is a requirements specification. If it describes both hardware and software,it is a system requirements specification. If it describes only software, it is a software requirements specification. In either case, a requirements specification must weat the system as a black box. It must delineate inputs, outputs, the functional requirements that show external behavior in terms of input, output, and their relationships, and nonfunctional require-

ments and their constraints, including performance, portability, and reliability. The software requirements specification should be internally consistent; consistent with existing documents; correct and complete with respect to satisfymg needs; understandable to users, customers, designers, and testers; and capable of serving as a basis for both design and test.
STATE OF THE PRACTICE

Most software-development organizations agree there should be a set of activities called requirements engineering and that their success is vital to the success of the entire project. So why is the state of the practice no better than it is? There are several reasons, not all of them obvious: + Reguimnents alp dzficult to u~zcoue~: Today we are automating virtually every kmd of task - some that were formerly done manually and some that have never been done before. In either kind of application, it is difficult if not impossibleto uncover requirements, regardless of the techniques you use. No one can seea brand new system in its

IEEE SOFTWARE

07407459/93/1100/0075/$03

00 D IEEE

75

entirety. Even if someone could, the description is always incomplete at the start. Users and developers must resort to trial and error to identify problems and solutions. + Requirements change. Because no user can come u p with a complete list of requirements a t the outset, the requirements get added and changed as the user begins to understand the system and his or her real needs. That is why we always have requirements changes. But, the project schedule is seldom adjusted to reflect these modifications. Fluid requirements make it difficult to establish a baseline from which to design and test. Finally, it is hard to justify spending resources to make a requirements specification perfect,because it will soon change anyway. T h s is the biggest problem facing requirements engineering, and there is as yet no technology to overcome it. T h s characteristic is often used as an excuse to either eliminate or scale back requirements-engineering effort. + Some method being used are inappropriate. In their persistent quest for a silver bullet, engineers and managers are repeatedly drawn toward popular but inappropriate techniques. In the 1970s and early

BECAUSE

ARE FLUID, IT S I HARD TO ESTABLISH

RWJMMS

1980s, many requirements engineers embraced structured analysis. But this technique, whch describes interactions that occur in the real world or among software components, does not let you visualize the overall systems behavior dynamicallv and tends to fead to Premature design. Now many projects are embracing objectoriented techniques. Although object-oriented techniques are practical and effective for design and codmg, it is not clear what they can do for requirements engineering. Object-oriented analysis is an effective way to describe entities in the real world and their interactions, but it has yet to be demonstrated as effective for documenting a systems external behavior as a black box. + There is over-reliance on CASE tools. Computer-aided software-engineeringtools are often sold as panaceas. These exaggerated claims have created a false sense of trust, which could inflict untold damage on the softwareindustry. CASE tools are as important to developers (including requirements writers) as word processors are to authors. However, you must not rely on requirements-engineering tools without first understanding and establishing requirements-engineering principles, techniques, and process. Futhermore you must have realistic expectations of the tools. The difference between

word processors and CASE tools is that the former are not sold as tools that wdl change how well you write. + Training is insuficient. Most software engineers know only a few requirements-engineering notations, techniques, and tools. Only a fraction of them have received the proper mining to apply these to realworld problems. Additionally, very few software engineers are trained in the application domain. Hence, it is difficult for them to perform requirements engineering on a specific project. As a result, requirements-engineering notations, techniques, and tools are often misused, cresting the impression that requirements engineering is neither useful nor effective and reducing confidence in the results of requirements-engineering research. Effective requirements engineering means that you must know many notations and techniques. Unfortunately, today most training emphasizes specific ones, and thus communicates know-how without teaching know-when. This is like instructing carpenters in how to use a drill press and telling them they can build any piece of furniturewith it. + Prpject schedule is always unrealktizlly tight. Because of either lack of planning or unreasonable customer demand, many projects start with insufficient time to do a decent job. Sometimes, even the allocated time is reduced while the project is underway. It is also

customary to reduce the time set apart to analyze requirements, to get started designing and codmg, which kequently leads to disaster. + Developen lack c m j h e in requirements engineering. Many large projectshave failed in spite of using modern requirements-engineering techniques. Currently, there is no convincing evidence that modern requirements engineering improves productivity and quality, although the goal of understanding user needs early is obviously a worthy one. + Communication barriers separate helopenandmen. Requirements engineering is communication-intensive. Users and developershave different vocabularies, professional backgrounds, and tastes. Developers usually want more precise specifications; users prefer natural language. Selecting either results in misunderstandmg and confusion. A partial solution is to use formal models to augment, not replace, natural language.
STATE OF RESEARCH

On the basis of our investigation, we found the following research areas to have significant payoff potential. The relative time-fi-ame duringwhch we expect them to have major effect on practice ranges from short to long term.
Improving natural-language

spedficcllkns (short-tenn). Almost all research in requirements engineering today deals with the introduction of more formality into the process. There is a large gap between the state of the practice (informal natural language) and the state of

76

N O V E M B E R 1993

the research (formal models). More research must be done to provide natural-language writers with insight into how they can improve their documents without formal models. Although user needs truly are difficult to determine, we still need guidmg principles to reduce the ambiguityinherent in a natural-language document when it is written. Robert Balzer has succeeded in removing some shortcomings by experimenting with partial translation kom English into more formal models. Barry Boehm and Alan Davis and colleagues3 have identified the attributes that a requirements writing team should look for when they review a natural-Ianp a g e specification. Pei Hsia and colleagues have pioneered scenario-based analysis: whch can augment both naturaland formal-language specifications.

and inexpensively and are discarded afterward. The advanapproach is rapid tage of th~s feedback. Evolutionary prototypes are constructed in a quality manner and are evolved iteratively into a production system. The advantage of this approach is that nothing is discarded. As Luqi and Winston Royce have pointed out, the highest payoff will come kom research improving + languages for rapid prototype generation, + reuse capabilityto make prototype generation from reusable components more feasible, and + tools that generate user interfaces. Rapid prototyping of software systems includes functional, user-interface, and performance aspects. Functional prototyping is usually accomplished by executable specifications, which can be automatically translated into Rapid prototyping and require- executable prototypes. Userments animation (short-term). In interface prototypingis usually the context of requirements accomplished by computerengineering, prototyping is aided tools that capture the inthe construction of an execut- tended human-machme interable system model to enhance action and generate code that understanding of the problem implements such interactions. and identify appropriate and Performance prototyping is feasible external behaviors for often accomplished by anapossible solutions. Prototyp- lytic,probabilistic,and/or siming is an effective tool to re- ulation models that predict a duce risk on software projects designs performance and its by early focus on feasibility implementationalternatives. To improve its technology analysis, identification of real requirements, and elimination transfer, rapid prototyping of unnecessaryrequirements. must be assisted by tools for The most popular proto- requirements analysis, design typing approaches are the and prototype generation. Althrowaway approach and the though some experiments evolutionary approach. have shown its feasibility, a Throwaway prototypes are constructed relatively quickly

the ability to generate systemtest plans from a requirements specification. Faced with an NP-hard problem, only heuristic approaches work. Many Requirements clustering (mid- research efforts have atterm). Requirements clustering tempted to address h s , but for incrementalsoftwaredeliv- none have proved viable in ery has shown promise? It production environments. clusters related requirements Perhaps one reason is that to form the subsystems that ex- todays specifications arent hibit certain desired proper- formal enough. The second challenge is ties. For example, if you want to decomposea system into in- our inability to monitor how dependent subsystems, you well requirements are covered must identify all the basic and during system test. The indusessential requirements that are try has many code-coverage vital to all subsystems before analyzers but none for requireyou can partition the rest of the ments coverage. The h r d challenge is to requirements.If the purpose is to deliver software systems like develop tools that automatihighways, one segment a t a cally maintain traceabilitymatime, then you must establish trixes that map requirements proper criteria for clustering to tests. Numerous commersets ofrequirementsto support cially available tools help you maintain such such subsystraces, but none tems. Requirecan or will be ments clustering able to do thls is used to define separately delivautomatically, and none of erable increthem are h k e d ments. Case studies to programsthat have demont:yirestrated the feasiA recent debility of requirements clustering velopment in scenario-based in both the structured and pro totypin g suggests that an object-oriented intermediate paradigms. Further studies in requirements form may be used to solve clustering should take into these problems. Because sceconsiderationhow to deal with narios are the end users perrequirementschange and how spective of a system: they can to incorporate such change also serve as a basis for accepinto already defined incre- tance testing. An intermediate form alleviates the traceability ments. problem by having the users Requirements-based testing identify links between scenar(mid-term). This area poses ios and requirements, and many challenges. The first is solves the test-planning problem by using scenarios as test great deal of research and development remain before thls technology realizes its full potential.

WE NEED GUIDANCE ON HOW TO WRITE AN UNAMBWS NATURALLANGUAGE DOCUMENT.

IEEE SOFTWARE

77

templates for requirements. More study needs to be done to substantiate these promises.

what makes them reusable, how can we store and retrieve them, and how do we write a requirements specification Computer-clided requirements that gives us the highest probengineering (mid-term). Many ability of creating or reusing graphical editors are now existing requirements compoavailable under the CASE um- nents? The most significant work brella, most of which support a small set ofrequirementsnota- thus Edl. in requirements reuse tions. Those that do support came out of the 1993 IEEE International multiple notaSymposium on tions provide Requirements little consisEngineering tency checking (the proceedo r automatic ings are availtranslation between notations. Also with few exceptions, At the symposium, Alister CASE tools are Sutcliffe and based primarily Neil Maiden on dataflowdiadescribed how grams, one of to retrieve rethe most inforq u i r em e n t s mal (and thus based on doleast effective) main knowlnotations availedge, and Kevin able. More reRyan and Brian search is needed Mathews deto find CASE technology that can support scribed how to use conceptual multiple sets ofnotations,con- graphs to retrieve similar consistencycheckingacrossmulti- cepts. ple notations, and automatic Research into methods (midtranslation between them. T h e major advances in term). We need controlled exCASE technology during the periments with systematicdata last few years have been in the collection to demonstrate that quality of the user interface methods work. We believe and the addition of new nota- that complex system developtions with syntax-sensitiveedi- ment probably requires several tors. The May 1990, March requirements-engineering 1992, and May 1992 issues of methods. To make this meanIEEE Sqibare provide excel- ingful, we need a taxonomy of lent coverage of the state of the requirements notations that research in CASE technology. highlights the similarities and differences among them. Specifically, we must understand Requiements reuse (mid-term). Much research is underway in precisely how diverse notadesign and code reuse. More tions overlap semantically, research is needed on the advantages and the necessary methods for requirements reuse. For example, what are requirements components, .:

which will make it easier to do consistency checking across, and translation among, them. Knowledge engneerhg (longterm). Requirements engineering is a knowledge-intensive process. Knowledge that is useful in requirements engineering includes general knowledge of requirements analysis and specification as well as application-specific, model-specific, and processspecificknowledge. Knowledge-based requirements engineering is concerned with applying knowledge-based techniques to the problems of identifjmg,specifymg, verifjmg, and validating software requirements for large, complex systems. Research challenges in h s area include the acquisition, representation, and manipulation of knowledge about all of the above. In domain modeling, requirements engineering has recently begun dealing with the use of domain-specific knowledge to derive or validate requirements specifications. Research into automating the acquisition of customed requirements also looks promising. Automated translation of informal, natural-language specifications into more rigorous, formal specifications has made some earlyprogress.
Formal methods (long-term).

THE $(OPE OF FORMAL METHODS SHOULD BE BROADENED, AND THEY SHOULD BE W E MORE PRACML ANDUSERFRlENDLX

$k&Fr:L:

Research in formal methods and their associated formal reasoning capabilities has potential for a long-term effect on requirements engineering. In many engineering fields, mathematical models and declarative languages are used in

the requirements and design phases. Formal methods have a sound mathematical basis, often given by a formal specification language. The potential advantages of using a formal method include + promoting a deeper understanding of the functionality and behavior of complex systems, + promoting accurate, precise, and unambiguous requirements specifications; + allowing rigorous analysis of system, specification,and implementation properties, such as consistency, completeness, realizability, and correctness; and + allowing computeraided manipulation. The most well-known formal methods are Spec, Z , Vienna Definition Method, and Larch. L k e all formal methods, these systems have a sound mathematical basis. They have been applied to specifications of mediumsized, nontrivial problems, especially the functional behavior of sequential programs, abstract data types, and hardware? Current research on formal methods has focused mainly on developing formal specification languages for representation. Manipulation is often neglected. Long-term research goalsin formalmethods should include developing practically applicable reasoning methods, expanding their scope and scale of application to more complex systems, and finding the means to make their representations more user-friendly. As pointed out by Jeanette Wing, the chal-

7 8

NOVEMBER 1993

esearch in improving lenges for formal methods inatural-language specificlude + specifying nonfunctional cation, and rapid prototyping requirements such as reliabil- should provide quick results ity, safety, critical timing con- and be readily transferable. straints, performance and However, research in knowlhuman factors; edge engineering and formal + combining different methods requires longer term methods, such as a domain- commitments and substantial specific method with a do- effort to bring about practical main-independent method, or results -and they may not be an informal method with a for- readily transferableto practice. We must learn from experimal method; + building more usable ence that technology transfer and more reliable tools to ef- in requirements engineering is fectivelyand efficientlymanip- exceptionally slow. Two avedate and analyze formal spec- nues may be the best routes to successful technology transfer: ifications; + building reusable speci- Incvemental changes in techfication libraries to increase niques, whch provide gradual the productivity and quality of improvement and radical changes in techques, whch formal methods; + integrating formal imply revolution and thus remethods with the entire soft- quire significant evidence of worth, utility, and applicability ware-developmentprocess; + demonstrating that ex- because the risk is much isting techtuques scale up to hgher. The requirements-enhandle real-world problems gineering community has yet and scaling up the techques to be exposed to the latter case ,in its short 2 5-year life. themselves; and + training more people in the use of formal methods. Pei Hsia is a

R n

ACKNOWLEDGMENTS
This report was developed out ofworkshops in 1991 and 1992 whose participants were members of the IEEE S0f)Wai-e editorial and industry advisory boards. The requirements-engineering subgroup included the authors plus Art Hersh, Software Producnvity Consortium; Gunter Koch, 2i Consult; and Shari Pfleeger, City University of London.

REFERENCES

1. R. Baker, et al., Informalityin Program ,IEEE Tra7u. SoJham Eng., Mar. 1978,pp. 94-103.

2. B. Boehm, Verierifyingand Validating Software Requirements and Design IEEE Sofixwe, Jan. 1984, pp.ij-8X. Specifications,
3. A Davis et al., Identifiingand Measuring Quality in Sofnvare Requiremen= Specification,Prac. Sojhaw Metrics Synzp., IEEE CS Press, Los A amito?, Calif., 1993,pp. 131-152. 3. P. Hsia and A. Gupta, Incremental Deliveg Using Abstract Data Types and Intl Con$ Syrtms Integmtimz, IEEE CS Requirements Clustering, P7-0~. Press, Los Alamitos, Calif., 1992, pp. 137-.50.

5 . Luqi and W Royce, Status Report: Computer-Aided Prototping, IEEE Sofn.are, Nov. 1992, pp. 77-81. 6. V V Wang et al., Scenario-Driven Requirenients-.~alysis Method, Pivc I i d Con5 $ y z m r Integmtion, IEEE CS Press, Los Alamitos, Calif., 1992,pp. 127-136. 7 . A Davis, K. Jordan, and 1.Nakajima, -4Canonical Representation for Requirements, tech. report, Computer Science Dept., Univ. of Colorado, Colorado Springs, 1993. 8. H. Rubeilstein and R. Waters, The Requiremeno:Apprentice,p1-or. Itztl Con6 S p t m Inteptzoiz, IEEE CS Press, Los Alamitos, Calif., 1992,pp. 127136. 9. V Berr,insand Luqi, S o j h u e Engiiiewingn,ith ,4b,sn;?ltiozr, Addison-Wesley, Reading,,Mass., 1991. 10. J. UTng, A SpecifiersIntroduction to Formal Methods, Complrtm;Sept. 1990, pp. 8-24

A unified framework (longterm). Currently no formal foundation or model for nonfunctional requirements has been found. Hence, problems in functionalrequirements and nonfunctional requirements have to be dealt with separately.However, piecemeal solutions do not necessarily work well overall. Therefore, we must establish a unified framework to integrate requirements-engineering principles and concepts and to avoid fragmentation.

profesqor of computer-acience c n g neermg at the University of Texas at khngron, and an associate editor-rnchief of IEEE Sojhume. His research interests include requirements engineering, software-developmentparadigms, rapid protogping, languages,and conputation complexity. Hsia received a PhD in computer science from the University of Texas at Austin. I Ie is a memhcr of the ACU, Sigma Xi, Scienafic Research Society, and Phi Beta Delta I Ionor Society for International Scholars, and a senior member of the IEEE. His address is Computer Science Engineering Dept., Umvenity of Texas, POBox 190li,.Arhngton,TX7601900 15; CSnet hsia~evax.arl.utexas.edu.

Alan M. Davis 15 a professor of computer science and El Pomar chair of soh\\ are engineermg at the Unirersity of Colorado at Colorado Springs and a t the Colorado Institute for Technology Transfer and Implementation, and an associate editor ofIEEE [email protected] Ie is the author ofSofitzlr Regnn+mnzts: Objects, Foundations,aid States (PrenticeHall, 1993) and the author or coauthor ofmore than 40 papers on software and requirements engineering. H e is also associate editor of3ozmzul of~+tm~s ami
So&a,u.

David C. Kung IS an a sociate profe sor of computer science and engneer ing at the University of Texas at ArI m a m His research interests are object-oriented design and object-oriented software testing. Kung received a BSc in mathematin from Peking University and an MS and a PhD in computer science from the Nomegian Institute of Technology I3e is a member of the IFIP Working Group on Information Systems Design and Evaluation. Address questions about this article to Hsia at Univenity ofTexas, Computer Science Dept., Box 19018,hrling ton, T X 76019-001 5; hsiaOae.uta.edu or Davis at University ofColorado at Colorado Springs, 1867 Ausm Bluffs P h y , Ste. 200, PO Box 7150, Colorado Springs, CO, 80933-71 SO; adavis~valdi.uccs.edu.

Da\<sreceived a BS in mathematiu: from the State University of New York at Albany, and anMS and a PhD in computer science from the University of Illinois at Urbana-Champaign. He is a senior rneniber of the IEEE.

IEEE SOFTWARE

79