Dedication

Over the course of many years , we and others who have contributed to this book have taught, and have been taught by, thousands of students interested in improving project outcomes by doing a better job of managing their software requirements. In this second edition of the book, we've been more prescriptive, but we still recognize that there is no one right way to perform requirements management. No one single elicitation technique applies in every circumstance; no one single process fits all teams . Projects have varying degrees of scope and complexity. Application types vary tremendously and come from many different industries.

Yes, requirements management is a broad topic, and it is also very deep. A recurring theme from the classroom is that students feel the need to have a more prescriptive process ”a recipe, if you will ”for applying what they learned in class. "You've told us too much," our students might say. "Just give us a single generic process that we can start with," they continue. "We know it's not that simple, but we'll be happy to modify it as necessary for our project. We need a more prescriptive starting point, a step-by-step process so that we can better apply what we learned. Just tell me how to get started! "

OK, you've got it. These next two chapters are dedicated to these students and to those of you who share their point of view and this common " user need."