Über die Autorin bzw. den Autor

Axel van Lamsweerde is Professor in the Department of Computing Science at the Université catholique de Louvain (UCL), Belgium. He recently received the ACM SIGSOFT Outstanding Research Award for "deep and lasting contributions to the theory and practice of requirements engineering".

Von der hinteren Coverseite

This book provides a systematic and practical approach to the engineering of high-quality requirements. It covers the entire requirements lifecycle and integrates state-of-the-art techniques for requirements elicitation, evaluation, specification, analysis, and evolution. Modeling plays a central role. A method is presented for building and analyzing a multi-view model of the target system, where each step is supported by heuristic rules, tactics, modeling patterns, and bad smells to avoid.

Highlights include:

• A comprehensive introduction to the fundamentals of requirements engineering, including techniques for: requirements elicitation and reuse, risk analysis, conflict management, and requirements prioritization; requirements specification, inspection, validation, and verification; traceability management and change control.
• An in-depth treatment of system modelling for requirements engineering, including constructive techniques for modeling system goals, conceptual objects, responsibilities among system agents, operations, scenarios and intended behaviors, and countermeasures to anticipated hazards and threats.
• A variety of techniques for model-based evaluation of alternative options, model refinement checking, model animation, property verification, inductive model synthesis, and analysis of conflicts, hazards, and security threats.
• Use of standard UML notations wherever applicable. Most techniques are based on a solid formal framework, kept hidden throughout the major part of the book for wider accessibility.
• Numerous examples from running case studies in a variety of domains, including security- and safety-critical ones. Rich set of problems and exercises at the end of each chapter together with bibliographical notes for further study.

The book is primarily written for undergraduates and masters students in software or system engineering to acquire a solid background in requirements engineering and system modelling. It is also intended for practitioners in need of systematic guidance for elaborating and analyzing requirements. The last part on model-based reasoning is more targeted to graduate students. A companion website with additional instructor resources and tool support can be found at www.wileyeurope.com/college/van lamsweerde

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

Requirements Engineering

John Wiley & Sons

Chapter One

This chapter introduces requirements engineering (RE) as a specific discipline in relation to others. It defines the scope of RE and the basic concepts, activities, actors and artefacts involved in the RE process. In particular, it explains what requirements there are with respect to other key RE notions such as domain properties and environment assumptions. Functional and non-functional requirements will be seen to play specific roles in the RE process. The quality criteria according to which requirements documents should be elaborated and evaluated will be detailed. We will also see why a careful elaboration of requirements and assumptions in the early stages of the software lifecycle is so important, and what obstacles may impinge on good RE practice.

The chapter also introduces three case studies from which running examples will be taken throughout the book. These case studies will additionally provide a basis for many exercises at the end of chapters. They are taken from quite different domains to demonstrate the wide applicability of the concepts and techniques. Although representative of real-world systems, the case study descriptions have been simplified to make our examples easily understandable without significant domain expertise. The first case study is a typical instance of an information system. The second captures the typical flavour of a system partly controlled by software. The third raises issues that are typical of distributed collaborative applications and product families.

1.1 What is requirements engineering?

To make sure that a software solution correctly solves a particular problem, we must first correctly understand and define what problem needs to be solved. This seems common sense at first sight. However, as we shall see, figuring out what the right problem is can be surprisingly difficult. We need to discover, understand, formulate, analyse and agree on what problem should be solved, why such a problem needs to be solved and who should be involved in the responsibility of solving that problem. Broadly, this is what requirements engineering is all about.

1.1.1 The problem world and the machine solution

The problem to be solved arises within some broader context. It is in general rooted in a complex organizational, technical or physical world. The aim of a software project is to improve this world by building some machine expected to solve the problem. The machine consists of software to be developed and installed on some computer platform, possibly together with some input/output devices.

The problem world and the machine solution have their own phenomena while sharing others (Jackson, 1995b). The shared phenomena define the interface through which the machine interacts with the world. The machine monitors some of the shared phenomena while controlling others in order to implement the requirements.

Figure 1.1 illustrates this for a simple e-commerce world. In this example, the world owns the phenomena of items being delivered to buyers only once they have been paid; the machine owns the phenomena of payment records being created in the machine's database. The phenomena of payment notifications being sent to sellers are shared, as the machine can control them whereas the world can monitor them.

Requirements engineering is concerned with the machine's effect on the surrounding world and the assumptions we make about that world. As a consequence, it is solely concerned with world phenomena, including shared ones. Requirements and assumptions have their meaning in the problem world. In contrast, software design is concerned with machine phenomena.

The system-as-is and the system-to-be

In the system engineering tradition, the word system will be used throughout the book to denote a set of components interacting with each other to satisfy some global objectives. While being intrinsically composite, a system can be seen as a whole through the global properties emerging from component interactions. Such properties include the objectives underpinning component interactions and laws regulating such interactions.

Example 1. Consider an e-auction system on the Internet. This system is made up of components such as sellers, buyers, shipping companies, an independent e-payment subsystem, e-mail systems, and the software to be developed or extended for inserting and advertising items, handling bids, billing highest bidders, recording evaluations of sellers and buyers, securing transactions and so forth. Global properties emerging from component interactions include the satisfaction of buyers getting wider access to interesting items, the satisfaction of sellers getting wider access to potential buyers, auction rules regulating the system, trustworthiness relationships and so on. Example 2. A flight management system includes components such as pilots, air traffic controllers, on-board and on-ground instruments, the autopilot software to be developed, an independent collision-avoidance subsystem and so forth. Global properties emerging from component interactions include the objectives of rapid and safe transportation of passengers, regulating laws about wind directions, aircraft speed, minimal distance between aircrafts and so forth.

In a machine-building project, our business as requirements engineers is to investigate the problem world. This leads us to consider two versions of the same system:

The system-as-is, the system as it exists before the machine is built into it.

The system-to-be, the system as it should be when the machine will be built and operated in it.

In the previous example of an auction world, the system-as-is is a standard auction system with no support for electronic bidding. The system-to-be is intended to provide such support in order to make items biddable from anywhere at any time. In a flight management world, the system-as-is might include some autopilot software with limited capabilities; the system-to-be would then include autopilot software with extended capabilities. In the former example the system-to-be is the outcome of a new software project, whereas in the latter example it results from a software evolution project.

Note that there is always a system-as-is. Consider a project aimed at developing control software for a MP4 player, for example. The system-as-is is the conventional system allowing you to listen to your favourite music on a standard hi-fi subsystem. The system-to-be is intended to mimic the listening conditions of the system-as-is while providing convenient, anywhere and any-time access to your music.

The software-to-be and its environment

The machine's software to be developed or modified is just one component of the system- to-be. We will refer to it as the software-to-be. Other components will in general pertain to the machine's surrounding world. They will form the environment of the software-to-be. Such components may include:

People or business units playing specific roles according to organizational policies. Physical devices operating under specific rules in conformance with physical laws - for example sensors, actuators, measurement instruments or communication media. Legacy, off-the-shelf or foreign software components with which the software-to-be needs to interact.

As we are concerned with the problem world, we need to consider both the system-as-is, to understand its objectives, regulating laws, deficiencies and limitations, and the system-to-be, to elaborate the requirements on the software-to-be accordingly together with assumptions on the environment.

The systems-to-be-next

If we want to build an evolvable machine in our problem world, we need to anticipate likely changes at RE time. During software development or after deployment of the system-to-be, new problems and limitations may arise. New opportunities may emerge as the world keeps changing. We may then even need to consider more than two system versions and foresee what the next system versions are likely to be. Beyond the system-as-is and the system-to-be, there are systems-to-be-next. Requirements evolution management is an important aspect of the RE process that will be discussed at length in Chapter 6.

Requirements engineering: A preliminary definition

In this setting, we may apprehend requirements engineering more precisely as a coordinated set of activities for exploring, evaluating, documenting, consolidating, revising and adapting the objectives, capabilities, qualities, constraints and assumptions that the system-to-be should meet based on problems raised by the system-as-is and opportunities provided by new technologies. We will come back to those various activities in Section 1.1.6 and will have a much closer look at them in subsequent chapters.

1.1.2 Introducing our running case studies

To make the nature of RE more apparent and more concrete, we will consider a variety of case studies. The following descriptions are intended to set up the context in which our running examples will be used throughout the book. They will also provide further insights into the scope and dimensions of the problem world. We should not consider them as problem statements, but rather as fragmentary material collected from preliminary investigations of the problem world (perhaps by use of the elicitation techniques discussed in Chapter 2).

1.1.3 The WHY, WHAT and WHO dimensions of requirements engineering

The preceding case-study descriptions give us a preliminary idea of the wide range of issues we need to consider in the RE process.

As noted before, the investigation of the problem world leads us to consider two versions of the system. The system-as-is has problems, deficiencies and limitations. For example, money is wasted in the UWON library system-as-is by the acquisition of duplicate or rarely used resources; access to bibliographical search facilities is severely limited in both time and location. In the WAX transportation system-as-is, flight connections are missed due to slow bus transportation and poor information to passengers. In the meeting scheduling system-as-is, meeting initiators are overloaded and meeting dates are not chosen well enough, which sometimes results in poor meeting attendance.

The system-to-be is intended to address those problems based on technology opportunities. It will do so only if the software-to-be and the organizational and physical components defining the environment are able to cooperate effectively. In the UWON library system-to-be, the new software has to cooperate effectively with environmental components such as patrons, staff, anti-theft devices, digital libraries and external library systems. In the WAX train system-to-be, the train-control software has to operate in conjunction with environmental components such as track sensors, train actuators, passengers, information panel devices and so forth. In the meeting scheduling system-to-be, the scheduler software has to cooperate effectively with environmental components such as meeting initiators and participants, e-mail systems, e-agenda managers, the communications network and so on. In the end, what really matters is the satisfactory working of the software-environment pair.

The problem world may thus be structured along three dimensions. We need to figure out why a system-to-be is needed, what needs must be addressed by it, and who in this system will take part in fulfilling such needs (see Figure 1.2).

The WHY dimension

The contextual reasons for a new version of a system must be made explicit in terms of objectives to be satisfied by it. Such objectives must be identified with regard to the limitations of the system-as-is and the opportunities to be exploited. This requires some careful analysis. What are those objectives precisely? What are their ramifications? How do they interact? How do they align with business objectives?

As we will see more thoroughly in subsequent chapters, such analysis along the WHY dimension is generally far from simple.

Acquiring domain knowledge We need to get a thorough understanding of the domain in which the problem world is rooted. This domain might be quite complex in terms of concepts, regulating laws, procedures and terminology. If you are not sufficiently convinced by the complexity of library management or meeting scheduling, think of domains such as air traffic control, proton therapy, power plants or stock exchanges. (Chapter 2 will present techniques to help us acquire domain knowledge.)

Evaluating alternative options in the problem world There can be alternative ways of satisfying the same identified objective. We need to assess the pros and cons of such alternatives in order to select the most preferable one. (Chapters 3 and 16 will present techniques to support this task.)

Example: Library management. We could satisfy the objective of extensive coverage of the literature through a non-selective journal subscription policy or, alternatively, through access to digital libraries. The two alternatives need to be evaluated in relation to their pros and cons. Example: Train control. We could satisfy the objective of avoiding train collisions by ensuring that there will never be two trains on the same block or, alternatively, by ensuring that trains on the same block will always be separated by some worst-case stopping distance. The pros and cons of each alternative must be assessed carefully. Example: Meeting scheduling. The objective of knowing the time constraints of invited participants could be satisfied by asking them their constraints via e-mail or, alternatively, by accessing their electronic agenda directly.

Evaluating technology opportunities We also need to acquire a thorough understanding of the oppportunities provided by technologies emerging in the domain under consideration, together with their implications and risks. For example, what are the strengths, implications and risks associated with digital libraries, driverless trains or e-agendas?

Handling conflicts The objectives that the system-to-be should satisfy are generally identified from multiple sources which have conflicting viewpoints and interests. As a result, there may be different perceptions of what the problems and opportunities are; and there may be different views on how the perceived problems should be addressed. In the end, a coherent set of objectives needs to emerge from agreed trade-offs. (Chapters 3, 16 and 18 will present techniques to support that task.)

Example: Library management. All parties concerned with the library system-to-be will certainly agree that access to state-of-the-art books and journals should be made more effective. There were sufficient complaints reported about this in the system-as-is. Conflicts are likely to arise, though, when this global objective is refined into more concrete objectives in order to achieve it. Everyone will acclaim the objective of improving the effectiveness of bibliographical search. However, university authorities are likely to emphasize the objective of cost reduction through integration of department libraries. Departments might be reluctant to accede to the implications of this, such as losing their autonomy. On the other hand, library staff might be concerned by strict enforcement of rules limiting library opening periods, the length of loan periods or the number of loans to the same patron. In contrast, library patrons might want much more flexible usage rules. Example: Train control. All parties will agree on the objectives of faster and safer transportation. Conflicts will, however, appear between the railway company management and the unions while exploring the pros and cons of alternative options with or without drivers, respectively.

(Continues...)

Excerpted from Requirements Engineeringby Axel van Lamsweerde Copyright © 2009 by Axel van Lamsweerde. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.