Writing Effective Use Cases
Alistair Cockburn Humans and Technology in preparation for Addison-Wesley Longman, Q3 2000.
Page 1 of 204
Writing Effective Use Cases Prologue
There are still no trusted guides about how to write (or review) use cases, even though it is now nearly a decade since use cases have become the "norm" for writing functional requirements for object-oriented software systems, and are gaining acceptance for embedded software and business process reengineering work. I can say from firsthand attempts that is very difficult to articulate what makes a use case "good", let alone how to write them so they will come out being "good". This view is shared by many teachers of use case writing. The problem is that writing use cases is fundamentally an exercise in writing natural language essays, with all the difficulties in articulating "good" that comes with natural language prose writing in general. These are the guidelines I use in writing and coaching. The ideas came from listening to my on the fly inventions, describing to beginners what is going wrong, how to think and observe to get the writing to improve. This book has those guidelines, examples of use cases, variations that make sense - - and best of all, the reassurance that a use case need not be "best" to be "useful". Even mediocre use cases are useful, more useful than many of the competing requirements files being written. So relax, write something readable, and you will have done your organization a service already. Audience This book is predominantly aimed at the professional practitioners who read and study alone. For these people, the book is organized as a self-study guide. There are introductory, intermediate and advanced concepts, reminders and rules, examples, test questions with answers, and a set of discussions around frequently asked questions. The second group of people for whom this book is intended are consultants and coaches looking for explanations and sample use cases to show their project teams ways, to help them get better at their writing. The third group are instructors and their students. The instructors can build course material around the topics and exercises in the book, and issue reading assignments as needed. However, as I include answers to most exercises, they will have to construct their own exam material :-). Organization The book is written in 16 parts, to address the different needs of the various readers: 1. The One-Page Summary. Here it is in condensed form: what really matters, boiled down to one sheet you can photocopy and crib from. If you can understand and practice these sentence, I claim you can write as good a use case as you need at the time (see "Diminishing Returns"). 2. Base Concepts. The elements of use cases, from actors, through scope and goal levels, to postconditions and failures, sub-use cases. This section of the book provides the ABC's of use cases. 3. Related concepts. Building on the base concepts, what are different ways to write, how does UML work, what about quality, tools, project planning, and the information that didn't go into the use cases. 4. Reminders. Key phrases to remind yourself with. Assuming you know the ABCs of use cases, you will still need constant reminding about the Do's and Don'ts of good use case ©A.Cockburn 1999 Page 2 of 204
Writing Effective Use Cases
writing, little rules showing what is better, and what is worse. What strikes me as remarkable, writing these down, is how very many of them there are - which somewhat explains why it has taken us so long to articulate them. Hopefully, someone will come up with a shorter adequate list in the future. Writing samples. The best way to learn is to see "good" examples. They answer many little questions and gives us templates to build upon. Mistakes fixed. We also learn from comparing the "worse" with the "better". These show us the gradients the writing lives along,...