Perspectives on Software Requirements PDF
Preview Perspectives on Software Requirements
PERSPECTIVES ON SOFTWARE REQUIREMENTS THE KLUWER INTERNATIONAL SERIES IN ENGINEERING AND COMPUTER SCIENCE PERSPECTIVES ON SOFTWARE REQUIREMENTS edited by lulio Cesar Sampaio do Prado Leite Potificia Universidade Cat6lica do Rio de Janeiro Brazii Jorge Horacio Doorn Universidad Nacional del Centro de la Provincia de Buenos Aires Universidad Tecnol6gica Nacional, Facultad Regional Buenos Aires Argentina SPRINGER SCIENCE+BUSINESS MEDIA, LLC Library of Congress Cataloging-in-Publication PERSPECTIVES ON SOFrWA RE REQUIREMENTS Julio Cesar Sampaio do Prado Leite and Jorge Haracio Doom ISBN 978-1-4613-5090-3 ISBN 978-1-4615-0465-8 (eBook) DOI 10.1007/978-1-4615-0465-8 Copyright © 2004 by Springer Science+Business Media New York Originally published by Kluwer Academic Publishers in 2004 Softcover reprint of the hardcover 1s t edition 2004 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photo-copying, microfilming, recording, or otherwise, without the prior written permission ofthe publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Permissions for books published inthe USA: [email protected] Permissions forbooks published in Europe: [email protected] Printed an acid-free paper. TABLE OF CONTENTS Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. VII Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix 1. Perspectives on Software Requirements: An Introduction. 1 Julio Cesar Sampaio do Prado Leite and Jorge Horacio Doom 2. Ambiguity in Requirements Specification ....••....•.. 7 Daniel M. Berry and Erik Kamsties 3. Task-Driven Requirements in Object-Oriented ........ 45 Development Barbara Paech and Kirstin Kohler 4. Surfacing Requirements Interactions •..........•.... 69 William N. Robinson 5. Requirements Traceability ••••............•..•..••. 91 Francisco A. C. Pinheiro 6. Non-Functional Requirements Elicitation .•..•....... 115 Luiz Marcio Cysneiros and Eric Yu VI 7. Requirements Engineering in the Information ....•...• 139 Assurance Domain: The Common Criteria Evaluation Process Ruben Prieto-Diaz 8. Defining System Context Using Scenarios. . • • • • • • • • . • 169 Julio C. Sampaio do Prado Leite, Jorge H. Doorn, Gladys N. Kaplan, Graciela D. S. Hadad and Marcela N. Ridao 9. Semi Automatic Generation of User Interface. . • • • • . .• 201 Prototypes from Early Requirement Models Juan Sanchez Diaz, Oscar Pastor L6pez, Hugo Estrada Esquivel, Alicia Martinez Rebollar and Jorge Belenguer Faguas 10. Strategically Defining and Exploiting Product. • . . • . • . 223 Portfolios with a Product Line Approach Klaus Schmid 11. Agent-Driven Requirements Engineering. . . . . • . . • . . • 253 Jaelson Castro, John Mylopoulos and Carla Silva Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 PREFACE Requirements engineering is a field of knowledge concerned with the systematic process of eliciting, modelling and analysing requirements. Requirements engineering is usually understood in relation with software system requirements, but most of its principles and some of its techniques can be adapted to other problems dealing with complex sets of requirements. The engineering vision indicates that the field should provide a practical and well-defined process where trade-offs have to be considered to obtain the best results. Mature software development needs mature requirements engineering. This was true ten years ago when requirements engineering became an important component of the software development process and it is still true today when the pressure to deliver code on time and on budget is increasing and the demand for higher quality software also increases. Many contributions were done to this field during the last decade, but many others are still needed. We foresee two main reasons why this will happen: i) we believe that there are still several problems related to specific domains and a lack of organized knowledge for general crosscutting requirements; ii) the context in which software is developed is a fast changing arena where new technologies appear and disappear and stakeholders change their expectations. The objective of this book is to give some perspectives on several current approaches to software requirements. Each chapter addresses a specific problem where authors summarize their experiences and results in the area. Chapters lightening well-known issues with the results of recent results and experiences are accompanied with chapters describing well-tuned new methods for specific domains. We hope researchers in the field of requirements engineering will appreciate this book. We understand that software and system engineering practitioners will also find important knowledge in this book. Julio Cesar Sampaio do Prado Leite Jorge Horacio Doom viii ACKNOWLEDGMENTS Julio Cesar Sampaio do Prado Leite: I believe that this book started with the cooperation of Departamento de Informatica of PUC-Rio and Universidad de Belgrano. It was the support from Universidad de Belgrano that made possible the cooperation reflected in Chapter 8. This cooperation was started by Gustavo Rossi and Alejandro Oliveros. I would also like to thank Lopez Saubidet who was responsible for the research unit at University of Belgrano. I thank them for the opportunity they gave me to be in Buenos Aires so many times. Buenos Aires inspired most of our work on scenarios; in particular with instantiations of restaurant scenarios, with its amazing good food and very good Argentinean wine. The continuing support of CNPq, the Brazilian Research Agency, is very much appreciated as well as the brief but important support from Faperj by the award Cientista do Nosso Estado. The CYTED-CNPq project WEST made it possible to maintain the links with the Ibero American research community and, as such, helped to produce this volume. I wrote this Preface when at University of Toronto on a sabbatical leave from PUC-Rio, so I also acknowledge the support of CAPES and the support of the John Mylopoulos's group at the Department of Computer Science of University of Toronto. Last but not least, I wish to thank the twenty two authors who wrote for this book. Jorge Horacio Doorn: I am grateful to Alejandro Oliveros for inducing me to participate in the cooperation project between Universidad de Belgrano and Departamento de Informatica of PUC-Rio. I am specially grateful to the many people who contributed with ideas throughout the original project and its continuation at Universidad Tecnol6gica Nacional, Facultad Regional Buenos Aires. I particularly acknowledge to Marcela Ridao for her invaluable help during the edition of this book. Chapter 1 PERSPECTIVES ON SOFTWARE REQUIREMENTS: AN INTRODUCTION Julio Cesar Sampaio do Prado Leitel and Jorge Horacio Doorn2•3 I Pontificia Universidade Cat6lica do Rio de Janeiro - PUC-Rio lINTIA, Universidad Nacional del Centro de la Provincia de Buenos Aires 3 Facultad Regional Buenos Aires, Universidad Tecnol6gica Nacional Requirements engineering is a young field. Nonetheless it is maturing very quickly. The first gathering of researchers to discuss the engineering of requirements did happen in 1993 with the IEEE International Symposium on Requirements Engineering. This meeting was important since for the first time requirements was seen as a frontier field in computer science, but with strong links to other sciences, as well. In particular, the community started to recognize the importance of elicitation [2] as something to be seen as research topic as well as the topics of modelling and analysis. Software engineering associates the word "requirements" with the beginning of the software production. A software product will be built according to its requirements. Experience from the real world and research have pointed out that an unclear understanding of the "requirements" will lead to several problems in the software construction process. It is well accepted in software engineering that an investment on the engineering of requirements is justifiable as a way of avoiding future problems, or changes in the software process. Several data are often cited showing that correcting an error at the beginning of the software process is less expensive than to correct this error later on. Numbers vary from 1 to 20 to 1 to 200 if evolution is considered. There are also several accounts that report that a large chunk of the errors after deployment of a new or enhanced system can be traced to a misunderstanding of the real requirements. Of course, that one of the aims of requirements engineering is making requirements easy to understand to both those who required them, as well as to those who will implement them. Despite the apparent convincing argument, engineering requirements are not always taken as a priority in the process of software construction. However, recent J. C. S. Prado Leite et al. (eds.), Perspectives on Software Requirements © Kluwer Academic Publishers 2004 2 Perspectives on Software Requirements trends from industry are starting to show some change. The most difficult barriers to introduce requirements engineering practices are: market pressure, lack of knowledge about the discipline of requirements engineering and evolution. Recent developments from industry have produced a considerable number of tools to deal with requirements. Standard bodies like the Software Engineering Institute and the International Standards Organization are also important pushers in the direction of requirements engineering institutionalisation. However, even those bodies are still learning how to deal with requirements processes. For instance; the new CMMI directives now propose two key areas: Requirements Management and Requirements Development. This is an advance since with just Requirements Management as a key area, it did not use to provide practitioners with enough information on how to engineer requirements. The use of the word engineering in the field of requirements has brought some discussion. Some have argued that it is not a proper usage of the term engineering. Although we do not believe this discussion to be relevant, it is worth noting that requirements engineering, as dealt in this book, is, in reality, software requirements engineering. On the other hand, requirements engineering as a discipline can contribute to other production oriented processes as well, and as such it will be closer to systems engineering. Requirements engineering may be practiced in different settings. It can be applied to better select an existing package or a COTS, to evolve existing legacy systems, or to specific clients. It can also be employed when the clients are hidden in what is usually called the market. As such, requirements engineers must be aware that a requirements process is context sensitive. We understand the process of requirements engineering as of one responsible for producing the definition of a software product. We believe it can be seen as a process composed of three main sub-processes: elicitation, modelling and analysis. This process is perennial over the entire software process and should be managed accordingly. As such, management is orthogonal to the other processes and is also perennial. Eliciting is gathering the needs, modelling is describing the elicited facts in some description language and analysing is making sure that correctness and completeness were taken into account. The analysis process is performed by a combination of verification and validation. These processes are really a web of processes, sometimes without a sequence or sometimes so mixed together that it is hard to separate each one. However this classification helps to understand the issues a requirements engineer faces when dealing with problems and, a researcher when dealing with the complexities of the area. This book, Perspectives on Software Requirements, is a snapshot of different types of research results that enables the reader to have a better understanding of the discipline. It unites different researchers of different backgrounds and different
The list of books you might like
