focusrequirements engineering1 Integrated Requirements Engineering: A Tutorial Ian Sommerville, Lancaster University efore developing any system, you must understand what the sys- tem is supposed to do and how its use can support the goals of the individuals or business that will pay for that system. This in- B volves understanding the application domain (telecommunica- tions, railways, retail banking, games, and so on); the system’s operational constraints; the specific functionality required by the stakeholders (the peo- ple who directly or indirectly use the system or the information it provides); and essential system characteristics such as The fundamental process performance, security, and dependability. Re- The RE process varies immensely depend- quirements engineering is the name given to a ing on the type of application being devel- structured set of activities that help develop oped, the size and culture of the companies in- this understanding and that document the sys- volved, and the software acquisition processes tem specification for the stakeholders and en- used. For large military and aerospace sys- gineers involved in the system development. tems, there is normally a formal RE stage in This short tutorial introduces the funda- the systems engineering processes and an ex- mental activities of RE and discusses how it tensively documented set of system and soft- has evolved as part of the software engineering ware requirements. For small companies de- process. However, rather than focus on estab- veloping innovative software products, the RE lished RE techniques, I discuss how the chang- process might consist of brainstorming ses- ing nature of software engineering has led to sions, and the product “requirements” might new challenges for RE. I then introduce a num- simply be a short vision statement of what the ber of new techniques that help meet these software is expected to do. challenges by integrating RE more closely with Whatever the actual process used, some ac- other systems implementation activities. tivities are fundamental to all RE processes: ■ Elicitation. Identify sources of informa- This tutorial introduces the fundamental activities of tion about the system and discover the re- quirements from these. requirements engineering and discusses recent ■ Analysis. Understand the requirements, developments that integrate it and system implementation. their overlaps, and their conflicts. ■ Validation. Go back to the system stake- 16 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/05/$20.00 © 2005 IEEE holders and check if the requirements are what they really need. Elicitation ■ Negotiation. Inevitably, stakeholders’ views will differ, and proposed require- ments might conflict. Try to reconcile con- flicting views and generate a consistent set of requirements. Documentation ■ Documentation. Write down the require- Negotiation Analysis ments in a way that stakeholders and soft- Management ware developers can understand. ■ Management. Control the requirements changes that will inevitably arise. These activities are sometimes presented as Validation if they occur in sequence, where you start with elicitation and end with a documented set of requirements that are then handed over for Figure 1. The implementation and managed as changes oc- developed. The RAND Corporation, founded requirements cur. In reality, whatever the details of the in 1946, introduced the notion of systems engineering process, RE is always a cyclic activity (see Fig- analysis, which has evolved into RE. Under- activity cycle. ure 1). Individual activities repeat as the soft- standing a problem and specifying its system ware requirements are derived, and the itera- requirements became an inherent part of the tion continues during system implementation development process for complex military and and operation. aerospace systems. The outcome of the RE process is a state- The lifecycle model used in systems engi- ment of the requirements (a requirements doc- neering was the predominant influence on the ument) that defines what is to be implemented. development of the waterfall model of software The software engineering research community engineering, first proposed by Winston Royce has argued that the more complete and consis- in 1970. In this model, the process of under- tent a requirements document, the more likely standing and documenting system requirements that the software will be reliable and delivered is the first stage in the software engineering on time. So, we have a range of techniques— process. This led to an assumption that RE was from the use of special-purpose requirements something that you did before you started soft- specification languages to structured model- ware development and that, once discovered, ing, to formal mathematical specifications—to the software requirements would not change help us analyze requirements’ completeness significantly during the development process. It and consistency. also led to the assumption that RE should be Academic research aimed at supporting separated from system design. The system re- completeness and consistency hasn’t had a quirements should define what the system major impact on practice. Requirements are should do; the design should define how the usually written in natural language and are of- system should implement the requirements. ten vague descriptions of what’s wanted rather Work in the 1970s on requirements focused than detailed specifications. In situations on developing requirements statement lan- where requirements change very quickly, this guages, such as Dan Teichrow’s PSL/PSA might be the right approach, because the costs (Problem Statement Language/Problem State- of maintaining a detailed specification are un- ment Analyzer), and methods of structured justified. In other situations, however, failure analysis.1,2 Object-oriented modeling was de- to define precisely what’s required results in veloped in the 1980s, with Ivar Jacobson’s use endless disputes between the client and the cases being a key element now embodied in system developer. the Unified Modeling Language.3,4 The IEEE standard on requirements documents was in- RE’s evolution troduced and refined,5 and the 1990s saw The need for RE became obvious in the last much academic research on viewpoint-ori- century as the systems engineering discipline ented approaches to elicitation and analysis,6 January/February 2005 IEEE SOFTWARE 17 formal mathematical methods,7 goal-oriented ■ New approaches to systems development— approaches,8 and RE process improvement.9 in particular, construction by configuration. Requirements We now know that the initial assumptions The dominant approach for many types of engineers that underpinned much RE research and prac- system is now based on reuse, where exist- tice were unrealistic. Requirements change is ing systems and components are config- shouldn’t be inevitable, because the business environment ured to create new systems. The software influenced in which the software is used continually requirements depend on the existing sys- changes—new competitors with new products tem capabilities and not just on what by design emerge, and businesses reorganize, restruc- stakeholders believe they need. The “Con- considerations ture, and react to new opportunities. Further- struction by Configuration” sidebar dis- when setting more, for large systems, the problem being cusses this important approach to systems tackled is usually so complex that no one can development in more detail. out a system’s understand it completely before starting sys- ■ The need for rapid software delivery. Busi- requirements. tem development. During system development nesses now operate in an environment that’s and operational use, your stakeholders con- changing incredibly quickly. New products tinue to gain new insights into the problem, appear and disappear, regulations change, leading to changes in the requirements. businesses merge and restructure, competi- Separating requirements and design means tors change strategy. New software must be that requirements engineers shouldn’t be influ- rapidly conceived, implemented, and deliv- enced by design considerations when setting ered. There isn’t time for a prolonged RE out a system’s requirements. Moreover, the re- process. Development gets going as soon as quirements shouldn’t limit designers’ freedom a vision for the software is available, and in deciding how to implement the system. In the requirements emerge and are clarified one of the first books on RE,10 Alan Davis ex- during the development process. plains why this is desirable: designers often ■ The increasing rate of requirements know more about technologies and implemen- change. This is an inevitable consequence tation techniques than requirements engineers, of rapid delivery. If you don’t have time to and the requirements shouldn’t stop them understand your requirements in detail, from using the best available approach. you’ll inevitably make mistakes and have However, Davis also recognizes that this to change the requirements to fix these ideal is impossible to achieve. What one person problems. More significantly, perhaps, the might think of as a specification, another thinks changing business environment means of as a design. Fundamentally, the processes of that new requirements might emerge and understanding the problem, specifying the re- existing requirements might change every quirements, and designing the system aren’t week or sometimes even every day. discrete stages.