This cheerful word from military/disaster medicine is adopted by Davis because, he says, it perfectly suits the requirements situation. Some things are no-brainers; there's no need for discussion. Some are hopelessly dreamy: they should instantly be dismissed. And the rest need to be ranked in a practical way so you can plan your projects. 

Triage / prioritisation seems to overlap quite strongly with the whole business of optioneering: you can't really tell how important a requirement is until you know a possible solution; and if different options enable different requirements, the trade-offs are complex and probably cannot be optimised perfectly. In any case, there isn't time: if you go on until the requirements are perfect, you'll be bankrupt, and in any case the world will have moved on and the customers will have changed their minds. Davis doesn't use language like 'optioneering' and 'trade-off' but he's certainly at home in a world where imperfect, non-mathematical kludges are necessary to get a quick fix: in fact, it's the only kind of fix in town. 

One thing that is specially nice about the book is that it does not just trot out Standish's 1994 Chaos report as evidence that requirements matter, but quotes studies going back to Endres in 1975, and Boehm, Daly, and Fagan in 1976, to show that nearly half of all errors stem from requirements issues. Davis divides these into three categories:

• Knowledge errors

• Triage errors

• Specification errors.

These correspond to Davis' view of the requirements process: Elicitation, Triage, and Specification (or if you prefer, Requirements Gathering, Prioritisation, and Writing/Formalising). 

The book concentrates on the awkward middle ground in other dimensions also (apart from triage): 

• between doing too much and too little (seeking the perfect spec, or rushing into code);

• between technology and the market (doing analysis, or thinking about what will sell).

This is brave, novel, and very welcome. No-one else, perhaps, could take a long view of the passionate arguments between traditionalists, formalists, and agile methods people, or of the differing viewpoints of developers, managers, and marketing on a software product's requirements, and the difficult interdisciplinary work (involving messy things like schedule risk and marketing strategies, rather than the merits of individual requirements) that has to be done to arrive at good decisions in that political minefield. 

The book is addressed to software developers, who are assumed to be doing the requirements work. Obviously that isn't the only possibility. It's also not clear whether the book is intended for, or suitable for people who are more or less beginners. The advice given is generally spot on, but may be hard for the inexperienced to take. 

For instance, it's all very well to advise people not to expect complete requirements (page 157), but try telling that to a naive client with a critical project. 'Just enough' is in its way as much a counsel of perfection as the old and obviously impossible 'complete, correct, consistent' dogma (p129ff, for which Davis was at least partly responsible). But is 'just enough' any easier? How do you know that you have the bare minimum? It might be safer to do just a little more to provide a margin for error! Of course, it depends who (developer, marketer, customer) is talking. 

So, perhaps this is a book for experienced requirements people (ie, those who've been burnt once) to reflect on. It doesn't attempt to cover every analysis and elicitation method ever taught: the textbooks can do that. Instead, it takes a light, informed, politically-skilful and industrially-informed look at the problem of doing just enough. This is very timely, given the 'heavy RE' versus 'agile methods' debate: and Davis succeeds in pointing out where the balance lies. Davis writes in a fresh and engaging way, telling stories from his long and varied experience as a consultant (and researcher). 

Davis has come up with yet another good, practical book for industry. It's also packed with knowledge of how the requirements literature fits together, forming a useful synopsis of the last thirty years of research, which might be useful to academics starting out in the field. It is very definitely about software, and within that area it is remarkably comprehensive for such a short book; but much of the approach is applicable to requirements work in other areas too. 

© Ian Alexander 2005

You may also like: