Review By: Meredith Morrow
08/18/2008 "Unearthing Business Requirements: Elicitation Tools and Techniques" has the ability to attain a long shelf life due to the extremely practical information and manner of presentation. The most surprising part of this book is the fact that the first six chapters deal with preparing for gathering requirements rather than gathering requirements. I first thought this was odd, but after reading those chapters, I can see that the authors (both having a PMP designation) use these pages to ensure that the stage is set appropriately on which the requirements are obtained. The techniques for gathering requirements are then presented in the next seven chapters. The book also includes an Appendix of a sample requirements management plan.

This book is geared for business analysts that work on projects rather than testing resources. As a current business analyst and former testing analyst, this book is definitely applicable for those testing analysts who want to use the requirements to the best advantage for testing.

I thought the best chapter of the book was Chapter 10, "Surveys." I work for a group of systems analysts that work with a highly technical tool. To alleviate some issues that arise when the user base is scattered (across four different locations) and have a different business focus (which could range from one to six); we have relied on the Windows tool SharePoint in which the community can get the most current information, talk to each other, and generally know what is going on in other spaces.

One of the features of SharePoint is the ability to create surveys. The problem is that the community doesn't like surveys and it has been a struggle to engage them this way. Surveys have been used to prioritize requirements in the past with little success (less than 10 percent participation). Using this chapter I was able to create a survey that measured the baseline satisfaction with a relatively new tool. The authors suggested that survey respondents have a chance to "win" a monetary award. Using the reward and the advice on the best way to structure and ask questions, the tool support team now has information about how the system is meeting the user needs. Only this time it isn't from the number of problem tickets opened or general grumbling. Now, there is data behind the information.

I recommend this book for any business analyst wanting to put more structure around the process of gathering requirements. Additionally, testers responsible for acceptance testing and implementation of a product can get a great deal from this publication.