Jjjjjj

focus 1

requirements engineering

Integrated Requirements Engineering: A Tutorial
Ian Sommerville, Lancaster University

B

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 involves 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 people who directly or indirectly use the system or the information it provides);
and essential system characteristics such as performance, security, and dependability. Requirements engineering is the name given to a structured set of activities that help developthis understanding and that document the system specification for the stakeholders and engineers involved in the system development. This short tutorial introduces the fundamental activities of RE and discusses how it has evolved as part of the software engineering process. However, rather than focus on established RE techniques, I discuss how the changing nature of software engineering has led tonew challenges for RE. I then introduce a number of new techniques that help meet these challenges by integrating RE more closely with other systems implementation activities.

The fundamental process The RE process varies immensely depending on the type of application being developed, the size and culture of the companies involved, and the software acquisition processes used. For large militaryand aerospace systems, there is normally a formal RE stage in the systems engineering processes and an extensively documented set of system and software requirements. For small companies developing innovative software products, the RE process might consist of brainstorming sessions, and the product “requirements” might simply be a short vision statement of what the software is expected to do.Whatever the actual process used, some activities are fundamental to all RE processes:
■

This tutorial introduces the fundamental activities of requirements engineering and discusses recent developments that integrate it and system implementation.

■ ■

Elicitation. Identify sources of information about the system and discover the requirements from these. Analysis. Understand therequirements, 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. Negotiation. Inevitably, stakeholders’ views will differ, and proposed requirements might conflict. Try to reconcile conflicting viewsand generate a consistent set of requirements. Documentation. Write down the requirements in a way that stakeholders and software developers can understand. Management. Control the requirements changes that will inevitably arise.

Elicitation

Documentation Negotiation Management Analysis

These activities are sometimes presented as if they occur in sequence, where you start with elicitationand end with a documented set of requirements that are then handed over for implementation and managed as changes occur. In reality, whatever the details of the process, RE is always a cyclic activity (see Figure 1). Individual activities repeat as the software requirements are derived, and the iteration continues during system implementation and operation. The outcome of the RE process is astatement of the requirements (a requirements document) that defines what is to be implemented. The software engineering research community has argued that the more complete and consistent a requirements document, the more likely that the software will be reliable and delivered on time. So, we have a range of techniques— from the use of special-purpose requirements specification languages to...