Joy Beatty and Anthony Chen
Microsoft Press, 2012
ISBN 0735667721 (paper)
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
I can't fully independently review this book as I wrote its foreword, which may however serve as a review of sorts.
The most striking thing about requirements work is the enormous difference between what academics think it involves, and what people in industry actually do.
The academics think they are far ahead, because they have a wide range of models and techniques, complete with experimental studies (done with specially-tamed industrial tribespeople), theoretical analyses and enormous textbooks full of excellent advice. They can’t see why people in industry are being so slow to adopt their methods.
The people in industry think they are far ahead, because they have years of experience, software that works (after a bit of pushing and shoving), and proven methods of managing requirements with traceability matrices, reviews, configuration management, and attributes for priority and status. They can’t see why people in academia are being so slow to catch up with reality.
It’s like watching two cyclists on a circular racetrack, 180 degrees apart, endlessly circling.
That’s why it is so good to see this book from Beatty Beatty and Anthony Chen. They are practical engineers who speak from their own experience. But – and this is the crucial thing – they are familiar with the range of models advocated by researchers, and even better, they have steadily incorporated more and more of these into their practice. Now they have reached the point where they can see that the models they are using enable them conveniently and effectively to analyse all the requirements they come across. They’ve seen and heard the academics talking about, say, goal modelling using KAOS or i*. They’ve seen challenged projects that only needed a context model to inject clarity, or the disaster that looms on projects that lack something as simple and traditional as a data dictionary. And they have a practical handle on the essential fact that you have to use all these things together.
They’ve arrived at a clear understanding that in a requirements process, as in any system or product, the whole is more than the sum of its parts. An airframe, a pair of powerful engines, an avionics system and an aircrew … do not make an aircraft until they are integrated. When they work together, something new emerges, that none of the parts could achieve on their own: the ability to fly.
To make a requirements process ‘fly’, the first step is to understand that there is more than one kind of requirements model. A shopping list of requirements is invaluable in a contract, but on its own it’s desperately difficult to check for correctness and completeness; and it doesn’t offer any suggestions on how to discover requirements either. Different requirements models are needed to assist with discovering, checking and analyzing the requirements. The ‘shopping list’ is an output, not the one-and-only input.
Beatty and Chen identify four major classes of requirements model: those dealing with objectives; people; systems; and data.
Their Objectives come closest to traditional requirements, but starting at a much earlier and more tentative stage, looking at what a business’s objectives are and from there working out how those needs can be met.
People, obviously, means looking at who has an interest in the system under design, how they will use it, and what they want from it.
Systems means exploring the context, interfaces and events that govern what they new system will have to do. This is largely a traditional set of analysis techniques, often considered outmoded by those subject to the whims of software fashion – and it is creditably brave of Beatty and Chen to face up to this and to state clearly that old – even if incomplete – does not mean wrong. The point is, of course, that 1970s-style system analysis on its own was not enough – for example, it often failed for lack of proper attention to Objectives.
Finally, Data means defining the information that is needed by business users, and exploring how it is used within the system. Again, much of this is very traditional, though it covers not only data analysis but state models and report analysis – a modern take on an old topic.
There is a necessary complexity here. Requirements models interlock. Objectives relate to features which relate to processes which relate to use cases which relate to the user interface. Beatty and Chen show how this requirements architecture – you could call it a meta-model – can be tailored to the individual project. They have tried it, over and over, and it works.
The approach in this book is designed for software that supports business processes. Related but distinctively different requirements processes are needed for other kinds of project, such as developing a family of mass-market products that include both hardware and software. Beatty and Chen focus specifically on one world: the world of software for businesses. The result is an innovative but compelling requirements approach.
Ian Alexander, April 2012
You may also like:
