Ian Alexander's Reviews of Books on Requirements Engineering and Related Subjects

Classic Book Review: Writing Effective Use Cases

Alistair Cockburn
Addison-Wesley, 2001

ISBN 0201702258 (paper)

Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)

This is a really clear, practical and above all simple account of how use cases - scenario-based requirement structures, introduced by Ivar Jacobson back in 1992 - can be put to work to specify system functions. It is not a complete textbook of requirements engineering:

"use cases .. are not all of the requirements - they are only the behavioral requirements but they are all of the behavioral requirements. Business rules, glossary, performance targets, process requirements and many other things do not fall into [this] category."

The book is based on a wealth of experience and offers much help to the beginner as well as to the practitioner. The focus is sharply practical but there is a short and helpful list of referenced books, papers, and online resources. Cockburn is especially good at stating what is not yet known and what needs to be explored further.

The book is, perhaps surprisingly, neither about UML nor a critique of it - as the author explains, most of what he has to say fits inside those little ellipses and is therefore compatible with the language. This is not to say that the UML concept or popular accounts of it are in Cockburn's opinion perfectly formed. In fact:

"…if you only read the UML standard, which does not discuss the content or writing of a use case, you will not understand what a use case is or how to use it, and you will be led in the dangerous direction of thinking that use cases are a graphical, as opposed to a textual, construction."

The diagram notation of the UML tends to divert attention away from the text; tricky concepts like generalisation and extension are not particularly suited to describing desired behaviour; and the language is poor at describing how use cases relate to each other (though other diagram types can indicate temporal relationships). What is more, though Cockburn does not say so, some of the terms chosen in the UML seem simply unfortunate; an agent, whether human or machine, is known as an Actor, and represented by a manikin figure - at best confusing, and at worst seriously misleading. Cockburn points out some of the difficulties, accepts that they are here to stay, and works around them by concentrating mainly on use case text. Specifically:

"The UML use case diagram, consisting of ellipses, arrows, and stick figures, is not a notation for capturing use cases. The ellipses and arrows show the packaging and decomposition of use cases, not their content. Recall that a use case names a goal… the ellipse diagram is missing essential information, such as which actor is doing each step [within the use case] and notes about the step ordering…"

Amen to that.

The book is neatly organised into Introduction, three Parts, and some useful Appendices. There is an effective Index.

The Introduction explains what a use case is "(more or less)", what they are good for, and how to get started.
Part 1 looks at the Use Case Body Parts - the contract for behavior, scope, stakeholders and actors, three named goal levels, preconditions, triggers and guarantees, scenarios and steps, extensions, and use case formats.
Part 2 looks at Frequently Discussed Topics, including completeness, scaling up to large systems, CRUD and parameterised use cases, business process modelling, linking to detailed requirements (including constraints), use cases in the overall process, extreme programming, and common mistakes (especially, too much detail, too low level, and designing the user interface).
Part 3 provides Reminders for the Busy, including reminders for each use case, for sets of use cases, and for ways of working.
Appendix A takes a dozen pages to explain use cases in UML, complete with the difference between the includes, generalises, and extends relations. The reader is recommended to take advantage of the rules of UML to customise the arrow styles so that the different relations appear visually different. For example, extends can be drawn with a coathanger-like hook connector so it doesn't look like generalises. Cockburn ends with the advice
"to spend time writing clear text, staying away from extends, and not worrying about diagrams."
The other Appendices offer answers to some of the exercises, a glossary, and a short list of references.

Cockburn organises use case text in many ways, supplementing it with icons to indicate black or white box views and level (high in the clouds, up with a flying kite, at the user-level ocean surface, underwater with the fishes, or 'too low' down amongst the clams). He has devised a range of templates of differing degrees of formality, from casual to 'fully dressed'. For comparison, the Rational Unified Process (RUP) style is illustrated; "I find the use case quite self-explanatory" comments the author, though we may add that, like his fully-dressed style, it is plainly a lot of work to document a use case in this style - Ian Graham tells the story that a corporation discovered it took 2 weeks per case; since they had 1500 use cases to write up, they abandoned the attempt to follow the RUP.

Perhaps the aspect of the book that is most open to criticism is the suggested applicability of use cases to everything from low-level subfunction specification to business process modelling: it certainly sounds like a strong claim. Cockburn devotes an entire chapter to the subject of business process modelling. He goes so far as to suggest that "often there is no time [to] write white-box business use cases .. without mentioning the new technology" followed by writing "black-box system use cases that show the new system fitting into the technology-free white-box business use cases". The solution is to dive right in to specification: "a light business process documentation will be generated as a normal part of the system requirements exercise." This may reinforce the worst fears of UML critics, who argue that the whole approach is back-to-front, starting as it does with an assumed system and working outwards towards 'users' whose function is to serve that system. Cockburn's perspective is admittedly that of a skilled developer, but he is aware that other people who are not developers exist and matter, and that system scope is a critical point of agreement.

I wholeheartedly recommend this book to everyone involved in defining what systems ought to do for their stakeholders. It is streets ahead of all other accounts of use cases. If the story is still not perfect, and if some of the claims seem a little too strong, at least the book is state-of-the-art. Use cases will not go away; they represent a genuine and practical recognition that scenarios ought to be identified and recorded, and they also indicate a definite movement in thinking among object-oriented designers away from coding towards specification and, with their emphasis on users, towards stakeholders and their requirements. This is to be welcomed.

Advanced students - and their teachers - will find this an useful source of ideas, though they should take care to find out about alternative views on requirements and scenarios. Practitioners of object-oriented development will need no encouragement; engineers used to more traditional styles of development will find the book challenging.

2009: Looking back at Cockburn's book all these years later, I still find it clear, practical and helpful. It is a valuable reference book, wonderfully accessible and astonishingly perceptive. Many things are clearer now, and requirements analysis is far better understood than it was then, but Cockburn's suggestions and framework for use cases have stood up well. It is said that any software book more than two years old is obsolete. Well, obviously this isn't a software book, but a timeless classic of system development or requirements analysis or something. It's a classic, no doubt about it, and the youngest such book on this website. Buy it at once! .

You may also like: