Book Review: Writing Effective Use Cases
By , SAP AG, Research & Breakthrough Innovation – 07/06/2006
This review takes a personal look at Alistair Cockburn's book Writing Effective Use Cases.
Book
Alistair
Cockburn
Writing Effective Use Cases
Addison-Wesley, 2001
ISBN: 0201702258
Usability: Methodology
Author
Alistair
Cockburn is an internationally renowned project witchdoctor and IT strategist,
is best known for describing Software development as a cooperative game,
for helping craft the Agile Development Manifesto, for finally defining Use
Cases, and for developing the Initial Response Technique massage form.
(From Cockburn's homepage)
Homepage: alistair.cockburn.us
Review
Target Group
As indicated on the cover, the book is targeted at software developers. It aims to help them learn how to write good use cases. Consequently, it's equally useful for software product managers, requirement engineers, user researchers, user experience professionals, and project managers.
Summary
Cockburn provides a practical guide on how to write good use cases. That
comprises a list of key elements like actors, stakeholders, design scope and
scenarios. A hierarchy of goal levels is defined to accommodate the breakdown
from an overall general goal into detailed steps (= smaller goals). For the
writing itself a sensible division in steps is suggested and templates are
provided. There are lots of examples and exercises throughout the book.
The "Reminders for the busy" are especially nice and helpful. They
are a summary of all the tips, which are important for use case writing.
What I Learned and Conclusion
Essentially, Cockburn tells you and teaches you how to make your use case an easy read by keeping the clutter out. This is achieved by handling extensions separately, linking to sub-use cases, handling use cases over several software releases, keeping diagrams and the graphical user interface (GUI) out, and focusing on short active sentences and the general guidance that less is more when it comes to the writing itself!
For me, the most important insight was how to handle failures. Cockburn doesn't
talk about failures, he recommends calling them extensions. And that's everything
that occurs as an obstacle to the primary success scenario. It can lead to
a failure or an alternate success ending of the scenario.
These obstacles have the tendency to appear en masse in the course of a software
project and slow down the progress considerably. Often it's the developer who
raises the question: "what happens if this or that condition arises " (for
example, a value is zero or a different system delivers erroneous input). I
suppose you can't rule that out completely, but with the structure that the
author proposes, you can discover those cases earlier on, answer them sooner,
and feed them into the requirements in the first stages of a software project.
I've read use cases that were complicated and clumsy because the author of the use case did not realize that a routine really represented a sub-use case. If a sub-use case is identified, it should not be handled in the main scenario but in a linked use case that is called from the main one.
Another piece of advice, which is true for a lot of topics: It doesn't matter if your use case is not perfect, if parts are omitted or unclear, as long as the communication of the development team – especially usage experts and developers – is excellent. The latter makes up for a lot of mistakes that might have been made during requirements gathering and the resulting use case texts. So why not work on it both ways – improving internal communication as well as the writing of use cases?
A use case is a central document, a link for all the people and roles involved
in a software project. And because there are so many different people with
so many different backgrounds involved, the use case needs to be understood
by everybody to serve as a connection. Human beings are well trained to communicate
in stories. That's also how we understand things and processes best – if
we get them in the form of a nice and logical story. We understand simple stories
and that's what a use case should be in my opinion.
Software development is a complex process by default. That's why I liked the
book; Alain Cockburn does a great job in helping you to at least keep your
use cases as simple and easy to read as possible.
