Preface to the Second Edition

In the six years since we published the first edition of this book, the world's knowledge of requirements has grown, and more people have a job called "business analyst," "requirements engineer," or something similar. The Volere Requirements Specification Template has been downloaded countless times. The Volere Requirements Process is in use by thousands of people who are engaged in the activity of successful requirements gathering. They, in turn, have given us feedback over the years about what they needed to know, and what they are doing when gathering requirements.

This book is a reflection of the feedback we have received, and of the way people have made use of the first edition.

The requirements activity has moved away from wanting to be seen as an engineering discipline, to the realization that it is a sociotechnical activity. Requirements analysts now see their role first as one of communication, and second as a technician adding rigor and precision to the results of the human communication.

As a result, we have updated and expanded the project sociology analysis section of the book. In a similar vein, we have added the appropriate rigor to the technicalities of recording and measuring the requirements.

Perhaps the greatest change to come along since the first edition has been the arrival of agile methods, accompanied by some wonderful technological advances. Agile methods have influenced the way people develop software, with the result being that greater emphasis is placed on close customer relationships, and less emphasis is placed on documentation. We heartily applaud this advance. However, we have also seen too many people, who, in the name of agility, rush to a solution without first understanding the real business problem to be solved.

This, then, is the role of requirements in the agile world: to ensure that we hear not only one customer's voice, but also the voices of the other stakeholdersthose with some value to add to the requirements for the product. Agile requirements analysts ensure that the work is considered, not just the product, and that the nonfunctional requirements are studied, not left to the whim of the programmer.

Agile methods have brought with them a healthy disdain for documentation. We agree with this view. Throughout this second edition we urge you to consider the benefit before committing anything to writing. But while we suggest sometimes you can develop software successfully without formally written requirements, we never suggest you can do it without understanding the requirements.

The emphasis on iterative development means that the requirements "phase" is no longer completed before building begins. The drive toward short, sharp release cycles means requirements analysts get feedback on their requirements efforts more quickly. Stakeholders receive positive reinforcement when they see the time they invest in requirements paid back with progressive versions of working software that does what they expect, and what they need.

Technological advances have changed requirements gathering. Blogs and wikis mean that requirements analysts can gather their requirements informally and iteratively using the convenience of networking with their stakeholders. Desktop videoconferencing and instant messaging mean closer, quicker communication with stakeholders, which is, of course, necessary for good requirements gathering.

The gap between what we wrote in 1999 and what we found ourselves doing when gathering requirements gradually grew wider, until we knew it was time to update our book. The volume that you hold in your hands is the result of the last few years of our work and teaching. We trust you find it interesting, enlightening, and useful.

For the convenience of the reader, throughout this book we have used "he" to refer to both genders. The authors(one male and one female) find the use of "he or she" disruptive and awkward.