Use Case Template 101
I’ve noticed over the last 15 years or so that Use Cases are much less prevalent in business analysis requirements approaches. However, some organizations still use them, so we did give them a chapter in Visual Models for Software Requirements. If you want to jump ahead, you can download our Use Case Template to customize and re-use however you see fit.
Use Cases vs Process Flow vs User Story
Some organizations have moved towards User Stories to replace Use Cases. Others use Process Flows instead. However, neither of these are an exact replacement for the Use Case, so let’s talk about what you get from a Use Case and when to use it.
Most importantly, Use Cases are meant to capture user interactions with the system from the user’s perspective.
Process Flows
Process Flows only show the user interactions, not how a user interacts with the system. Process Flows show branching and looping more easily. But Use Cases allow you to include much more detail than Process Flows do at each step. In fact, they complement Process Flows by showing additional detail beyond the flow as to how the system responds to the user interactions.
User Stories
User Stories are not even close to a replacement for Use Cases because they don’t contain nearly the same amount of detail. In fact, a user story is more equivalent to the Use Case name, description, and organizational benefit than the full set of information that comes from this template.
When Should You a Use Case?
Use Cases are the well-rounded, but often forgotten model. They are great for requirements re-use. They are perfect to build user acceptance test scripts (UAT) from. They are easy to understand. They are easy to derive requirements from, by looking at them step-by-step. They are a great way to organize and prioritize work on a project. And Use Cases are the best if you want to show detailed interactions between the user and the system.
Improve Your Use Cases
Now if you are writing Use Cases, I have a couple suggestions that are not necessarily commonly accepted practice with business analysts:
1. Organizational Benefit: Capture this in a field of the Use Case. This can be a link back to the business objectives, but if not, needs to state how the Use Case contributes value to the business. This field is critical in prioritizing development of Use Cases.
2. Assumptions: Most people write assumptions that aren’t interesting or useful – probably because it’s hard to identify the good ones. However, think about what would get in the way of the Use Case reaching the desired benefits – those are assumptions. If you expect a certain number of people to execute a Use Case in order for the business objectives to be met, then state that assumption.
3. Don’t model system actors: Many Use Case descriptions say that you can describe the system-to-system interactions with them (in fact I used to say that!). An actor can be a person or a system right? Well, we strongly suggest not to do that. If you are describing the interaction between two systems, use a System Flow diagram instead. It is far easier to read the interactions in that type of model.
