Integrated Requirements Engineering: a Tutorial

focusrequirements engineering1

Integrated Requirements Engineering: A Tutorial

Ian Sommerville, Lancaster University

efore developing any system, you must understand what the system 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 (telecommunications, 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 requirements 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 requirements 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. They are all part of the general ■ The need for improved ROI on software process of developing a deeper understanding assets. Companies have enormous invest- of the business, the capabilities and structure ments in their software and, understand- of the system being developed, and its operat- ably, want to get as much return as possible ing environment. on that investment. So, when they need new systems, there’s pressure to reuse exist- RE for the 21st century ing software wherever possible. This intro- The 20th-century view of RE as something duces the need for interoperability require- you do before system development, and the ments that specify how the new and the software requirements document as a com- existing software should work together. plete specification of the software to be implemented, is no longer valid for many types of The emerging vision of Web Service archi- system. New approaches to software develop- tectures where programs can dynamically ment and the need for businesses to respond search for available services and bind to them quickly to new opportunities and challenges at runtime poses further challenges for RE. In mean that we must rethink RE’s role in soft- the Web Services model, a system’s components ware development. are services, defined by their interfaces. These Four key change drivers have forced this re- might be offered by external providers, and think: many providers might offer the same service,

18 IEEE SOFTWARE www.computer.org/software such as an ordering service for PCs. In princi- Construction by Configuration ple, an executing program can use services from different providers at different times without user intervention. The central development in software engineering over the past 15 years Instead of thinking about requirements in has been the divergence of approaches to software development for different terms of system functionality or features, we’ll types of system. Before 1990, irrespective of application domain, most sys- have to think about systems in terms of services tems were designed and programmed in a generic or application-specific provided and used. We’ll also need to find ways programming language. Business systems were developed in Cobol, operat- to embed the requirements for the services that ing systems in C, many embedded systems in assembly language, and so on. a program itself needs so that these services can There was a shared development paradigm of specify, design, implement, test. be dynamically discovered and used. However, the past 10 years have seen remarkable changes. Pressured by the need to cope with rapid change, the Y2K problem, and increasingly Integrating RE with system complex distributed environments, businesses changed from building all development their software from scratch to an approach based on software reuse. For To address the system development chal- business systems, the dominant development paradigm is no longer based lenges of the 21st century, we must integrate around programming but around reuse. Systems are developed by assem- the processes of RE and system implementa- bling and integrating COTS, legacy systems, handwritten code, configured tion. The artificial separation of these activi- enterprise resource planning (ERP) systems, and other software. ties leads to a situation where customers don’t Sometimes this still involves conventional programming but with extensive realize how much time and effort is required component reuse. At other times, it means configuring an off-the-shelf system to to deliver their requirements, and where sup- support a business process; in other cases, it might mean moving toward an ERP- pliers can’t deliver the best value to customers based solution where the software development involves constructing business using their specialist knowledge and existing rules and business process descriptions. In all these cases, however, the freedom software. of the system stakeholders and designers is limited by what is available. RE researchers and practitioners increas- Of course, other system classes, such as control systems and middleware, ingly recognize this. I don’t have space to dis- are still developed according to the traditional paradigm. While this approach cuss all the recent developments, so I’ll focus will continue for some classes of system, I believe that software construction by here on three particularly important areas of configuration rather than programming will be extended to other areas such work: as systems software development and embedded systems.

■ Concurrent RE ■ Supporting trade-offs between requirements and design oped and delivered in increments, with each ■ RE and commercial off-the-shelf (COTS) increment incorporating a useful subset of the acquisition overall system functionality. Concurrent RE offers several benefits: Concurrent RE Concurrent engineering is an approach to ■ Lower process overheads. You’ll spend product development where, instead of a se- less time analyzing and documenting a quential process of specification, design, manu- large body of requirements. facture, and so on, engineering process activities ■ Early identification and implementation are carried out concurrently with extensive feed- of value-delivering requirements. Value- back and iteration among the different teams delivering requirements are the most criti- involved. In software engineering, agile devel- cal ones for the customer’s business—they opment methods such as Extreme Program- might allow new business processes to be ming (XP)11 embody a concurrent approach created or existing processes to be more that integrates the processes of RE, design, and effective. A customer representative iden- development. tifies the requirements that deliver the Concurrent RE means that the starting most value and negotiates their implemen- point for development is an outline of the soft- tation with the development team. ware. RE activities such as elicitation and val- ■ Responsiveness to requirements change. idation are carried out concurrently, and the Because you identify and document your RE process is concurrent with other system requirements iteratively, the overhead of development processes. The system is devel- accommodating requirements change is

January/February 2005 IEEE SOFTWARE 19 lieve that the benefits of creating a complete requirements document for their business sys- Downloading and printing an article tems outweigh the time and effort costs re- First, you select the article that you want from a displayed list. You quired to create such a document. then have to tell the system how you will pay for it – this can either be through a subscription, through a company account, or by credit Some RE researchers and practitioners are card. concerned that XP’s informal approach makes After this, you get a copyright form from the system to fill in and, requirements analysis almost impossible. Be- when you have submitted this, the article you want is downloaded cause XP requirements aren’t formally docu- onto your computer. mented, developers effectively discard them You then choose a printer and a copy of the article is printed. You after implementation, and they never deliver a tell the system if printing has been successful. complete system specification to the customer. If the article is a print-only article, you cannot keep the PDF version I also have some doubts about the imperma- so it is automatically deleted from your computer. nence of XP requirements, but I believe the concurrent approach points the way forward for using RE in volatile business systems. Figure 2. A story card describing a usage relatively low. It might simply involve Supporting requirements/design scenario of a digital reprioritizing the development schedule to trade-offs article library. incorporate a requirements change in the A major difficulty in RE is that customers next system increment or to implement a don’t have the knowledge to estimate the dif- newly emerged requirement. ficulty and associated costs of implementing a requirement. They might suggest an appar- For example, in XP, customer representa- ently simple requirement that has major cost tives are key members of the development repercussions, or they might unnecessarily team. Rapid iteration is the norm, with new limit their requirements because they don’t releases of the system delivered to the cus- know what’s already available in off-the-shelf tomer at frequent intervals. The customer rep- products. Barry Boehm and his colleagues give resentative’s role on the development team is examples of situations in which such problems to identify the requirements that, at any point arose:12 in the development cycle, deliver the best value and then to negotiate the implementa- ■ A customer asked for a natural language tion of these requirements with the developers. interface to a relatively simple query sys- The particular approach used in XP is based tem. This resulted in major additional costs on stories or scenarios, with each scenario writ- and ultimate cancellation of the project. ten on a card. The scenarios are written in user ■ In a project to digitize corporate records terms and illustrate some required user func- using scanning and optical character tionality. For example, Figure 2 shows a simple recognition, the customer failed to recog- scenario that might be used in implementing a nize that the OCR technology didn’t work library system that provides access to paid-for well with tables, charts, and graphs. copyright articles from external providers. Developers analyze the scenario, break it Boehm argues that to deliver systems rapidly down into tasks, and estimate the effort re- that meet customer needs, a key challenge is to quired to implement that scenario. Given this reconcile customer expectations with developer information about the costs of implementing capabilities. He developed an approach to RE each scenario, the customer representative then called the WinWin approach,13 in which nego- decides which requirements should have prior- tiation between customers and software suppli- ity for inclusion in the next system release. ers is central. The aim is to ensure that all stake- Concurrent RE isn’t suitable for all types of holders identify win conditions that can be system. If you have to implement a critical sys- satisfied. The WinWin approach has now been tem where careful analysis of the interactions incorporated in a more general approach to RE and dependencies between requirements is es- called MBASE (model-based architecting and sential, you need a complete and detailed re- software engineering), which integrates RE and quirements document before implementation systems design. starts. However, many companies don’t be- One of the most important aspects of the

20 IEEE SOFTWARE www.computer.org/software MBASE approach is its support for managing Figure 3. The cyclical expectations. To help with communication be- Acquire PORE (procurement- customer oriented requirements tween customers and developers, Boehm and requirements his team have identified what he calls simpli- engineering) process fiers and complicators: things that make life can help you select the easier and things that make life harder, for right COTS product. both developers and customers. These are or- Explore Check remaining compliance ganized and classified using domain-specific COTS software with COTS headings and are used to help customers un- candidates software derstand the problems developers face, and vice versa. For example, for COTS package extension, Reject noncompliant developer-side simplifiers are systems

■ Clean, well-defined APIs ■ A single COTS package ■ Simple mappings of interface inputs and though you shouldn’t underestimate the diffi- outputs culties of this approach, when it’s successful it leads to lower development costs and acceler- and developer-side complicators include ated system deployment. From an RE perspective, the traditional “re- ■ Dynamic APIs quirements first” approach poses real prob- ■ Natural language processing lems. If you develop a detailed set of require- ■ Multiple, incompatible COTS packages ments, you’ll probably find that no COTS ■ Volatile COTS packages product meets your requirements. When select- ■ Complex exception handling ing COTS software, you need to be flexible; identify a set of critical requirements and You can analyze simplifiers and complica- choose products that meet them. Then you can tors from a customer perspective to assess the adapt and extend your other requirements ac- associated customer risks and benefits. For ex- cording to the selected systems’ capabilities. ample, in an information retrieval system for a Two areas of RE research are particularly digital library, an obvious simplifier is to use a important for COTS acquisition. The first deals standard query language. However, the risk with COTS product selection: When many dif- from a librarian perspective is that this might ferent products are available, how do you pick not be as effective as a specially designed query the one that’s best for your requirements? system because users must know what they’re The second area is COTS interoperability: looking for before they start searching. How should you specify your requirements Simplifiers and complicators are a simple so that your COTS software will work with idea that you can easily incorporate in any RE each other and with your existing operational process. They make clear to customers that systems? different requirements choices have signifi- cant implications for the system’s design and Selecting a COTS product implementation, and they provide a focus for Neil Maiden and his colleagues have devel- making requirements and design decisions oped a systematic approach to COTS product that reduce the risks for both software cus- selection called PORE (procurement-oriented tomers and suppliers. requirements engineering).14 This approach depends on eliciting key requirements from RE and COTS acquisition stakeholders, then using these to identify a COTS systems are now available in most candidate set of COTS software that meets or domains, so you can configure and adapt partially meets these requirements. The candi- generic products to different operational set- date systems’ features and capabilities help tings. You can develop applications by acquir- system stakeholders identify further require- ing new COTS systems and configuring them ments that they can then use to refine their se- to interoperate with existing systems. Al- lection of COTS products. Figure 3 shows this

January/February 2005 IEEE SOFTWARE 21 cyclic process, in which the final result is se- that are already in place. For example, a desk- lection of the most suitable COTS system. top e-procurement system might have to work Over the next In the PORE process, you select candidates with an existing supplier database to provide few years, through a three-stage process, in which each supplier information and with an existing or- stage develops the system requirements in dering and invoicing system to manage orders, integrated RE more detail and reduces the size of the COTS payments, and deliveries. will become the candidates set. The stages are as follows: In the RE research community, there’s been a prevailing view that we can achieve preferred mode 1. Use publicly available information to select interoperability by using open interfaces and of development candidate COTS software. Identify critical standards, and that simply specifying open- for most types requirements that you can employ to dis- ness as a requirement solves the problem. criminate between products using market- Experience has shown this isn’t true. Boehm of system. ing literature and data sheets. Require- and Chris Abts have reported on some of the ments at this stage might include cost practical difficulties in integrating COTS requirements, requirements for general ca- systems.15 pabilities, and interoperability require- Soren Lausen, in a recent paper,16 discusses ments. the problems of specifying interoperability re- 2. Use product demonstrations to narrow the quirements and choosing systems that meet set of possible systems and to stimulate the these requirements. He introduces a new type elicitation of new requirements. The prod- of requirement called an open-target require- uct demonstrations should show how each ment, which tries not to exclude any possible system meets the initial requirements and technical solution. It defines customer expec- demonstrate each system’s overall capabili- tations and, critically, requires potential ties. This gives you information on how to suppliers to explain how they’ll meet those refine your initial requirements and gener- expectations. ate new requirements that let you pick the He proposes five guidelines for interoper- systems that go forward to the next stage. ability requirements specification: 3. Use hands-on product evaluation to further refine your choice of system and your system 1. Use open-target requirements and develop requirements. By this stage, you effectively a structured framework for evaluating have a prototype system for experiment, and and scoring suppliers’ responses to these you can use this with stakeholders to drive requirements. the requirements elicitation process. Because 2. Express the interoperability requirement as they can see what features and capabilities a user request rather than as a technical each system offers, stakeholders can priori- requirement. tize their requirements accordingly. Once 3. Be flexible in the degree of integration that you’ve narrowed the choice to two or three you can live with. systems, you might perform more extensive 4. Think about product evolution, and write trials to assess the emergent properties of can- requirements that ensure that someone didates such as performance, reliability, and apart from the original supplier can extend so on. the product. 5. Write a trial period into the system contract The PORE method provides active guid- to demonstrate that the supplier can handle ance for each of these stages. It’s been used the project’s high-risk areas. successfully to procure different types of systems, including requirements management To illustrate open-target requirements, con- systems and telecommunications systems for sider a sample e-procurement system that securities trading. must interoperate with an existing supplier database: Interoperability requirements All companies now use a range of different R1: The e-procurement system shall not software systems, and a critical business re- maintain supplier addresses separately but quirement in many situations is that new soft- shall retrieve supplier addresses from the ex- ware systems should interoperate with those isting supplier database.

22 IEEE SOFTWARE www.computer.org/software Expressing the requirement in this way is un- About the Author duly restrictive and might exclude many possible e-procurement COTS solutions that in- Ian Sommerville is a professor of software engineering in the Computing Department clude their own data management system. An at Lancaster University. His research interests include requirements engineering, system dependability, service-oriented software engineering, and social informatics. He received his PhD alternative specification would be to focus on in computer science from St. Andrews University, Scotland. He is a Fellow of the British Com- the consistency of the information: puter Society and IEE and a member of the IEEE Computer Society and ACM. Contact him at the Computing Dept., Infolab21, Lancaster Univ., Lancaster, LA1 4WA, UK; [email protected]. R1a: The supplier addresses displayed by the e-procurement system shall be consistent with the customer addresses in the supplier database.

This is a more open requirement but again lies on the remote development team working might be unduly restrictive. It excludes the from a detailed specification. Integrated RE will possibility, for example, of simply displaying require acquisition processes to evolve to reflect the supplier name and supplier reference and the fact that close cooperation between clients then adding the address from the supplier and suppliers is the best hope we have for more database when the order is actually generated. effective software engineering.

R1b: The e-procurement system shall share References supplier data with the current supplier data- 1. D. Teichrow and E.A. Hershey, “PSL/PSA: A Computer base. Supplier addresses on orders and invoices Aided Technique for Structured Documentation and must be consistent. The system provider shall Analysis of Information Processing Systems,” IEEE Trans. Software Eng., vol. SE-3, no. 1, 1977, pp. 41–49. explain the proposed sharing mechanism. 2. T. DeMaro and P.J. Plauger, Structured Analysis and System Specification, Prentice Hall, 1979. This open-target requirement is more flexible; 3. I. Jacobson, Object-Oriented Software Engineering: A Use-Case Driven Approach, Addison-Wesley, 1992. it states why the requirement is included and 4. G. Booch, J. Rumbaugh, and I. Jacobson, The Unified explicitly requires an explanation from the Modeling Language User Guide, Addison-Wesley, 1998. system provider of how this will be ensured. 5. IEEE Std IEEE-Std-830-1998, IEEE Recommended Practice for Software Requirements Specification, IEEE Such requirements are a way of ensuring in- CS Press, 1998. teroperability without overprescribing and ex- 6. I. Sommerville and P. Sawyer, “Viewpoints: Principles, cluding systems that might viably meet other Problems and a Practical Approach to Requirements Engineering,” Annals of Software Eng., vol. 3, 1997, important system requirements. pp. 101–130. 7. A. Hall, “Using Formal Methods to Develop an ATC Information System,” IEEE Software, vol. 13, no. 2, 1996, pp. 66–76. usiness demands for faster delivery of 8. A. Van Lamsweerde, “Goal-Oriented Requirements En- systems that cost less and are more gineering: A Guided Tour,” Proc. 5th Int’l IEEE Re- responsive to changing requirements quirements Eng. Conf., IEEE CS Press, 2001, p. 249. B 9. I. Sommerville and P. Sawyer, Requirements Engineer- mean that the traditional “requirements first” ing: A Good Practice Guide, John Wiley & Sons, 2000. approach to software engineering has to 10. A. Davis, Software Requirements: Analysis and Specifi- evolve. Requirements engineering has to be cation, Prentice Hall, 1990. 11. K. Beck, Extreme Programming Explained: Embrace more tightly integrated with system implemen- Change, Addison-Wesley, 2000. tation to take advantage of reuse and to let 12. B. Boehm et al., “Requirements Engineering, Expectations systems evolve to reflect changing require- Management and the Two Cultures,” Proc. 7th Int’l Symp. Requirements Eng., IEEE CS Press, 1999, pp. 14–22. ments. Business system developers have al- 13. B. Boehm et al., “Using the WinWin Spiral Model: A ready embraced these changes. I predict that Case Study,” Computer, vol. 31, no. 7, 1998, pp. 33–44. over the next few years, integrated RE will be- 14: N.A. Maiden and C. Ncube, “Acquiring COTS Soft- ware Selection Requirements,” IEEE Software, vol. 15, come the preferred mode of development for no. 2, 1998, pp. 46–56. most types of system. 15. B. Boehm and C. Abts, “COTS Integration: Plug and However, we should not underestimate the Pray?” Computer, vol. 32, no. 1, 1999, pp. 135–138. real barriers to this integration that will slow 16. S. Lausen, “COTS Tenders and Integration Require- ments.” Proc. 12th IEEE Int’l Requirements Eng. its introduction. Many system acquisition Conf., IEEE CS Press, 2004, pp. 166–175. processes require a detailed requirements document as the basis of the contract between client For more information on this or any other computing topic, please visit our and supplier. Outsourced development also re- Digital Library at www.computer.org/publications/dlib.

January/February 2005 IEEE SOFTWARE 23