ISBN: 0750665076 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Tom Gilb is well known as a speaker and consultant, as the author of Principles of Software Engineering Management (1988) and of Software Metrics (1977), and as the inventor of "Planguage", a way of structuring requirements.
This is an unusual book in several ways, and as such not easy to review. It might well have been entitled 'The Planguage Reference Manual' as a large part of its structure is a systematic walk through the main components of the approach: the language's Concepts and its 'Parameters and Grammar'; and the processes that use the language. The introduction makes clear that the book will not be very readable: it is somewhat expanded from the dry style of a reference manual, but not by much, and the sharp edges of the hierarchical structure are everywhere visible. That makes the book something of a challenge.
Despite the fact that the Planguage glossary section takes up nearly a third of the book, it's still only about a quarter of the current glossary, which is still growing. There is however a "complete" glossary of Planguage on the Elsevier website (along with a review by Jerry Huller of Raytheon, and a sample chapter, both useful if you want to know what the book is like). The book is thus an incomplete introduction to the reference material. This is an odd compromise: perhaps a more 'chatty' overview (to use Gilb's own word) in the style of a tutorial would have been a better choice.
The book, however, is far from consisting only of reference material. Gilb's thinking is based on several famous names from an earlier age, notably Shewhart and Deming's Plan-Do-Study-Act, or Plan-Do-Check-Act if you prefer. That is of course a management take on process control: continuously iterate between measuring and putting a hand on the tiller to keep the boat on course. Iterative life-cycles (Gilb calls this Evo, which stands for both 'evolutionary' and for 'evolutionary project management') are much in fashion today, from the CMM's concept of continuous improvement to the rapid cycles of Agile software development.
The book, too, is full of simple plain wisdom, often expressed in aphorisms and proverbs. For instance,
"The basic ideas of S[pecification] Q[uality] C[ontrol] are simple:
A stitch in time saves nine...
An ounce of prevention is worth a pound of cure".
Or again:
"It is important to distinguish 'ends' from 'means'"
— design ideas are labelled 'false requirements'. Good sensible stuff. Similarly the idea of looking for the 'few key requirements' is advised: "I often use the concept 'Top Ten'". The boxed reminder immediately below runs:
|
Remember, for many projects, even delivering a single top objective on time and to financial budget, would be an advance on their current experiences! |
This is the voice of experience (and of an expert communicator and trainer): it's obviously true, and it suggests a good place to start if a project is in a mess. But it sits oddly with the formal structure of the body of the book.
Other attractively homespun elements include Tenniel's fine cartoon of Alice (in Wonderland) talking to the Cheshire Cat. Alice says she doesn't much care where she gets to; to which the Cat replies "Then it doesn't matter which way you go". In the context of getting projects to create "clear measurable requirements" (Philip Crosby); this may strike a chord with some beleaguered readers.
There are good things in this book, not least its strong emphasis on iteration, on communication, on clarity, on reducing risk, and perhaps especially on measurement (there are telling quotes from Lord Kelvin and Simon Ramo on that subject). But these things are the daily stuff of systems and software engineering: they are the purpose and bread-and-butter of requirements work, and Planguage has no monopoly on any of them.
This book is clearly aimed at industry, and it is associated with a successful consulting and training practice. It contains much that is helpful and practical. While the analytic definitions of principles, rules and concepts may prove indigestible for many readers, the plain advice (for instance) to define your requirements in terms of stakeholders, scope, conditions, rationale, dependencies, links, and testability can hardly be faulted.
© Ian Alexander 2005 You may also like:
