As I write, less than a week has passed since the terrible events of September 11, 2001. Like many Americans I am torn between two urges: on the one hand, to move forward with business as usual; on the other, to devote attention to understanding what happened, and why, and to form my own opinion about what our country should do about it.
The compromise between these urges is this abbreviated column. Normally I seek to make my column valuable to you by calling your attention to worthy books or software. This column does that. Normally I add further value by analyzing and describing the products I review in the light of my experience in the computer field. This time I haven't achieved my usual level of analysis and description. In other words, this time I tell you about some books that I think you ought to read, but I may not give you sufficient information to let you come to that conclusion for yourself.
Requirements
Exploring Requirements -- Quality Before Design by Donald C. Gause and Gerald M. Weinberg (Dorset House, New York, NY, 1989, 320pp, www.dorsethouse.com, ISBN 0-932633-13-7, $50.45)
The biggest problem with software development is knowing exactly what to build. Communication between developers and their customers faces many obstacles:
- Different assumptions and terminology
- Intermediaries with their own assumptions and understanding
- Failure to understand and respect each other's expertise
- Insufficient time to build a common understanding of the desired final product
- All the ambiguities of natural languages
A charming example of the last point is the authors' Mary Had a Little Lamb heuristic, which encourages you to substitute synonyms for the words in a requirement. For example, Mary cheated an unsophisticated investor; Mary gave birth to a small good-natured child; Mary dined sparingly on mutton stew.
A misunderstanding can cost a great deal to correct after the product is finished but very little to correct before the design phase begins. This more than justifies the cost of defining requirements carefully.
Twelve years after it first appeared, this book is completely relevant to today's development projects. Gause and Weinberg call on their many years of consulting experience to provide practical techniques for exploring requirements. That is, they show you ways to discover and overcome ambiguity, distinguish between requirements and preferences, and push back against constraints. They show you how to tell when you're done and how to translate requirements into acceptance tests. They even give you ways to make meetings more productive.
Given the frequent disconnect between "what the customer wanted" and "what the engineers built" -- the subject of a well known cartoon -- most companies would benefit greatly from improvements to the way they define requirements. This book is just what the doctor ordered. I recommend it to anyone who has anything to do with software development.
Mastering the Requirements Process by Suzanne Robertson and James Robertson (Addison-Wesley/ACM Press, Harlow England, 1999, 416pp, www.aw.com/cseng ISBN 0-201-36046-2, $47.99)
This book picks up where the Gause/Weinberg book leaves off. Gause and Weinberg describe a collection of valuable techniques. The Robertsons, based on their long and widely recognized experience, lay out a complete end-to-end process for defining sets of requirements that are complete, correct, and measurable.
The Robertsons call their process Volere. They don't say how they came up with that name, but I assume it has something to do with the Italian verb meaning "wish." The Volere process turns customers' wishes into a usable specification document. The process is far from linear. An overview diagram contains many circular paths and feedback loops -- as simple as possible, to paraphrase Einstein, but no simpler. Or as Gerald Weinberg says in his foreword, "every part of the process makes sense, even to people who are not experienced with requirements work."
Several notable features make the Volere process especially worthwhile. The first is the freely available Volere template (www.guild.demon.co.uk/SpecTemplate8.pdf). You can adapt this template for a requirements process to your own situation. Of course, to fully understand it, you probably need to read this book.
Two other notable features work together to keep your specification documents on target. The first is the concept of fit criteria, and the second is the quality gateway. Fit criteria are the rules (generally involving numerical measurements) for testing whether the final system meets the given requirement. The quality gateway is a process for deciding whether or not to include a fully specified requirement in the final requirements set.
If you write requirements documents or specifications, reading this book is your first requirement.
Software Requirements by Karl E. Wiegers (Microsoft, Redmond WA, 1999, 366pp, www.microsoft.com/mspress, ISBN 0-7356-0631-5, $34.99)
This book covers much of the same area as the other two books in this section, but it does so from a software developer's point of view. It also expands the idea of requirements to include specifications, and it addresses the way the requirements process fits into the entire development management process.
Wiegers uses a fictional chemical tracking application to provide context for the discussion, but he sometimes abandons it and brings in situations from his own extensive experience. Either way, he tries to keep his techniques practical.
I especially like the When Bad Requirements Happen to Nice People section. There Wiegers outlines the problems that his book is meant to solve. For example, he warns against gold-plating, a situation in which programmers add features that they think users will like, inevitably at the cost of taking time away from the most important features.
Naturally, the problems Wiegers sees overlap substantially with the ones that Gause and Weinberg and the Robertsons address. For example, the Robertsons' quality gateway avoids gold plating.
I'd read the Gause and Weinberg book before reading this book. If your main interest is software development, you might read this book instead of the Robertsons' book, but if you have time, read all three.
Project Management
A Guide to the Project Management Body of Knowledge, 2000 ed by Project Management Institute (PMI, Newtown Square, PA, 2000, 228pp, www.pmi.org, ISBN 1-880410-23-0, $35.95)
Project management professionals apply a variety of theories and practices to their work -- some experimental, others tried and true. The combined lore of these professionals constitutes a large body of knowledge.
The PMBOK Guide, as this book is known in project management circles, identifies and describes the subset of that body of knowledge that the Project Management Institute deems generally accepted. It does not teach this body of knowledge, but it provides an excellent map, a well organized skeleton with a little flesh on the bones.
This is a basic reference for anyone seeking certification in project management. It is also a helpful guide for anyone seeking to understand the underlying model of that ubiquitous but inscrutable tool, Microsoft Project. If you use Microsoft Project, but don't always understand what it's doing, read this book.
While this book is basic, if your interest is in a specific aspect or field of project management, you should also look at more narrowly focused books.
Information Technology Project Management by Kathy Schwalbe (Thomson/Course Technology, Cambridge, MA, 2000, 512pp, www.course.com, ISBN 0-7600-1180-X, $53.95)
The PMBOK Guide is a scant 228 pages. This book, at more than twice that length, seeks to flesh out the PMBOK and specialize it to a specific industry. Schwalbe writes in the format of a textbook, with discussion questions, exercises, and suggested readings. The layout and printing are not up to the standards of mainstream publishers, but if you can get past that, the book provides a great deal of information in an easy to assimilate format.
One attractive feature of this book is that it uses Microsoft Project to develop class projects. Using Microsoft Project without understanding the underlying project management model can be confusing and difficult. The examples in this book help you avoid the confusion.
Special Edition Using Microsoft Project 2000 by Tim Pyron (Que, Indianapolis IN, 2000, 1314pp plus CD, www.quepublishing.com, ISBN 0-7897-2253-4, $39.99)
This book is well organized, beautifully laid out and printed, well written, comprehensive, and insightful. The notes and cautions add real value by tapping into the author's extensive experience with the product.
The detailed table of contents reflects the logical structure, and the excellent index makes it easy to find information in this huge volume.
If anything can make Microsoft Project comprehensible, this book is it. I recommend it to anyone who wants to use the real power of this tool.
