Requirements Engineering: From System Goals to UML Models to Software Specifications - Softcover

Van Lamsweerde, Axel

Softcover

ISBN 10: 0470012706 ISBN 13: 9780470012703

Verlag: Wiley, 2009

Inhaltsangabe

The book presents both the current state of the art in requirements engineering and a systematic method for engineering high-quality requirements, broken down into four parts.  The first part introduces fundamental concepts and principles including the aim and scope of requirements engineering, the products and processes involved, requirements qualities to aim at and flaws to avoid, and the critical role of requirements engineering in system and software engineering.

The second part of the book is devoted to system modeling in the specific context of engineering requirements. It presents a multi-view modeling framework that integrates complementary techniques for modeling the system-as-is and the system-to-be. The third part of the book reviews goal-based reasoning techniques to support the various steps of the KAOS method. The fourth part of the book goes beyond requirements engineering to discuss the mapping from goal-oriented requirements to software specifications and to software architecture.

Online software will accompany the book and will add value to both classroom and self-study by enabling students to build models and specifications involved in the book’s exercises and case studies, helping them to discover the latest RE technology solutions. Instructor resources such as slides, figures and handouts are available from an accompanying website.

Über diesen Titel

Ü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

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

From System Goals to UML Models to Software SpecificationsBy Axel van Lamsweerde

John Wiley & Sons

Copyright © 2009 Axel van Lamsweerde
All right reserved.
ISBN: 978-0-470-01270-3

Chapter One

Setting the Scene

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...

Details zur Ausgabe

• Verlag: Wiley
• Erscheinungsdatum: 2009
• Sprache: Englisch
• ISBN 10: 0470012706
• ISBN 13: 9780470012703
• Einband: Taschenbuch
• Auflage: 1
• Anzahl der Seiten: 714
• Kontakt zum Hersteller: Wiley-VCH GmbH; product_safety@wiley.com; ; Boschstrasse 12; Weinheim; 69469; Deutschland