Books & People

back To Overview of Books & People

Books, People

Archives

Book Reviews

 

Book Review: Writing Effective Use Cases

Book | Authors | Review

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

Cover of Effective Use CasesAlistair Cockburn
Writing Effective Use Cases
Addison-Wesley, 2001
ISBN: 0201702258

Usability: Methodology

 

 

Author

Photo of Alistair CockburnAlistair 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.

 

top top