From Goals to Use Cases

Here’s a common scenario for many of us who have learned about uses cases but haven’t written one yet: You’ve identified the actors for your project. You’ve brainstormed a list of goals for each actor. You’re ready to create your first set of use cases. And you feel stuck. Or at least uncertain. Call it use case writer’s block. You could point to a use case if you saw one, but what are your use cases?

When this happens, remember that use cases are based on actor goals. If a use case doesn’t describe how an actor gets something done, it’s not really a use case. Does that mean that every goal becomes use case? Not necessarily. Goals address needs at many levels – from very high levels to very low levels and infinite shades in between. Consider the following goals:actor goals

  • Relax
  • Plan a vacation
  • Reserve a room
  • Find a resort
  • Pick a destination
  • Type the name of a city into a text box
  • Open a web browser

These are all related goals, but at different levels. Not all of them will make for a good use case. Pick a high level goal and the use case will either be too big to comprehend or too imprecise to guide decisions. Pick a low level goal and the use case will be too small and you’ll need too many of them to describe the system. This is starting to sound like a fairy tale involving three bears, but – you guessed it – the best goals are neither too high, nor too low, but just right.

If you’re wondering what goal levels are just right, here’s a more concrete guideline from Craig Larman’s Applying UML and Patterns: Write use cases at the level of the elementary business process (EBP):

A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.

There are exceptions to this guideline, of course. You might want a high-level use case that puts context around the EBP use cases. You might occasionally want a low-level use case that describes a complex sub-process. When you’re identifying the bulk of your use cases, however, most will address goals at the EBP level – something one actor can complete in one place at one time.

To identify the use cases in your system, look at the list of goals you’ve brainstormed. Is each goal written at the elementary business process level? For goals that are written at a level lower than a business event, consider why the actor wants to achieve that goal. It’s probably just a step towards a higher level goal. For goals that are written at a level higher than a business event, consider how the actor would go about achieving that goal. There’s probably an intermediate step that has more business meaning in the system you’re defining.

So, back to our use case writer’s block. You’ve just broken through. Each of the EBP-level goals you identified answers the question: What are your use cases?

Comments (4)

4/16/2010 5:42:14 PM #

Adam Bradley

Nice post Matt!

Good to see you back Wink

Adam Bradley Australia

4/27/2010 9:20:02 AM #

Stan Meyers  Systems Management Inc.

While I found your description interesting I think it creates an opportunity to lose the forests through the trees.

I must admit I have never used your Case Tool, however it has been my experience that it is best to define requirements from the top down and not the inside out. By going inside out it will generally lead to a suboptimization of subsystem functions and a greater potential for missing critical requirements. A system of suboptimized functions does not result in the best or the right system.  

Stan Meyers Systems Management Inc. United States

4/27/2010 11:23:30 AM #

Matt Terski

Hi Stan,

I disagree with your premise that starting with goals is an inside-out approach. In fact, it’s just the opposite.

We start by answering the question of why the system needs to exist in the first place. We do this by asking who needs to use the system (actors) and why do they need to use it (goals). From there, we work downward towards more manageable goals (the topic of this post), then to use cases and other supporting requirements.

With this approach, we’ll more likely build the right thing and less likely to miss critical requirements.

Matt Terski United States

10/17/2013 7:05:15 AM #


if you line up all the analysts in the world end to end you will never reach a conclusion.

There are numerous variations on what a good use case is depending on who you read or talk to.


Comments are closed