“Writing Effective Use Cases”, by Alistair Cockburn, is an excellent reading for those who want to learn the art of writing good behavioral specifications in the form of use cases. The book is fairly easy to read, it contains plenty of examples of use cases and also presents good tips and the pitfalls to avoid when writing a use case. In this post, I’ll summarize some of the things I learned from the book.
The whole point of the use cases technique is to describe interactions between actors in order to accomplish a goal, while protecting the stakeholders’ interests. They are usually written in simple text form (they can be either more casual or more formal, depending on the needs and characteristics of the project) and can be used to describe the behavior of any “system”, be it a software or an enterprise or business process (this is the “scope” of the use case). They can also be written viewing the system either as a white-box (considering the inner workings) or as a black-box (considering the external interface). The former is more used to describe business processes while the latter is more used to describe the functionality of a software system to be designed.
The author uses a set of graphical symbols to denote the scope (computer system, organization, component) and level of the use cases (summary, user-goal, subfunction). The idea of levels is an interesting one because it allows use cases to be treated as an ever-unfolding story – a piece of behavior can be a simple step in a use case or a use case of its own (to increase the level, ask “why”, and to decrease the level, ask “how”). Especially useful is the advice of writing a few summary use cases that connect all the other user-goal level use cases, thus providing overall context and a good starting point for whoever wants to quickly figure out the whole picture.
To make the most out of the writing process, the author recommends working breadth-first, from lower to higher precision. This way, it’s easier to manage the energy and not get quickly overwhelmed with lots of details of the extension conditions and extension handling sections.
It’s also emphasized that use cases are not all the requirements, they are only the behavioral requirements. There are other requirements, such as business rules, performance, protocols, UI, data formats, etc. However, use cases do act like a glue that connects all the other requirements. The author illustrates this through the “Hub-and-Spoke” model of requirements, which sees use cases as the hub of a wheel with the other requirements being spokes that lead in different directions; and that’s why some processes have a strong focus on use cases.
The author provides several reminders and checklists for improving the quality of a use case (those are nicely summarized at the beginning and at the end of the book). Among those, I quote the following three questions to be asked regarding every use case:
- To the sponsors and users:
- “is this what you want?”
- “will you be able to tell, upon delivery, whether you got this?” (acceptance tests are great for addressing this one)
- To the developers:
- “can you implement this?”
In a nutshell, the book is full of useful recommendations and what is exposed can surely be applied in order to improve requirements elicitation in any project, whether using use cases, user stories or any other technique.