Soren Lauesen
Lauesen Publishing 2008
Soren Lauesen
Lauesen Publishing 2008
ISBN 9788799234400 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Lauesen has already shown himself to be a capable teacher of both requirements and user interface design. With this new booklet, he reveals his intensely practical side. The Guide, Template and Examples is a slim volume that follows the ancient teacher's maxim: Show, Don't Tell. The Guide is essentially just a short description of what each part of the Template is about. The Examples are from a real project and cover functional as well as non-functional requirements.
The odd title, by the way, is simply "Soren Lauesen, version 2007" - new versions will be issued and published as necessary, incorporating reader feedback and experience. That desirable process could only be accomplished by Lauesen's publishing the book himself.
There is no flowery rhetoric here; little theory; and no academic bibliography at all: pretty remarkable for a university professor. Instead, you get a compact, practical guide to what to put in your requirements specification, at least, if your project is for software - most probably of the data-handling variety - and you share Lauesen's concern to write down clear requirements to communicate a large customer's wishes directly to a supplier (a software house). In other words, this is a book specially for work of the copy, study, and edit kind, for what used to be called "user requirements".
Actually, it is rather more than that. Each chunk of the Template has a column for the (customer's) requirements on the left, and a column for the "Proposed solutions" to its right. The customer is, in other words, invited to write down what he expects or suggests in the way of a possibly-workable solution. This is rather a wise move on Lauesen's part, because customers frequently come up with solutions rather than requirements. The template coaxes them into moving such things into the "proposed" category, leaving the requirements field invitingly blank. Of course, that invites reflection: what must our requirement be, if that is what we think our solution will be like? With any luck, it will be a clear statement of stakeholders' goals, which will help the supplier mightily in understanding what is in fact wanted.
Lauesen's examples are nearly all from a healthcare project. Together they add up to a complete specification, except that only some of the use cases, some of the data classes, and some of the integration requirements are described. They quietly convey the message "this is how I did the requirements on this project". People have been pleading for such a book for years.
Some cautions are in order. The template does not attempt to cover "system" and "subsystem" requirements that might be written by the supplier and perhaps his subcontractors, once the architecture and scope are known. No attempt is made, either, to cover domains other than software, so there is scope for more templates and matching guidance if you know a good way of writing requirements for other kinds of product. Finally, this is not a book of processes and techniques: it does not teach you how to identify your stakeholders, model people's goals, narrate their scenarios, or much else. But what it does do, it does supremely well, and it has its niche to itself.
This is a really good and valuable contribution to the industrial literature on requirements. In a sense, it is a coming-of-age: requirements work is growing up, and Lauesen has given the world a serious, quiet, practical guide to help people get better results from their projects. The template itself can be freely downloaded from Soren Lauesen's website.
© Ian Alexander 2008
You may also like:
