Writing Use Case Extensions

©iStockphoto.com/WoodenheadWorld By the time you write your first complete use case, you’ll realize you’re going to have more extensions than use cases. Extensions are the primary way that use cases help us uncover the most important, interesting requirements that we might otherwise miss. So let’s talk about how to write a good use case extension.

First Comes the Main Success Scenario

To understand what an extension is, you must first understand the main success scenario. Of all the parts that make up a use case, the main success scenario is the most central. It describes the interaction between the actor and the system as the actor completes the use case. Here’s a main success scenario for a use case named Create Account:

  1. System prompts Unregistered User for new account information:
        Full name
        Username
        Password
        Email address
  2. Unregistered User enters new account information.
  3. System validates new account information
  4. System sends account verification code to Unregistered User’s email
  5. System prompts Unregistered User for verification code
  6. Unregistered User enters verification code
  7. System creates account

It’s called the main success scenario because it describes what happens when everything goes right. Of course, rarely does everything go right, but don’t worry about that just yet. Incidentally, if there is more than one way for a use case to go right, pick the simplest way and make that the main success scenario.

We start with the main success scenario because it’s the shortest path between zero knowledge and understanding what a use case is about. Our readers need this base understanding before they can go any further.

Then Come the Extensions

We still need to describe how the system should respond when things either do not go right or do go right, but not in the way we described in the main success scenario. We call these situations extensions. There are two varieties: exceptions and alternates. Exceptions are failure conditions (something went wrong). Alternates are simply a different way for things to go right. We treat them the same, so I’m not sure why I just bothered to explain the difference.

To create an extension, we need three pieces of information:

  • The condition that caused the extension to happen
  • The steps that will happen when the above condition is true
  • What happens when the steps are complete

The Extension Condition

First, write the condition. Alistair Cockburn identifies two essential traits for the condition: It must be something that the system can detect and it must be something the system will handle. Why? If we don’t limit ourselves to the conditions the system can detect, the possible conditions are endless. And if the system can’t detect a condition, we can’t do anything about it anyhow. So there’s no point in adding it to our requirements.

For example, in step 3 of the Create Account use case, username is already in use and email address is already in use are conditions the system can detect. In fact, since we’d handle both of these conditions in the same way, it will be more effective to collapse them into a single condition: username or email address is already in use.

While conditions like Unregistered User mistyped email address or Unregistered User enters someone else’s email address seem valid at first, it’s not something the system can actually detect (How do we know what the user’s email address is?). Now, if either of these things actually happened, the person who incorrectly received the email might choose to NOT verify the account in step 6. That’s something we can detect, and it’s a condition we’d want to handle.

The Extension Steps and Ending

Next, write the steps that describe what will happen when the condition is true. These are just like any other steps in a use case – they explain the interaction between the actor and the system. For example:

3.a. Username or email address is already in use.

  1. System displays an error message
  2. The use case continues at step 1

Finally, you might need to write what happens when the extension is complete. I have done this in step 2, above. After the extension, the use case might end, it might pick up right where it left off, or it might continue at another step. If what’s going to happen is obvious, you might choose not to explicitly say so – in the name of simplicity and brevity.

As I said earlier, you’ll quickly find that extensions will outnumber use cases. To find them, consider each step of a use case and brainstorm for the things that could go wrong or vary. Throw out the conditions you can’t detect or handle; combine the conditions that will be handled identically. Then describe how your system should handle them. You’re now prepared to uncover and handle requirements you might have otherwise missed.



Comments (4)

3/26/2009 8:41:42 AM #

ranjan

Your post very well clarifies how to cover alternate scenarios in an Use case and I fully agree with you that most of the times these scenarios covers major part of the use case.

But I think the usage of word 'extension' refers more to the situation when you have to  extend the use case or When you have modification in the use case during a change management process...
I would like to know your opinion on that ..

ranjan India


3/26/2009 11:23:48 AM #

Matt Terski

Ranjan, you are correct - I am using the word extension to describe additional scenarios that extend the main success scenario in a use case.

If you modify a use case during a change management process, wouldn't that simply be a new version of the use case? Maybe I don't understand. What in your use case would change in this situation?


Matt Terski United States


5/9/2009 6:17:35 PM #

ranjan

Hi Matt-

Thanks  for the response. Here is my situation-
In the current project as we are doing incremental  development, the requirements are evolving as the system is being  developed. So in the first phase we create  a requirement for the publisher to  be able to  'create an article' through a web form, we wrote an Use case, the component was developed and excepted by the users.
Now,in the next module, the business want an ability to  make 'Comments' optional on an article while they are creating the article. This is a new requirement and I have created an use case for this as 'Make Comments optional to an article', but this clearly linked to the use case of creating the  article. I have following doubts in my mind-
1. Does 'Make Comments Optional' <<extends>> 'Create an article' ?
2. Or does  'Create an article' <<included>> 'Make Comments Optional'?

I think the second scenario makes sense. As the making comments optional is included in the process of creating and article and not an alternate path to achieve the success (which in this case is creating the article).

Let me know your thought... thanks a lot in advance!!
Ranjan

ranjan India


5/20/2009 8:27:06 AM #

Philippe

Matt,

Excellent post! It is simple, logical and systematic. I have always struggled with the whole extension thing but after reading your post the “lights” really turned on in my mind. Keep writing...

Philippe United States


Comments are closed