Daryl Kulak and Eamonn Guiney
Addison-Wesley, 2000
Daryl Kulak and Eamonn Guiney
Addison-Wesley, 2000
ISBN 0201657678 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
This is an interesting contribution to the hotly-debated literature on Use Cases. Kulak and Guiney focus quite strongly on software and on the UML, but at the same time propose their own definition of a use case and what it should contain, supported by clearly documented templates and examples. They explain in a fresh way the difference between the user's and the developer's points of view, and use this to critique traditional and older approaches to requirements -- would you really want users to look through DFDs, ERDs, and long lists of shalls, or try to define requirements by embodying them in prototypes? All those techniques have a place but they do not substitute for presenting things in a shared language.
This is one of the few book-sized works on use cases (another is Cockburn) as opposed to UML as a language.
I rather take issue with the assertion that
'By turning requirements specification into requirements engineering (a term we've avoided), teams often produce huge amounts of requirements documentation.' (p54)
This seems an altogether unwarranted assault on engineering. Given that the rest of the book concentrates almost exclusively on (business) software, one may suspect that the authors do not wholly appreciate the need to keep track of systems, subsystems, and interfaces in complex projects such as in transportation, telecommunications, defence, and aerospace. It really will not do simply to assert that
'Strategies for reducing volume are to leave the rote requirements (table maintenance and the like) until the end and to abstract use cases and business rules as much as possible.'
These two pieces of advice -- do custodial requirements last (as the Robertsons have long advised), and abstract away from individual details to create general rules, as everyone has tried to do for a generation -- are fine as far as they go, but they in no way address the desperate need to maintain order in large systems projects by defining and tracing requirements from one level down to the next, not to mention to design elements and test cases. Sometimes I feel that there are no real controversies, just people in different environments (e.g. Jack Carroll in the HCI community, Karen Holtzblatt in the design community, Kent Beck in the Agile Methods community, etc) talking past each other.
The book is well-indexed, has a short bibliography (suggesting that many of the ideas presented are novel), and is attractively illustrated.
This is an important reference for anyone wanting to put use cases to the test on a project. Many of the issues are plainly contentious enough for the book to have value to researchers also.
© Ian Alexander 2001