Writing Use Cases: Exception or Alternate Flow?

Learn when to describe an exception and when to go into an alternate flow. This is essential to improve readability of your use cases.

As you might all know writing use cases may be tricky. The template is as easy as you can think. But using it efficiently is not that easy. One question I have been asked several times lately is

When do I have to describe an Exception? What is an Alternate Flow?

Actually, the difference is very easy to explain.

1. Result negative: An Exception is anything that leads to NOT achieving the use case’s goal.

2. Result positive: An Alternate Flow is a step or a sequence of steps that achieves the use case’s goal following different steps than described in the main success scenario. But the goal is achieved finally.

Cancel is no Alternative! It’s an Exception

Anything that leads to NOT achieving the use case’s goal is an Exception.

Very often the user is requested to confirm a step like data entry or delete something. In that situation there is always the possibility that the user does not confirm but cancel the use case. So what happens? The system works perfectly right handling the cancellation. Nevertheless this is a typical Exception because it leads to not achieving the use case’s goal.

In the example below the user confirms the deletion in step 5. But there are two other options the user may select: He aborts the the deletion or he prolongs the deletion. Because both possibilities refer to step 5 they are numbered as 5a and 5b within the section Exceptions. Again, both exceptions are not caused by system errors or malfunction. But both exceptions lead to not achieving the use case’s goal, which is the deletion of the contract. In the first case the user will not delete the contract. In the letter case the contract is also not deleted but additionally put into the job queue for later assessment.

Alternatives lead to success

We consider any steps deviating from the main success scenario, which finally lead to a success of the use case as Alternative Steps.

There are many roads to Rome. The main success scenario describes the most likely way a user may take to achieve the business goal. Nevertheless, there may be other ways to perform a particular step or a sequence of steps. Those different paths are called Alternate Flows or Alternatives.

Below an example show how to delete a contract. From the pure business perspective this is most likely not the way we do that. But take it just as an example. In the first step the user’s navigates to the customer who’s contract to be deleted. Next he selects the particular contract (step 2). Instead of locating the customer the user may filter the huge list of contracts alternatively. As this is an alternative to step 1 of the success scenario it is numbered as 1a within the alternate flows. As it is nothing stated explicitly in the alternate step the use case will continue with step 2 of the main scenario. The user selects the contract and initiates the deletion.

Use case with two exceptions and one alternate step

How do you deal with this issue in your projects? I hope I could provide a rule of thumb to distinct between Exceptions and Alternatives. If there are any questions or suggestions don’t hesitate and write a comment.

#AlternateFlow #BusinessProcessAnalysis #Exceptions #UseCase