Customer Reviews

Just Enough Requirements Management: Where Software Development Meets Marketing

5 star:		(6)
4 star:		(3)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

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.

Al Davis has done it again, with a highly practical and useable book on the ongoing process of effectively managing changing requirements.

Davis is an expert in requirements, bringing to light his vast expertise in many domains including systems engineering on real (very large) projects as well as commercial software. He is perhaps THE expert on requirements triage.

This book provides practical advise on how to do triage and provides examples and wisdom on documenting requirements that honors both the need to 'write it down' in some way with the reality of ever-changing requirements.

I am reading another book on the same topic as I read this one, and I must say, this one is so much easier to read and understand. If you have any experience in software, this book will be a pleasure to read.

I would recommend to both practitioners and students.

The information in JERM is concise, practical, and to the point. It has become a must have in my collection alongside my Peopleware and Man Made Month. It has lots of images that do an excellent job of explaining just how to make sure your requirements remain useful on a practical level. I bought this copy for my team at the office, but I'll be ordering one for my home library as well.

If you think that requirements are not all that necessary, this book might change your view: Before you build something, you should decide what you want to build. If you think you cannot start development until requirements are "complete," Davis will convince you that, since requirements change, requirements management is an ongoing activity. He breaks it down into three major areas:

- Requirements elicitation (i.e. determining the actual needs of the stakeholders): This includes identifying ALL the stakeholders and also knowing when and how to apply different elicitation techniques. Davis comments on the proper use of modeling notations are really noteworthy.

- Requirements triage (to balance the delivery date and the development budget against desired requirements): If you don't know what triage is, then you should probably read this book. Its importance (and the author's bias) is manifest when you realize that it has the longest chapter in this book.

- Requirements specification (i.e. documenting requirements): Davis advocates for the use of lists of discrete annotated requirements written in natural language just because natural language is the language of customers (and free text is not too manageable). Supporting models can also be sensibly used, but only for those parts of the system where the use of natural language would introduce too much risk, never to completely replace the written requirements.

"Just Enough Requirements Management" ends with a reminder of change as an unavoidable fact. It also includes an extensive annotated bibliography for those interested in learning more about requirements, just after reading this cleverly-written book...

Alan Davis has written a good book on Requirements Management. He has explained his approach and includes a lot common sense with it. I had just finished a class discussion on requirement attributes, and we had "brainstormed" a comprehensive list of 30+ attributes. On this topic, Davis explained how his opinion had changed over time so that now he felt eight attributes was enough. I agreed completely. Reviewing a list of a hundred or more requirements, and validating that each met a list of attributes, which list makes more sense to you - 8 or more than 30? A good book, but a little "over-priced" for $35 for only 240 pages.

One of the best books I have read in this subject. Detailed and with many practical rules and examples.