Once I'm ready to get down to the business of writing a use case, I ask myself a few questions: How big should this use case be? Where should it begin? Where should it end?
If a use case is too big, it'll be hard to understand. If it's too small, I'll wind up with too many use cases and it'll be hard to see the big picture. Here are four guidelines to help answer these questions and get the scope of your use cases just right.
To help illustrate the guidelines, consider the sample use cases shown here. They involve the system a cashier uses at your local supermarket.
#1 - Based on a goal. A use case describes how an actor uses the system to achieve a goal. In the example, the Scan Item use case is suspicious. Scanning an item sounds like a step - not a goal. On its own, scanning an item probably doesn't add measurable business value. If I wrote all of my use cases at this level, I'd wind up with way too many.
When faced with a use case at this low-level, ask why the actor is performing the step. The answer will often point towards the real goal.
#2 Complete or not complete. When an actor has performed the steps in a use case, the goal should be either 100% complete or 0% complete. Not somewhere in between. If a use case is so long that it could finish in varying states (that is, some of the goals achieved), then it's probably too big. The Work Shift use case in the example probably fails this test. The cashier has multiple goals that need to be met in the course of working a shift.
#3 One person, one place, one time, one event. Try to write use cases that describe how one actor responds to one event in one place at one time. The Work Shift use case seems to break this guideline. It sounds like it could take a long time and encompass many events. So it would probably wind up being too long and complex grasp in a few minutes. (While it's possible to write summary-level use cases aimed at higher-level goals, I'll leave that as an advanced topic for another day.)
#4 Six to ten steps. Try to keep the main success scenario (aka primary flow) of a use case between six and ten steps. Use cases should make requirements easier to comprehend. While there's nothing magical about 6-10 steps, it seems to be the sweet spot between writing a use case that is too small to deliver value (Scan Item) and too big grasp all at once (Work Shift).
Follow these four guidelines and you'll be on your way to writing use cases that your readers will understand without losing sight of the big picture.