Among valuable references on software requirements you will want to place Alan M. Davis's Just Enough Requirements Management (Dorset House Publishing, New York). With this book, Davis strikes straight at the heart of the problem of eliciting requirements: creating software that works for people. For despite everyone's best intentions, requirements elicitation remains an area where teams wander off the path or -- just as bad -- get into a predictable rut.
Davis as a master critic of software processes provides a look at how much planning is enough when it comes to requirements, which is just the question people are asking these days as Agile processes vie with Waterfall methods. At 240 pages, his book fits neatly between the extremes of a too-short take and a dreadfully long tome.
Being open to changes in requirements is part and parcel of today's Agile credo. Davis endorses such change. But he holds fast against the notion of gathering tons of initial requirements. "Just enough" is the mantra. Moreover, Davis deftly dissects the dark side of endlessly added requirements. By Davis's estimates, 10% is a reasonable level of requirements change in a project. I buy that. At some point, someone has to get serious about finishing something, rather than endlessly asking "what if," right?
The book is guided by a common sense view. It proceeds based on a basic principle that you do your best to understand your problem and then move on to apply that understanding to an adequate solution.
Now a professor of information systems at the University of Colorado at Colorado Springs, Davis has the prerequisites to tackle his topic. In the past he authored articles and books on requirements and served on the board of requirements software house Requisite Software. He is the author of 201 Principles of Software Development (McGraw-Hill, 1995), long a personal favorite.
Just Enough Requirements Management won't molder on the shelf. Davis has devoted a portion of the book to "Quick Recipes" that highlight the elements that comprise the successful requirements process. The book, proper with its thoughtful detail, provides the background for understanding the recipes. Here are a few morsels from his summary of requirements elicitation best practices:
- Never lose sight of your goal: to understand enough of the problem to proceed with minimal risk
- Never think you understand the problem better than the customer
- Never assume that one stakeholder can speak for all stakeholders
- Prepare for active, explicit and overt triage
Warning: Just Enough Requirements Management probably is not a book for requirements traditionalists. Neither is it a book for Extreme Programming aficionados. It takes a middle ground and holds it. As its subtitle ("Where Software Development Meets Marketing") indicates, it is all about bridging the gap between software development and business users' objectives. After all, that is the essence of requirements elicitation in the business enterprise. In Davis' hands that seems to be not just a worthwhile purpose, but also an achievable goal.