Engineering and Managing Software Requirements
Engineering and Managing
Software Requirements
Aybüke Aurum · Claes Wohlin (Eds.)
Engineering andManaging Software
Requirements With 54 Figures and 48 TablesEditors Aybüke Aurum School of Information Systems, Technology and Management University of New South Wales Sydney, NSW 2052, Australia aybuke@unsw.edu.au Claes Wohlin School of Engineering Blekinge Institute of Technology Box 520, 372 25 Ronneby, Sweden Claes.Wohlin@bth.se Library of Congress Control Number: 2005927220 ACM Computing Classification (1998): D.2.1, D.2.9, K.6.1
ISBN-10 3-540-25043-3 Springer Berlin Heidelberg New York
ISBN-13 978-3-540-25043-2 Springer Berlin Heidelberg New York
This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable for prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springeronline.com © Springer-Verlag Berlin Heidelberg 2005 Printed in Germany The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
Foreword Pericles Loucopoulos
The effects of integration and evolution of Information and Communication Tech- nologies (ICT) are having a profound effect on both the way that organizations function and people interact with each other. The increasing reliance of our every day activities on ICT systems demands sustainable service levels from such sys- tems commensurate with our expectations and levels of investment for their im- plementation. Such investments, however, have been regrettably risky and the mortality rates of ICT systems have been above average in any industry. Whilst the rate of failed projects and cost overruns has decreased in recent years bust still remaining unacceptably high over half of commissioned projects fail to meet their initial objectives. If we have been less than successful in delivering yesterday’s systems, what chance is there for developing tomorrow’s highly complex and de- manding systems?
Using the field of Requirements Engineering as their focal point, Aurum and Wohlin address this question in this book from a multidisciplinary perspective. As a field of intellectual endeavor and industrial practice Requirements Engineering has traditionally been concerned with goals for, functions of and constraints on software intensive systems. This book argues for a broader perspective in order to gain a better understanding of the interdependencies between enterprise stake- holders, processes and information systems that would in turn give rise to more appropriate techniques and higher quality systems.
It is this broader perspective that gives this book its distinct appeal and should be of interest not only to software engineers but also to researchers and practitio- ners working in other disciplines such as business process engineering, organiza- tional change, enterprise integration, and design theories and across many differ- ent business sectors. A common issue of concern across all these different areas is how one should tackle “ill-structured problems” where the problem state is not known at the outset and there is no definitive formulation, and where multiple stakeholders from different divisions and often different organizations need to reach agreement about the intended systems. Decisions taken at this stage have a profound effect on the technical and economic feasibility of the project. It is no longer appropriate for information systems professionals to focus only on func- tional and non-functional aspects of the intended system and somehow assume that organizational context and needs are outside their scope.
Here in these pages the reader will find a clear exposition of the processes in- volved in requirements together with a critique of current theories and practice. The book is thoughtfully assembled as a series of articles from leading researchers and practitioners, each article focusing on a specific issue. Whilst each article, presented as a distinct chapter, represents an important contribution in its own VI Foreword ments Engineering. I commend to you the journey that Aurum and Wohlin have begun for you with this book.
Author Biography
Pericles Loucopoulos holds the chair of Information Systems in the School of In- formatics, The University of Manchester. He is the co-editor-in-chief of the Jour-
nal of Requirements Engineering published by Springer and is on the editorial
board of five other international journals. He has served as General Chair and Pro- gramme Chair of six international conferences and has been a member of over 100 Programme Committees of international conferences. His research work is con- cerned with the engineering of information, and the tools, methods and processes used to design, develop and deploy information systems in order to meet organisa- tional goals. He works closely with industrial, commercial and governmental insti- tutions in improving the way that information systems could be deployed to im- plement change in an effective and efficient manner. He is the co-author of 6 books and the author and co-author of over 150 papers published in academic journals and conference proceedings.
Preface Aybüke Aurum and Claes Wohlin
This book explores the interdisciplinary nature of Requirements Engineering (RE) and portrays the current status of understanding, analyzing, modeling and manag- ing of RE activities for current as well as future systems, with particular emphasis on innovative ideas, frameworks and empirical studies, and future directions of RE practice.
Introduction
As we enter the third millennium, organizations have to cope with accelerating rates of change in technology and increased levels of competition on a global scale more than ever before. There is incredible pressure on companies to achieve and sustain competitive advantage. In order to stay competitive within this changing business environment, organizations are forced to constantly pursue new strategies to differentiate themselves from their competition, such as offering a stream of new products and services. Organizations in search of competitive advantage be- come more conscious of how software products have become a strategic asset to their business. Software companies, like many other organizations, are forced to adapt to the strategic challenges and opportunities presented by the new economy where new technology causes dramatic changes in business processes, products and services. Since software products play a vital role in supporting strategic chal- lenges and opportunities in business, it is important that these products function according to customers’ or markets’ requirements. Hence, an important task in software development is the identification and understanding of key business re- quirements to ensure that software products will fully support and evolve with the system.
Requirements Engineering (RE) is the process by which the requirements for software products are gathered, analyzed, documented, and managed throughout the SE lifecycle. RE is concerned with interpreting and understanding stake- holders’ goals, needs and beliefs. There are many problems associated with RE which may lead to inconsistent and incomplete requirements and cancellation of software projects. As RE is one of the main contributors to the success of software projects, improving the RE process can significantly increase the likelihood of software project success. Software developers realize that a strong requirements management process is essential to the successful completion of software projects. Furthermore, understanding, identifying and articulating the role of business re- quirements which are elicited from stakeholders from diverse backgrounds with different needs, expectations and goals is a challenge in RE. Quality management VIII Preface task in software development as it involves investigating and learning about the problem domain in order to develop a better understanding of stakeholders’ actual goals, needs, and expectations.
This book looks at software requirements from both engineering and manage- ment perspectives. We believe that RE is both an “engineering” and “manage- ment” activity. It is an engineering activity because it is concerned with identify- ing appropriate methodologies to develop software solutions and identifying cost effective ways of doing so. In other words, the aim of RE is to introduce engineer- ing principles into the practice of software systems analysis while integrating RE with a quality assurance process of utmost value to practitioners. Requirements change during the software development lifecycle and evolve after the system has become operational. Thus, RE is also a “management” activity as it is concerned with managing RE activities such as monitoring product requirements and manag- ing the project scope, cost and schedule throughout the software development process, while ensuring that all essential business applications are delivered as specified in different requirements documents on different levels, for example, product and project levels.
This book is intended to draw engineering and management perspectives to- gether to discuss the issues that face the RE in the third millennium.
Aims of the Book and Target Audience
Engineering and managing software requirements are key means for systematic software development. This book presents several examples of how this vision is supported by theory, as well as how to apply these solutions to industrial practice. Furthermore, it provides a collection of state-of-the-art RE research as well as in- formation about current industry practices. The intention is that the book should primarily function as a textbook for research students and researchers, although it should also be useful to undergraduate and graduate students as well as require- ments engineers operating in industry. The typical reader has most likely taken a basic course, read an introductory book to RE or worked with RE in industry for some time. Although it is recommended that readers have a sound background in software development, this book offers new insights into the software develop- ment process for both novice software developers as well as experienced profes- sionals.
Book Overview
This book is organized into three major parts. Each part contains five to seven chapters. In addition, Chap. 1 provides an exploration of some of key issues in re- quirements engineering. This includes offering an understanding of the different
Preface IX role of different stakeholders in requirements engineering. Chapter 1 also demon- strates how the three parts of this book are interrelated. Although it is preferable to firstly familiarize yourself with the first chapter, the book is designed to permit reading of the parts in any order, depending on readers’ interests.
Part 1: State-of-the-Art Surveys of Requirements Engineering Process
Research Part 1 of this book provides a general introduction to the field of RE. It aims toenable readers to understand the motivation behind RE activities. The objective is to illustrate the strengths as well as weaknesses of this discipline and, as such, this part will present surveys of state-of-the art RE process research along with critical assessments of existing models, frameworks and techniques. Part 1 contains a col- lection of articles and up-to-date survey chapters that address the phases of the RE process, namely, requirements elicitation and capturing, modeling and specifica- tion, prioritization, dependencies, impact analysis, negotiation and quality assur- ance.
Part 2: The Next Practice in Requirements Engineering Building complex systems is still a challenge for software developers. The techno-
logical improvements in the global market are closely related to business envi- ronments. New concepts such as enterprise systems, e-business and telecommuni- cations have led to new trends for researchers and practitioners. The growth in strategic importance of IT implies that tools, techniques and processes need to be integrated with software system requirements so that they are aligned with the strategic business objectives and business model of the organizations they support.
Part 2 covers articles that address new trends in RE. Topics covered in this part in- clude market-driven requirements, decision support and decision making in RE, RE for agile methods, goal modeling, web-based information systems, require- ments ambiguity and use of natural language in RE.
Part 3: Studies and Industrial Experience Empirical research compares theory to reality, helping us draw conclusions and to
evaluate new methods and tools. It is also important to learn more about technolo- gies used in industrial practice. Part 3 concludes the book with articles that present empirical evidence. The studies in this part report on RE solutions and practices. This part focuses on state-of-the-practices that address overall RE issues including industrial experience, non-functional requirements and RE metrics.
X Preface
Acknowledgements There are many people whom we would like to thank for their help and support.
We wish to thank all the authors for their hard work and effort in creating this book. We are especially grateful to the following colleagues who participated in the external review process and for their valuable comments: Mark Staples, Karl Cox, Cat Kutay, Paul Bannerman, Niazi Mahmoud, Jenny Liu, from National ICT Australia; Ghassan Beydoun and Ken Stevens from University of New South Wales, Australia.
We would also like to thank Kerrie Miller and Max Mail for their assistance in formatting this book and Irem Sevinç for assisting with proofreading. Special thanks go to Ralf Gerstner of Springer Germany for providing professional advice during the publishing process. Finally, a big thank you is due to our families for enduring the lengthy editing process. This book is dedicated to our families.
Contents List of Contributors............................................................................................. XV
1 Requirements Engineering: Setting the Context .............................................. 1
1.1 Introduction.................................................................................................... 1
1.2 Background.................................................................................................... 3
1.3 The Role of Stakeholders in Requirements Engineering.............................. 6
1.4 Different Levels of Requirements................................................................. 7
1.5 Requirements Management........................................................................... 9
1.6 New Trends and the Next Practice.............................................................. 11
1.7 Empirical Evidence ..................................................................................... 12
1.8 Conclusion ................................................................................................... 12
Part 1 State-of-the-Art Surveys of Requirements Engineering Process Research ................................................................................................................. 17
2 Requirements Elicitation: A Survey of Techniques, Approaches
and Tools ................................................................................................................ 192.1 Introduction.................................................................................................. 19
2.2 What is Requirements Elicitation?.............................................................. 21
2.3 Techniques and Approaches for Requirements Elicitation ........................ 25
2.4 Methodology Based Requirements Elicitation ........................................... 34
2.5 Tool Support for Requirements Elicitation................................................. 35
2.6 Issues and Pitfalls of Requirements Elicitation .......................................... 36
2.7 Trends and Challenges in Requirements Elicitation................................... 38
2.8 Future Directions in Requirements Elicitation Research ........................... 41
2.9 Summary...................................................................................................... 41
3 Specification of Requirements Models............................................................. 47
3.1 Introduction.................................................................................................. 47
3.2 Modeling vs. Specification.......................................................................... 48
3.3 Meta-models Categories.............................................................................. 50
3.4 Specification Methodology ......................................................................... 56
3.5 Requirements Transformation..................................................................... 59
3.6 Conclusion ................................................................................................... 64
4 Requirements Prioritization.............................................................................. 69
4.1 Introduction.................................................................................................. 69
4.2 What is Requirements Prioritization? ......................................................... 70
4.3 Aspects of Prioritization.............................................................................. 72
4.4 Prioritization Techniques ............................................................................ 75
4.5 Involved Stakeholders in the Prioritization Process ................................... 79
XII Contents
5 Requirements Interdependencies: State of the Art and Future ................... 95
5.1 Introduction ................................................................................................. 95
5.2 Requirements Traceability: a Basis for Understanding Requirements Interdependencies .............................................................................................. 96
5.3 An Overview of Interdependency Types .................................................. 100
5.4 How can Knowledge about Requirements Interdependencies Facilitate Software Engineering? .................................................................................... 105
5.5 Research Issues.......................................................................................... 109
5.6 Summary.................................................................................................... 113
6 Impact Analysis ................................................................................................ 117
6.1 Introduction ............................................................................................... 117
6.2 Strategies for Impact Analysis .................................................................. 124
6.3 Non-Functional Requirements .................................................................. 130
6.4 Impact Analysis Metrics............................................................................ 131
6.5 Tool Support.............................................................................................. 137
6.6 Future of Impact Analysis......................................................................... 138
6.7 Summary.................................................................................................... 139
7 Requirements Negotiation............................................................................... 143
7.1 Introduction ............................................................................................... 143
7.2 The Negotiation Process............................................................................ 145
7.3 Dimensions of Requirements Negotiation................................................ 148
7.4 Examples of Negotiation Systems ............................................................ 154
7.5 Conclusions ............................................................................................... 158
8 Quality Assurance in Requirements Engineering ........................................ 163
8.1 The Importance of Early Quality Assurance ............................................ 163
8.2 Requirements and Quality Assurance....................................................... 165
8.3 Constructive Approaches .......................................................................... 172
8.4 Analytical Approaches .............................................................................. 175
8.5 Open Research Questions ......................................................................... 180
8.6 Conclusion................................................................................................. 182
Part 2 The Next Practice in Requirements Engineering ................................ 187
9 Modeling Goals and Reasoning with Them .................................................. 189
9.1 Introduction ............................................................................................... 189
9.2 State-of-the-Art Review ............................................................................ 190
9.3 Goal/Strategy Maps................................................................................... 199
9.4 Conclusion................................................................................................. 211
10 Managing Large Repositories of Natural Language Requirements ........ 219
10.1 Introduction ............................................................................................. 219
Contents XIII
10.5 Case 1: Keeping the Repository in Shape............................................... 228
10.6 Case 2: Linking Customer Wishes to Product Requirements ................ 232
10.7 Case 3: Managing Redundant Customer Requests................................. 236
10.8 Conclusions.............................................................................................. 240
11 Understanding Ambiguity in Requirements Engineering ......................... 245
11.1 Introduction ............................................................................................. 245
11.2 Related Work........................................................................................... 247
11.3 A New Definition of Requirements Ambiguity...................................... 248
11.4 Ambiguity in RE Processes..................................................................... 250
11.5 Detection of Ambiguity in Requirements Inspection ............................. 257
11.6 How to Live with Ambiguity .................................................................. 263
11.7 Summary and Conclusion ....................................................................... 264
12 Decision Support in Requirements Engineering ........................................ 267
12.1 Introduction ............................................................................................. 267
12.2 Basic Concepts ........................................................................................ 268
12.3 Decision Support versus Decision Making............................................. 273
12.4 Analysis of Research ............................................................................... 275
12.5 Conclusion and Future Research............................................................. 281
13 Market-Driven Requirements Engineering for Software Products ......... 287
13.1 Introduction ............................................................................................. 287
13.2 Concepts and Context.............................................................................. 289
13.3 The MDRE Process ................................................................................. 293
13.4 MDRE Data Management....................................................................... 296
13.5 Market Analysis and Requirements Elicitation ...................................... 300
13.6 Roadmapping and Release Planning....................................................... 301
13.7 Conclusion ............................................................................................... 304
14 Requirements Engineering for Agile Methods ........................................... 309
14.1 Introduction ............................................................................................. 309
14.2 Agile Methods ......................................................................................... 310
14.3 Traditional and Agile Requirement Engineering.................................... 315
14.4 Agile Approaches to Requirements Engineering.................................... 316
14.5 Role and Responsibility of Customers, Developers, and Managers ...... 321
14.6 Tools for Requirements Management in AMs ....................................... 322
14.7 Conclusions.............................................................................................. 323
15 Requirements Engineering for Web-Based Information Systems ........... 327
15.1 Introduction ............................................................................................. 327
15.2 Approaches to RE for Development of WBIS........................................ 329
15.3 Significance of Concerns in Requirements Engineering........................ 334
15.4 A Model of Concern-Driven Requirements Evolution........................... 339
XIV Contents
16 Requirements Engineering: A Case of Developing and Managing
Quality Software Systems in the Public Sector................................................ 353
16.1 Introduction ............................................................................................. 353
16.2 The ABS Case Study Setting .................................................................. 354
16.3 Governance of ABS Software Development.......................................... 356
16.4 The ABS Software Development Process .............................................. 358
16.5 The ABS Software Requirements Phase ................................................ 360
16.6 Some Examples of ABS Software .......................................................... 365
16.7 What can We Learn From the ABS? ...................................................... 367
17 Good Quality Requirements in Unified Process......................................... 373
17.1 Introduction ............................................................................................. 373
17.2 Background.............................................................................................. 374
17.3 Practice .................................................................................................... 375
17.4 Evaluation................................................................................................ 377
17.5 Conclusions ............................................................................................. 401
18 Requirements Experience in Practice: Studies of Six Companies............ 405
18.1 Introduction ............................................................................................. 405
18.2 Studied Companies.................................................................................. 406
18.3 Methodology............................................................................................ 407
18.4 Assessment Findings............................................................................... 413
18.5 Comparison with State of Practice Surveys............................................ 418
18.6 Discussion................................................................................................ 421
18.7 Conclusions ............................................................................................. 424
19 An Analysis of Empirical Requirements Engineering Survey.................. 427
19.1 Introduction ............................................................................................. 427
19.2 Empirical Research.................................................................................. 428
19.3 Classification of Existing Broad RE Studies.......................................... 429
19.4 Broad Studies Outcomes ......................................................................... 436
19.5 Requirements Engineering Practice: A New Study................................ 442
19.6 Remarks on Empirical RE Research....................................................... 445
19.7 Conclusion............................................................................................... 446
20 Requirements Engineering: Solutions and Trends .................................... 453
20.1 Introduction ............................................................................................. 453
20.2 A Requirements Engineering Framework: Available Solutions............ 454
20.3 Trends in Requirements Engineering ..................................................... 460
20.4 Conclusions and Outlook ........................................................................ 473
Index ..................................................................................................................... 477
List of Contributors Anneliese K. Amschler Andrews
Department of Software Engineering Faculty of Information Technology University of Technology, Sydney P O Box 123 Broadway NSW 2007, Australia Email: chadc@it.uts.edu.au
Christof Ebert
Fraunhofer Institute for Experimental Software Engineering Sauerwiesen 6 D-67661 Kaiserslautern, Germany Email: denger@iese.fhg.de
Christian Denger
School of Humanities and Informatics University of Skövde Box 408 SE-541 28 Skövde, Sweden Email: asa.dahlstedt@his.se
Åsa G. Dahlstedt
School of Information Systems Faculty of Business and Law Deakin University Burwood, Vic 3125, Australia Email: jlcybuls@deakin.edu.au
Jacob L. Cybulski
Chad Coulin
School of Electrical Engineering and Computer Science Washington State University PO Box 642752 Pullman, WA 99164-2752, USA Email: aandrews@eecs.wsu.edu
Institute of Information and Computing Sciences Utrecht University P.O. Box 80.089 3508 TB Utrecht The Netherlands Email: S.Brinkkemper@cs.uu.nl
Sjaak Brinkkemper
Institute for Computer Science University of Heidelberg Im Neuenheimer Feld 326 D-69120 Heidelberg, Germany Email: lars.borner@informatik.uni- heidelberg.de
Lars Borner
Department of Systems and Software Engineering School of Engineering Blekinge Institute of Technology Box 520 SE-372 25 Ronneby, Sweden Email: patrik.berander@bth.se
Patrik Berander
School of Information Systems, Technology and Management University of New South Wales Sydney NSW 2052 Australia Email: aybuke@unsw.edu.au
Aybüke Aurum
Alcatel 54 rue La Boetie, 75008 Paris, France Email: Christof.Ebert@alcatel.com XVI List of Contributors
João M. Fernandes
Department of Systems and Software Engineering School of Engineering Blekinge Institute of Technology Box 520 SE-372 25 Ronneby, Sweden Email: per.jonsson@bth.se
Pericles Loucopoulos
Fraunhofer USA University of Maryland 4321 Hartwick rd, suite 500 College Park, MD 20740, USA Email: mikli@fc-md.umd.edu>
Mikael Lindvall
Fraunhofer Institute Experimental Software Engineering Sauerwiesen 6 D-67661 Kaiserslautern, Germany Email: Tom.Koenig@iese.fraunhofer.de
Tom Koenig
Institute for Computer Science and Business Information Systems (ICB) University of Duisburg-Essen Schuetzenbahn 70 D-45117 Essen, Germany Email: kamsties@sse.uni-essen.de
Erik Kamsties
Per Jönsson
Dept. Informatica Universidade do Minho, Campus de Gualtar 4700-320 Braga, Portugal Email: jmf@di.uminho.pt
Systems Engineering & Automation Johannes Kepler University Linz Altenbergerstr. 69 4040 Linz, Austria Email: pg@sea.uni-linz.ac.at
Paul Grünbacher
School of Business and Information Management Faculty of Economics and Commerce Hanna Neumann Building 021 Australian National University ACT 0200 Australia Email: shirley.gregor@anu.edu.au
Shirley Gregor
Department of Systems and Software Engineering School of Engineering Blekinge Institute of Technology Box 520 SE-372 25 Ronneby Sweden Email: tony.gorschek@bth.se
Tony Gorschek
Dipartimento di Informatica via F. Buonarroti, 2 I-56127 Pisa, Italy Email: gervasi@di.unipi.it
Vincenzo Gervasi
School of Informatics The University of Manchester P.O. Box 88 Manchester M60 1QD, UK Email: p.loucopoulos@manchester.ac.uk
List of Contributors XVII
Anne Persson
Camille Salinesi
University of Calgary 2500 University Drive NW Calgary, Alberta, Canada T2N 1N4 Email: ruhe@ucalgary.ca
Guenther Ruhe
Centre de Recherche en Informatique Université Paris 1 - Panthéon Sorbonne 90, rue de Tolbiac, F-75013 Paris, France Email: Colette.Rolland@univ-paris1.fr
Colette Rolland
Dept. of Communication Systems Lund University Box 118 SE-221 00 Lund, Sweden Email: bjorn.regnell@telecom.lth.se
Bjorn Regnell
Dept. Sistemas de Informacao Universidade do Minho, Campus de Azurem 4800-058 Guimaraes, Portugal Email: iramos@dsi.uminho.pt
Isabel Ramos
School of Humanities and Informatics University of Skövde Box 408 SE-541 28 Skövde Sweden Email: anne.persson@his.se
Institute for Computer Science University of Heidelberg Im Neuenheimer Feld 326 D-69120 Heidelberg, Germany Email: paech@informatik.uni-heidelberg.de
Ricardo J. Machado
Barbara Paech
Fraunhofer Institute of Experimental Software Engineering Sauerwiesen 6 67661 Kaiserslautern, Germany Email: olsson@iese.fhg.de
Thomas Olsson
Laboratory of Software Engineering Decision Support University of Calgary 2500 University Drive NW Calgary, Alberta, Canada T2N 1N4 Email: ango@cpsc.ucalgary.ca
An Ngo-The
Dept. of Communication Systems Lund University Box 118, SE-221 00 Lund, Sweden Email: johan.nattochdag@telecom. lth.se
Johan Natt och Dag
14 Derham Court Wanniassa, Canberra ACT 2903 Australia Email: Nigel.Martin@defence.gov.au
Nigel Martin
Dept. Sistemas de Informacao Universidade do Minho, Campus de Azurem 4800-058 Guimaraes, Portugal Email: rmac@dsi.uminho.pt
Centre de Recherche en Informatique Université Paris 1 - Panthéon Sorbonne 90, rue de Tolbiac, F-75013 Paris, France Email: Camille.Salinesi@univ-paris1.fr XVIII List of Contributors
Pradip K. Sarkar
Roel Wieringa
Didar Zowghi
ABB AB Corporate Research SE-721 78 Västerås, Sweden Email: nur.yilmazturk@se.abb.com
Nur Yilmaztürk
Department of Systems and Software Engineering School of Engineering Blekinge Institute of Technology Box 520, SE-372 25 Ronneby, Sweden E-mail: claes.wohlin@bth.se
Claes Wohlin
Dept. of Computer Science, Faculty of Electrical Eng., Mathematics and Computer Science, University of Twente, PO Box 217, 7500 AE Enschede, Netherlands; Email: R.J.Wieringa@ewi.utwente.nl
Department of Systems and Software Engineering School of Engineering Blekinge Institute of Technology Box 520 SE-372 25 Ronneby Sweden Email: mikael.svahnberg@bth.se
School of Information Systems, Deakin University, 221 Burwood Highway, Burwood, Vic 3125, Australia Email: pks1@deakin.edu.au
Mikael Svahnberg
Center for Applied Software Engineering Faculty of Computer Science Free University of Bozen Piazza Domenicani 3, I-39100 Bolzano, Italy Email: Giancarlo.Succi@unibz.it
Giancarlo Succi
Center for Applied Software Engineering Faculty of Computer Science Free University of Bozen Piazza Domenicani 3, I-39100 Bolzano, Italy Email: Alberto.Sillitti@unibz.it
Alberto Sillitti
Systems Engineering & Automation Johannes Kepler University Linz Altenbergerstr. 69 4040 Linz, Austria Email: ns@sea.uni-linz.ac.at
Norbert Seyff
Department of Software Engineering Faculty of Information Technology University of Technology, Sydney P O Box 123 Broadway NSW 2007 Australia Email: didar@it.uts.edu.au
1 Requirements Engineering: Setting the Context
Aybüke Aurum and Claes Wohlin
Abstract: This chapter presents a brief overview of requirements engineering and
provides an introduction to some of the critical aspects of this field. This includes offering and understanding of the different levels of requirements involved in re- quirements engineering, namely organizational, product and project level require- ments, and illustrating the role of different stakeholders in requirements engineer- ing. The chapter also aims to demonstrate how the three parts of this book are interrelated.
Keywords : Requirements management, Business requirements, Product require-
ments, Project requirements, Stakeholders, Requirements taxonomy.1.1 Introduction
The objective of this chapter is twofold. First, it aims to provide a brief introduc- tion to requirements engineering, and secondly it aims to set a common context for the other chapters of the book. This introductory chapter is provided to set the stage for the remaining chapters and highlight some of the important areas covered by this book. The remaining chapters require a basic understanding of require- ments engineering to benefit from the deeper insights provided. These chapters are divided into three parts, each with a different focus, as shown in the table of con- tents and described briefly in the Preface.
Requirements engineering is accepted as one of the most crucial stages in soft- ware design and development as it addresses the critical problem of designing the right software for the customer. Requirements engineering is increasingly becom- ing a set of processes that operates on different levels, including organizational, product and project levels. Furthermore, it is a continuous process on organiza- tional and product levels and a process limited in time on the project level. How- ever, most requirements engineering research to date is devoted to handling re- quirements on the project level, making this the main focus of this chapter. The different levels are revisited in Sect. 1.4. Requirements engineering on the project level is the process by which the requirements for a software project are gathered, documented and managed throughout the software development lifecycle.
The development of a software requirements specification is widely recognized as the bases of system functionality. Software requirements are the critical deter- minants of software quality, given empirical studies showing that errors in re- quirements are the most numerous in the software life-cycle and also the most ex- pensive and time-consuming to correct. According to the Standish group report in
2 Aurum and Wohlin challenged projects were implemented. The study demonstrates that only 16.1% of all US software projects are developed on-schedule, on-budget and with all origi- nally planned features, while 31.1% of projects are terminated before completion. It was also observed that the average project is delivered at approximately three times the budget and in three times the scheduled time.
Such poor figures lead to questioning the causes of these deficiencies. Often these problems are a result of inadequate requirements [25]. According to a survey conducted with 350 organizations in the USA (with over 8000 projects), one third of the projects were never completed and one half succeeded only partially. About half of the managers interviewed identified poor requirements as a major source of problems, along with other factors such as low user involvement and unclear ob- jectives. Similarly, according to another survey which was conducted with 3800 organizations from over 17 countries in Europe, most problems are in the area of requirements specifications (50%) and requirements management (50%) [18]. In 1999, the Standish group report [11] revealed that three of the top ten reasons for “challenged” projects and project failure were lack of user involvement, unstable requirements and poor project management. In a 2001 report, while user involve- ment was no longer a key concern, unstable requirements and poor project man- agement remained amongst the primary reasons for project failure [12].
In a more recent survey of twelve UK companies’ requirements problems ac- counted for 48% of all software problems [20]. In one of the case studies, Tveito and Hasvold [38] observed that there was a huge gap between the day to day op- erations of a hospital and software developers’ domain knowledge of these opera- tions, though every year healthcare organizations spend large amounts of money and resources on IT systems. Tveito and Hasvold argue that this gap is due to in- sufficient requirements gathering and misunderstanding requirements due to the lack of domain knowledge.
These facts and figures only depict the sad reality of “software depression”. Furthermore, the cost of repairing requirements-related problems dramatically in- creases as the software development process progresses. A study by Boehm and Papaccio [6] revealed that it costs US$1 to locate and fix an error in the require- ments definition stage, US$5 in the design phase, US$10 in the coding phase, $20US during unit testing, and up to US$200 after system delivery. It is therefore evident that the RE process has important ramifications for the overall success of a software project. Although the above example dates back just over 15 years, the ratio remains the same today.
Requirements engineering is concerned with the identification of goals for a proposed system, the operation and conversion of these goals into services and constraints, as well as the assignment of responsibilities for the resulting require- ments to agents such as humans, devices and software. Requirements engineering has now moved from being the first phase in the software development lifecycle to a key activity that spans across the entire software development lifecycle in many organizations. New products or new releases of products are entering the market or delivered to customers at an increasingly faster pace. In order to improve re-
1 Requirements Engineering: Setting the Context 3 esses is an important step towards improving requirements engineering practices and therefore increasing the success of software projects [31].