Author: Ivy F Hooks and Kristin A Farry
Amacom, 2001
Author: Ivy F Hooks and Kristin A Farry
Amacom, 2001
ISBN 0814405681 (boards)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Well, there aren't many requirements books advertised on their covers with the words 'Drawing on their 50 combined years of real-world product development experience …', so this one must be special. Ivy Hooks is one of the world's most experienced requirements engineers, with a distinguished career with NASA. She now runs her own company, The book is physically unusual - a hardback, printed on slightly crinkly porous paper in rather big elegant type, with almost an Art Nouveau feeling to the section headings. And it is illustrated with absolutely no UML and virtually no other diagrams - barring one waterfall model which, apart from the nine steps to requirements, is dismissed in a line and a footnote on other development models. The illustrations are cartoons, one or two graphs of the cost of putting off fixing the requirements, and some useful checklist-style tables. In short, this is a practical, lively, sharp and businesslike book, more like a 'Fix the Problem Before Your Competitor Does' exhortation to business managers from the airport bookshop than a discourse on the merits of sequence diagrams over flowcharts.
The authors’ backgrounds give them one huge advantage – they have wonderful stories to tell. The cost growth graph speaks volumes about the dire lack of requirements to keep project budgets and timescales under control back in the 1980’s. Here is firm evidence that a stitch in time saves nine: compare the well-run and modestly-overrunning Ulysses which invested ten percent of the effort ‘pre-design’, i.e. in requirements, with the 160% cost-overrunning TDRSS with only five percent invested. The graph also shows that after about 12 or 15% the returns from additional specification effort diminish to almost nothing – requirements are best done quickly but not too quickly.
The book is very readably organized, with chapters on, for instance,
Story-telling (shades of Schank) is in a way the theme of the book. It extends both to a firm commitment to writing operational scenarios (use cases, stories, does it matter) before writing [system] requirements; and to a stack of grey-boxed anecdotes, humorous and presumably true stories about everything under the sun. The military and the space agencies are of course a rich vein of tales that would just be funny if they were not so sadly wasteful. Daily life is also used to teach the basic principles – Hooks and Farry are evidently lively public speakers. For instance, Farry discusses the topic of restroom doors. Men never see any problem:
Aha, a woman’s viewpoint on requirements engineering coming up…
Now that’s what I call a vivid operational scenario. Obviously ‘moving the hook off of the door and occasionally [providing] a shelf for bags’ is a good idea, but it takes someone who actually uses the woman’s loo to know it. Farry gives an object lesson in requirements elicitation in inimitable style.
Trendy requirements engineers may not agree with everything in this book.
"Operational concepts are .. important.. but they are not the requirements. For example ‘The operator shall be able to turn the machine on and off.’
But is it? A manual switch is a choice, which might depend on several operational factors, such as whether the operator’s hands are free: a voice-operated switch might be needed. And does a microswitch that actuates a relay count as a manual switch? Perhaps the ‘real’ requirement is ‘The system shall enable the operator to turn the machine on and off.’ – which is pretty close to the requirement that the authors criticise. A modern formulation a la Use Case might simply be ‘The operator turns the machine on’ – which Hooks and Farry would certainly agree was an operational description – and the requirement would be that this capability was mandatory in Version 1.0 of the system. And the magnificent Space Station requirement
(I told you the examples were brilliant) is definitely not a system requirement as framed.
However, the authors are not speaking to the trendy end of the market. They are addressing hierarchical big-business management, encouraging them to take requirements seriously in language they can understand and laugh along with, and they are not far from being the first to do so. Hooks and Farry have managed to communicate exotic-seeming concepts like user involvement, viewpoints engineering and scenarios to an audience that is strongly oriented towards command-and-control (see The ClueTrain Manifesto for a radical view of this). They have achieved this through a combination of experience, skill at their jobs and at teaching, and not least by having worked in institutions at the very heart of the military-industrial complex – and yet having managed to retain a clear vision.
You wouldn’t expect an academic bibliography in this book and there isn’t one. Instead there is a short list of books that a business manager could reasonably get hold of for each chapter, and a helpful index. There’s no glossary, but the key terms should be pretty clear from the lively discussion and examples.
I think I can wholeheartedly recommend this book to its intended audience – ‘a product developer or customer, a current leader or aspiring manager’ as Kathryn Sullivan (astronaut, ret’d) puts it in the preface. It may be easy to assimilate, but it packs quite a punch. It tells the story as it is, and it speaks in plain language. Every manager new to requirements should read it on their next flight. Mind you, developers could do well to have a look at it too. © Ian Alexander 2001 You may also like:
"They just walk in the stall, close and latch the door behind them, hang their jacket on the conveniently placed hook above the latch, and use the toilet.
The scene is very different in the women’s restroom!"
"Women then hang coats and purses – both heavier than a man’s sports coat – on the hook on the back of the door, because there is no other place besides the dirty, wet floor to put them. If a woman is blessed with small children, the diaper bag and children’s survival gear also go on that hook. Is it any wonder that the hinges soon sag? To make matters worse, while Mom is supervising child one through toiletry 101, child two and child three are running about, trying to push open every door and swinging on those that they succeed in opening."
This description of .. what the operator will do .. is not a requirement on the system. The real system requirement is ‘The system shall provide a manual on/off switch.’"
‘The monkeys shall not bite the astronauts’
