Write Use Case Extensions

The real world is messy. Fortunately, extensions help us deal with all of that messiness.

Last time, we covered a few tips for writing the body of a use case – its main success scenario.

 

As the name implies, the main success scenario describes what happens when everything goes right. Of course, things don't always go right. In fact, all the stuff that can go wrong makes up the most important, most interesting parts of our requirements.

When writing use cases, we capture all of these other cases with an extension. An extension describes what should happen when 1) something goes wrong or 2) something succeeds but in a different way.
To write an extension, break it down into three parts. Each part answers a question:

1. Why is this happening?

For this to make sense, we need a sample scenario to work with. Here's a simple use case that describes how to create a new user account with a verification step. You've probably encountered something like this yourself.

Use Case: Create Account
  1. System prompts Guest for account information.
  2. Guest enters account information.
  3. System validates new account information.
  4. System sends Guest a verification code.
  5. System prompts Guest to enter the verification code.
  6. Guest enters the verification code.
  7. System validates the verification code.
  8. System creates account.

This is what happens when everything goes right, but lots of things could go wrong here. For example, the Guest user might enter the wrong verification code. Let's write an extension to handle that.
First, write a statement that describes what caused the extension to happen:

7.a. The verification code is invalid.

It should be something that our system can detect. We can't handle conditions that we can't detect.

Notice that I named the extension 7.a. We detected it at step 7 and it's the first extension we've identified. So we number it using a simple outline numbering scheme.

2. What happens now?

Now, describe what should happen when our extension condition is true (that is, the verification code is invalid). How should things work? In this example, there is just one thing to do: tell the user that the code is invalid.

7.a. The verification code is invalid.
1. System tells the Guest the verification code is invalid.

3. Where do we go next?

For this last step, describe what happens after the extension. Most times, it’ll be one of two things. Either we return back to the use case at another step or the use case ends altogether. In our case, we return back to another step.

7.a. The verification code is invalid.
1. System tells the Guest the verification code is invalid.
2. The use case continues at step 5.

With that, our extension is complete.

In theory, we’d keep all of our requirements simple and straightforward. But things start getting complex when describing all the errors and alternate cases our system has to handle. Extensions are a clean, manageable way to do it.

Watch this Next