Requirements Engineering and Management for Software Development Projects Murali Chemuturi Requirements Engineering and Management for Software Development Projects Foreword by Tom Gilb 123 Murali Chemuturi Chemuturi Consultants [email protected] ISBN 978-1-4614-5376-5 ISBN 978-1-4614-5377-2 (eBook) DOI 10.1007/978-1-4614-5377-2 Springer New York Heidelberg Dordrecht London Library of Congress Control Number: 2012944969 Ó Springer Science+Business Media New York 2013 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law. The use of general descriptive names, registered names, trademarks, service marks, 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. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com) Foreword This book is a practical textbook which will be useful for a requirements student and/or a software manager student, to get a picture of the very many practical considerations that go into specifying and validating requirement for IT/IS projects. The book does not oversimplify subjects that require mature consideration in order to succeed. In my view the author gets many and most critical points correct, better than the many less mature authors. For a small example of such points, the importance of stakeholders, the silliness of the non-functional requirement term, and an understanding that quality is designed in, not tested in. The pages are, like my own detailed work, dense with powerful and useful lists of considerations. They will give excellent structure to a teacher who can help students discuss the points, and explain to students using examples. I hope this textbook finds its place as a teaching tool for information technology courses. But the lone reader can safely use it as a mature way to survey the entire software development scene today. Kolbotn, Norway, 8 June 2012 Tom Gilb v Preface Gerald M. Weinberg, author of the book ‘‘The Psychology of Computer Programming’’ is attributed with the quote —‘‘If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.’’ I could not agree more. The rate of project failure is much higher in software development compared to either manufacturing or construction. It is not that there are no failures in manufacturing or construction. Those failures are in ‘‘first-of-its-kind’’ projects, especially in manufacturing. In construction, these are even fewer. For example, the Empire State Building of New York city was the first of its kind when it was built. It is the first building in the world to go up 80 floors high above ground. It was the tallest building in the world for a number of years. The issues, there would have been many, were solved in the specifications and the design stage. The construction would scrupulously adhere to the design. It was a success. Why do software projects fail at such a high rate even when there were similar projects executed earlier? Two major causes are attributed for this phenomenon. The first is the poor understanding and definition of product requirements. This leads to technical failure. The second is the poor project management of developing the software product to the specified requirements resulting in unsustainable overruns of cost and schedule. Both the reasons lead to project failure. In this book, I am focusing on the precise understanding and definition of product requirements. As in other areas, there is more misunderstanding about this critical activity than right understanding. ‘‘The hardest single part of building a software system 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.’’ said Frederick Brooks, Jr., Brooks Computer Science Building, University of North Carolina, USA. (From his paper ‘‘No Silver Bullet: Essence and Accident in Software Engineering,’’ 1986 as also The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Chap. 16.) I concur wholeheartedly. vii viii Preface Unfortunately for me or perhaps for the software development industry itself, there is no commonly accepted taxonomy for software engineering activities. It is not that there are no definitions at all. The definitions that are there, are not universally accepted. Some, like ‘‘non-functional requirements’’ are downright ridiculous. That is the reason why I am explaining every term I use here, as you will notice, from the first fundamentals. Wherever, possible, I am using the ter- minology from a credible source. I am giving all the available meanings with my own interpretation with the idea that the reader is better informed when the same matter is presented by someone else with a different set of nomenclature. Please bear with me for this over-specification. My own perception was gathered from my experience, observation, study and participation in discussion forums of how well the requirements are either engi- neered or managed. It is not very flattering to the community of requirements engineers or managers. There are many doubts, which begin right at the funda- mental stage among the practitioners. This is, perhaps, due to the fact that uni- versities are not conducting courses in requirements engineering and management. Their focus is more on engineering and producing code rather than on the forward or backward linkages to code production. Managements rather hasten the project teams into coding ASAP. Of course, there are exceptions without which, I would not have been able to gather best practices. In this book, I tried to give you a complete view of the activities of require- ments engineering as well as requirements management. Both the activities, engineering and management, are equally important. Engineering activities, per- formed well, produce the right deliverable. When we manage the engineering activities diligently, we produce the deliverable within the estimated cost and on schedule. The variances that are bound to be there would be predictable and within acceptable levels. Management activities when performed diligently would also allow us to plow the experience back into the process of performing engineering activities and facilitate improvement. The information presented here is from my experience, observation, academic study and participation in the Internet discussion forums. That was my intent and I would like to learn how you perceived my effort to be. Please feel free to email me at [email protected] and I promise to respond to every email that I receive normally in one business day. June 2012 Murali Chemuturi Acknowledgments When I look back, I find that there are so many people to whom I should be grateful. Be it because of their commissions or omissions, they made me a stronger and a better person, and both directly and indirectly helped to make this book possible. It would be difficult to acknowledge everyone’s contributions here, so to those whose names may not appear, I wish to thank you all just the same. I will have failed in my duty if I did not explicitly and gratefully acknowledge the persons below: • My parents, Appa Rao and Vijaya Lakshmi, the reason for my existence. Especially my father, a rustic agrarian, who by personal example taught me the virtue of hard work and how sweet the aroma of sweat from the brow can be. • My family, who stood by me like a rock in difficult times. Especially my wife, Udaya Sundari, who gave me the confidence and the belief that ‘‘I can.’’ And my two sons, Dr. Nagendra and Vijay, who provided me the motive to excel. • My two uncles, Raju and Ramana, who by personal example taught me what integrity and excellence mean. • Springer Science+Business Media and especially Ms. Susan Lagerstrom-Fife and Ms. Courtney Clark for their belief in the content of this book, for their generous allocation of time, and for leading me by the hand like the Good Lord through every step of making this book a reality. • The staff of Springer Science+Business Media all of whom were involved in bringing this book out to the public. To all of you, I humbly bow my head in respect, and salute you in acknowl- edgement of your contribution. Murali Chemuturi ix Contents 1 Introduction to Requirements Engineering and Management .... 1 1.1 What is a ‘‘Requirement’’ . 1 1.2 Requirements Management .