Introduction

Abstract

Brooks’ statement still holds true (Brooks 1987, p. 17): The hardest single part of building software is deciding what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Getting requirements right may be the single most important and difficult part of a software project (Guinan et al. 1998, Merlyn and Parkinson 1994). The process of getting requirements right is the focus of this work. We will first provide some examples to illustrate its importance for delivering quality software. Then we will outline our understanding of the basic terminology underlying the evolving field of requirements engineering. Before we present the objectives of this work (Chapter 1.4. Objectives), we will discuss some widely held myths about requirements engineering. Finally, we will provide an overview of the remaining chapters.