Writing Effective Use Cases

Writing Effective Use Cases
by: Alistair Cockburn

On my way to visit our development team in India, I packed a couple of books on user requirement definition and UML modeling. Delivery in software is highly dependent on getting this part of the work done in such a way, that all stakeholders in the process understand what you are talking about. Each stakeholder has different interests, different needs for information, and putting it all together has to be translated to time and money (and if this is not done well, disaster awaits).

The first very strong point of the book is that the author has clearly set out to put into writing his experience of teaching and working with group on use case writing. He has accomplished to do so, without falling into the trap of writing a manual-style prose, or restricting the freedom of his audience by presenting his approach as the only way to do it. There are many ways to write effective use cases, depending on the situation and the teams and stakeholders we are working with. And this the reader is constantly reminded of this fact.

Second, the book was written in 2001 and remains as up to date as it was then. I recognize most of the situations he describes, and he offers a concise and practical approach to retain focus on the work to be done, and working out the balance between detail and comprehensiveness of the requirements document. I especially enjoyed reading about his experiences with the differences in definition of “requirements” and “requirements document” that different stakeholders have. Managing these differences is one of the core activities in managing technology requirements.

The third and last strong point I want to highlight is the scope of the audience. I would recommend this book to anyone who has just been assigned for the first time to gather requirements. And I would do the same for any veteran, regardless of the methodology that he has been trained in or grown accustomed to. In our development team this book is a must read for the team leaders and the entire test organization.

The next step up (or down, in terms of detail) for this book is Applying UML and Patterns – An introduction to object-oriented analysis and design and iterative development by Craig Larman. In Chapter 6 this book uses Cockburn’s methods to the letter in the description of writing use. And then it proceeds to take the full deep-dive into object oriented modeling in the next 600 pages. Our CIO immediately put this book under his pillow. For my level of requirement definition it goes too far. For our development process however, it is key that these two stages of development go hand in hand and are connected through the reference literature we use.

I highlight a few points out of the concise listings of best practices that the author offers:

1. Use case writing is about writing prose.
2. Start by identifying all actors and use this as a basis for defining the primary actors of you SUD.
3. The starting point, and subsequent reference for all the work involved in the definition is the actor-goal list.
4. If you are using graphical modeling, limit your UML relationships to Include, Extend and Generalize associations.
5. Do not mix GUI, detailed work flow and detailed calculation descriptions with Use Case writing.
6. Use cases are the ideal starting point for test scenarios (so involve your test organization early on in the definition process!).

All in all, an enjoyable and useful book that will help you set up or help you re-evaluate you requirement definition process. Everything written here is included almost to the letter in the book of Larman (with, and sometimes without a clear reference, as in chapter 30), making the combination of these two books a solid basis for object oriented development processes in your organization.