Writing Use Case Extensions

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 ScenarioTo 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:System prompts Unregistered User for new account information: Full name Username Password Email address Unregistered User enters new account information. System validates new account information System sends account verification code to Unregistered User’s email System prompts Unregistered User for verification code Unregistered User enters verification code 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 ExtensionsWe 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 ConditionFirst, 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 EndingNext, 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.System displays an error message 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.