Just Enough Requirements Management: Where Software Development Meets Marketing [Paperback]

The title says it all, this book really does explore all of the issues surrounding how to do just enough requirements management on your software development projects. I'd argue that it provides the insight that you require to put together an requirements program within your organization that is right for you, one that is sufficiently agile yet still reflects your situation. It explores strategies for eliciting requirements, prioritizing/triaging requirements, specifying requirements, and finally managing requirements change. Davis managed to pull off what few writers can do - by exploring the requirements management spectrum he has presented a range of strategies which should speak to both traditionalists and agilists. For traditionalists he presents some pretty convincing arguments that the "big requirements document up front" strategy might not be all that effective, and for agilists he presents convincing arguments that we need to invest some effort in requirements documentation. Most important is a running theme throughout the book: the goal isn't to write a perfect requirements document, it's to deliver working software which meets the needs of your stakeholders in a timely and cost effective manner. Sounds like really great advice to me.

I was very impressed when reading Alan Davis' latest book on 'Just enough Requirements Management.'

In his past work he has worked on bringing more formalism into requirements engineering in order to make them correct. However, over time he realized that this doesn't solve the real problems, because the requirements are changing despite the fact they've been formalized in advance.

There are not many people who are confident enough to admit that they have learned over the past years which also means that they've changed their mind. Alan is competent enough doing so which makes him really authentic.

A real eye opener for most of the readers is probably his illustration of the reality of ongoing requirements activities despite using a waterfall approach.

In this fast moving world, it is essential to know how much requirements engineering is necessary in order to being able to moving on and it is even more important to know when to stop doing requirements engineering for being in-time on the market.

I really recommend reading this book in order to know what barely sufficient requirement engineering is all about.

As all veterans of the software development process know, the software development and marketing teams often square off in a verbal and textual tussle regarding what the software should do. The marketing team often adopts a rigid, "We've got to have it all in order to sell it" position and the development team an opposite, "we can only do a limited number of absolutely essential features." Extremes tend to dominate over the means and exaggeration is often used to make a position sound more believable. It is much easier to sell your position if you use, "the life of the company is at stake" statements.
The reality is of course almost always in the middle and that is where Davis is. In emergency medicine, triage is the process where when faced with an overwhelming number of patients they are placed in one of three categories.

*) Those that will die no matter what the medical people do. All that can be done here is to ease the transition.
*) Those that will live even if the medical people do nothing. These people can be given minor aid such as painkillers but no major effort should be expended.
*) The injured that will die if left unaided and that will live if treated. These are the people that are given the extensive medical aid. The most critically injured are placed first in the treatment queue.

Davis applies the triage principle to the features that are to be included in the software to be developed.
In a series of meetings, both sides discuss what features are to be included with the desires of the customers given priority. Although it may sometimes be true in theory, it is a rare occasion in practice when developers and marketers know more about what to produce than the customers do. Charts, principles and any other relevant and understandable documentation can be used to justify a position or to record a decision or a development tactic.
The contents of appendix A should be hung on the wall of every room where developers work. It is a summary of the steps to follow including the all-important ranking of the value of features and customers. The old saying about, "the customer is always right" is false, as Davis points out, it should be amended to say, "Your best customer is always right." When you receive a large number of requests for features you should prioritize the features according to the value to the company of each customer. If customer A buys $1M worth of products and customer B buys $1K worth of products, then customer A should be more right than customer B when a decision is made about a feature to include.
Completeness and rigidity in requirements are the enemies of the completion of major projects, so the goal is to develop an encompassing set of flexible requirements that provide enough direction for system development. Developing these requirements is not an easy task, but it is a doable one. You can make that more likely by reading this book and adhering to the principles.