Colin Hood, Simon Wiedemann, Stefan Fichtinger,
Urte Pautz
Springer, 2008.
ISBN 354047689X
Buy it from Amazon.com
Buy it from Amazon.co.uk
It is often the subtitle of a book, rather than its official title, that says what it is really about. The subtitle, too, often speaks volumes about what the book's authors believe, their world-view. In this case, the world is divided into requirements development, in which you discover what people want; requirements management (RM), in which you
"try to make sure that everybody has all the background knowledge they need and that information is flowing properly between all parties involved." (page 69)
and finally all other processes such as design, verification, and manufacture that are needed in complex systems engineering. This is at the opposite end of the scale from, say, Alistair Cockburn's Agile Software Development. The context is contractual, rather than in-house development; the product is not necessarily software; and deliberate is likely to give better results than hasty:
"the requirements are usually the only means to check whether what has been wanted by the customer is what has actually been delivered. It is quite amazing to note how many projects are still based upon informal personal talks..." (page 68)
More and more, it feels as if controversy is not often actual disagreement, but people coming from different places and talking about what works for them in their own environment. Hood's environment is well summed up by Figure 7.5 in the book, where "Traceability" is shown from source code or hardware definitions under configuration management, to the requirements for hardware or software modules, to component requirements, then to subsystem requirements, and finally to system requirements. This is a substantial RM task; we may observe that requirements development or discovery is not even shown in the figure - most requirements are derived by analysis and design to meet parent system requirements, not by interviewing or other techniques to find out what customers and other stakeholders want.
Practices covered in the book include supporting
These practices are considered to be process interfaces (refer back to the book's subtitle for why). Each practice is described in enough detail to show what needs to be done, and why, even if actually implementing each practice may require much more in the way of engineering support. The mention of getting away from the document view indicates a database-centred approach: complex requirements need to be managed by means of a requirements database such as DOORS, capable of supporting detailed analysis of traceability, baselines and the status of individual requirements.
The book ends with 3 chapters on Capability Models. In the same way that SPICE or CMMI focus on how well a business implements various key practices, the Hood capability model focuses on how well you manage your requirements in each of the practices just listed (risk management, and so on). This enables a business to see how well it is doing, and where it most needs to improve its game.
This is a good, practical industrial book written from personal experience of helping people to manage their requirements better. It is not about requirements discovery (requirements development), nor about software or systems analysis and modelling -- all topics that people sometimes include under the RM umbrella.
If you are having trouble with managing your requirements (as opposed to discovering or modelling them), then this book contains solid advice for you.
© Ian Alexander 2008
You may also like:
