Design Requirements Engineering: A Ten-Year Perspective Design Requi
Since its inception in 1968, software engineering has undergone numerous changes. In the early years, software development was organized using the waterfall model, where the focus of requirements engineering was on a frozen requirements document, which fo
- PDF / 258,110 Bytes
- 11 Pages / 430 x 659.996 pts Page_size
- 103 Downloads / 217 Views
14
Kalle Lyytinen Pericles Loucopoulos John Mylopoulos Bill Robinson (Eds.)
Design Requirements Engineering: A Ten-Year Perspective Design Requirements Workshop Cleveland, OH, USA, June 3-6, 2007 Revised and Invited Papers
13
Volume Editors Kalle Lyytinen Case Western Reserve University, Cleveland, OH, USA E-mail: [email protected] Pericles Loucopoulos Loughborough University, UK E-mail: [email protected] John Mylopoulos University of Toronto, ON, Canada E-mail: [email protected] Bill Robinson Georgia State University, Atlanta, GA, USA E-mail: [email protected]
Library of Congress Control Number: 2008942723 ACM Computing Classification (1998): D.2.1, D.2.10, D.2.11, K.6.1 ISSN ISBN-10 ISBN-13
1865-1348 3-540-92965-7 Springer Berlin Heidelberg New York 978-3-540-92965-9 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, re-use of illustrations, recitation, broadcasting, reproduction on microfilms 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 to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2009 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12602377 06/3180 543210
Foreword
The critical nature of requirements was recognized around the time that the term software engineering was being coined to signal the need for a new discipline [NATO Software Engineering Conference, 1968]. In those early years, the focus of requirements practice was on the requirements document, which was the basis of a contract between customer and developer, which needed to be sufficiently definitive to determine, before system construction, what needed to be built, how much it might cost, and how long it might take to complete and put into operation. Requirements tended to change (or “creep”) until arbitrarily “frozen” so that agreement could finally be reached and the development project could begin. When the development project was over, the resulting system was evaluated to see if the contract was fulfilled. The approach is very disciplined, but the reality is that it has been bent and is broken. As software companies and IT departments grew, it was obvious that requirements were a major weak link in the business of software. Early studies and experience reports tried to put their finger on the problem, stating that requirements were often ambiguous, inconsistent, incomplete, missing, or just plain wrong. This recognition led to the emergence of requirements languages, tools, and techniques, as reported in workshops such as the International Workshop on Software Specifications &
Data Loading...
