 | Level: Introductory Jim Heumann, Requirements management evangelist, IBM
15 Sep 2005 from The Rational Edge: This review examines a book that takes a practical approach to requirements management, focusing on fundamentals gleaned from the author’s extensive experience in the field.  by Alan M. Davis
Dorset House Publishing, 2005
ISBN: 0-932633-64-1
Cover price:US$39.95
256 pages
A recurring problem in many software development projects is "analysis paralysis." When they elicit and manage requirements, project teams often either get stuck or try to do too much. In this relatively short book, Al Davis, whose requirements management work has spanned three decades in academia as well as industry, boils it all down to just enough. The book is about practice, not theory, and Davis gives us the benefit of his long tenure in the field.
The book's sections cover four key stages for requirements management:
- Elicitation
- Triage
- Specification
- Change management
Elicitation
The section on requirements elicitation provides definitions, guidelines, and tips for getting requirements from users and other stakeholders. Davis covers all the recognized elicitation techniques: interviewing, facilitated group meetings, computer-supported cooperative work, observation, questionnaires, prototyping, and storyboarding. Whatever techniques you use, at the end of elicitation, you should have a list of candidate requirements.
Triage
The section on triage states that "requirement triage is the art of selecting the right requirements to include in the next release of your product." Davis emphasizes that this aspect of the requirements management process is vital to success but is often either overlooked or done "...by some combination of intimidation, inertia, osmosis, and incompetence."
The first step in triage is to determine the relative importance, or priority, of each requirement, and Davis explores several techniques for this purpose. He rules out simply asking the customer how important the requirement is, because most customers will tell you that all their requirements are equally important and equally critical. Instead, development teams should consider three important factors: cost, budget, and schedule. The team can estimate cost by estimating the effort required to implement each requirement. Then, deciding which of the prioritized requirements to include in the next release is a careful negotiation process between development and marketing; the two groups must make tradeoffs between budget and schedule to determine the optimal product. At the end of triage, everyone knows which requirements will be implemented in the next release, when that will happen, and how much it will cost.
Specification
Requirements specification is about refining and documenting the requirements in a clearly defined format. Unfortunately, Davis describes this part of the process in a way that is confusing and casts doubt on what preceded it. At the start of this section he states, "After elicitation and triage, it would be nice to just start building the product. Unfortunately, great risks remain. In particular, requirements are still quite ambiguous and open-ended." Earlier in the book, he says that triage is supposed to produce a list of approved requirements, as well as estimates for cost and schedule. So how can you accomplish these things if the requirements are "still quite ambiguous and open-ended" at the end of triage?
Davis also states that "...requirements specification is actually conducted throughout requirements activities." By this, I assume he means that you do a fair amount of specification during elicitation and triage, which also seems to contradict the "still ambiguous and open-ended" description. However, despite these apparent contradictions, Davis provides some good advice in this section on various ways to document requirements, from simple to complex. In particular, he states that "...organizations spend an inordinate amount of time polishing requirements documents with relatively little gain." His suggestion is to keep the goal in mind, which is a good product, rather than a perfect requirements document. He then describes various documentation styles, the role each style plays and the content it should have, and techniques for describing different types of requirements.
Change management
The short section on requirements change emphasizes that change is fundamentally good and necessary. Organizations should not discourage change, but they must manage it effectively. Davis explains the pros and cons of several approaches to handling changes, and favors using a change control board (CCB) for approving change requests. Based on work by Ralph Young and Ed Yourdon, he also claims that a change acceptance rate of greater than 6 to 10 percent will likely result in project failure.
An appendix called "Quick Recipes" is a good reference. It takes the reader through nine steps that encapsulate important principles the book describes. A second appendix contains the full set of documented requirements used as examples throughout the book.
The best things about Just Enough Requirements Management are that it is based on experience, and it is honest. Davis tells it like he sees it. Sometimes he even disagrees with things he said in his earlier books, based on lessons he learned in the interim. He doesn't shy away from controversy, either. He dismisses agile approaches to requirements as ineffective. And although he sees value in use cases and scenario-based requirements, he regards them as a rather minor adjunct to the traditional, declarative style of writing requirements.
I recommend this book to anyone who works with requirements. Although you might not agree with everything Davis says, you should be able to glean something you can use to improve your requirements management process.
About the author | | | Jim Heumann has worked in the software industry since 1982, doing analysis, development, design, training, and project management for both large and small organizations. Since joining Rational in 1998, he has focused on helping customers understand and implement software development processes and tools. Currently, as IBM Rational's requirements management evangelist, he specializes in front-end development issues. He holds an M.S. in management information systems from the University of Arizona. |
Rate this page
| |
