I explored the differences between writing use cases as generic scenarios versus specific scenarios the other day on the Requirements Defined Message Board.
I’ve most commonly seen and written use cases in the generic form. However, an alternative is to write them as more specific instances of those scenarios. The specific instance version is something I would use in test scripts, more than in use cases. Or at most, I would use it to provide additional information in story form, but not as a replacement for generic use cases.
The actual difference between these two is really in what nouns are used. For example, in the generic scenario, the actor would describe a user role, but if you wrote them as specific instances, the actor might be a specific person representing that role. Or, the direct object of the sentence might be an abstract object in the generic scenario, but a named object in the specific scenario.
To illustrate the difference:
Let’s say you have a system like Amazon.com. You need to write a use case to capture the purchasing process for a book. You define your actor for the use case to be an online customer.
In your generic scenario use case, you might have a step that looks like:
“Online customer searches for book.”
The comparable step in a specific instance of this use case would be:
“John searches for ‘The Not So Big House’.”
Of course, you could also get too general:
“Actor searches for object.”
Now, I can see that the specific scenarios may be easier to understand. Word choices like buying an “object” are hard to visualize, so a business user is likely to have their eyes gloss over if they cannot relate to the interaction described.
And certainly, the specific scenarios are more interesting to read. However, requirements are not meant to be interesting reading. Variety is significantly less important than clarity when documenting the system’s required functionality.
Therefore, as a general rule, I prefer the generic version of use cases.
When I read the more specific example, I have to think about who John is and what it would look like if we used Jane or Joe. There is a level of abstraction I end up doing in my head to remap John to being just any online customer. The same thing happens when I read the book title. I have to wonder whether the use case represents searching for a book or any type of object I might buy on Amazon. Even worse, if I do not know the title is actually a book, I’m going to be completely lost.
Imagine reading more than just one line, but rather an entire scenario in the specific instance format. It is that much more confusing to understand. After reading this much detail, I find that I lose touch with the original goal of the scenario.
A final concern is that you will miss the alternate scenarios in the use case. Typically, these fall out naturally if you review each step of a use case and look for alternates. But if the use case steps require more mental processing to understand, identifying alternates on top of that is even more unlikely.
I do think the specific scenarios have a place in the requirements documentation. If you write a generic use case and provide what I call a “story” along with it, then that can be extremely helpful to the visualization process for the reader. But the generic scenario is far clearer for the team to work from as the actual use case.
The key take away here is that there are varying levels of abstraction here. The abstraction hierarchy looks like object -> book -> Not So Big House. Each level down in the abstraction hierarchy is more specific. You can write the use case as a customer searching for an “object”, or more specifically, searching for a “book”, or even more specifically than that – searching for “The Not So Big House” book. At the top of this hierarchy, you have to be careful that you are not so abstract that your use case is not understandable.
The important thing is to know which level of abstraction is the right level. I think you need to pick “object” when all object buying is the same. But you need to pick “book” when buying a book is different than buying a CD, DVD, printer, shoes, camera or a purse. And I don’t think you ever should use a book title, except in writing stories to enhance use case understanding.
