What do you think?
Rate this book
Just Enough Requirements Management: Where Software Development Meets Marketing
If you develop software without understanding the requirements, you're wasting your time. On the other hand, if a project spends too much time trying to understand the requirements, it will end up late and/or over-budget. And products that are created by such projects can be just as unsuccessful as those that fail to meet the basic requirements. Instead, every company must make a reasonable trade-off between what's required and what time and resources are available. Finding the right balance for your project may depend on many factors, including the corporate culture, the time-to-market pressure, and the criticality of the application. That is why requirements management—gathering requirements, identifying the "right" ones to satisfy, and documenting them—is essential. Just Enough Requirements Management shows you how to discover, prune, and document requirements when you are subjected to tight schedule constraints. You'll apply just enough process to minimize risks while still achieving desired outcomes. You'll determine how many requirements are just enough to satisfy your customers while still meeting your goals for schedule, budget, and resources. If your project has insufficient resources to satisfy all the requirements of your customers, you must read Just Enough Requirements Management. ------------------------------------------------------------------------ Reviews "Al Davis takes for his subject the largely unexplored middle ground between the requirements purists and the requirements cowboys. Since it's this middle ground where real work gets done, his guidance is both useful and welcome." —Tom DeMarco, coauthor of Peopleware Principal, The Atlantic Systems Guild, systemsguild.com
240 pages, Paperback
First published January 1, 2005
2 people are currently reading
28 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
May 27, 2015
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.
This review also appears on Amazon
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.
This review also appears on Amazon
Displaying 1 of 1 review