Writing Use Cases: Avoid IF THEN in use case steps

Checking conditions within a use case step blows out the success scenario. The use case is hard to understand. Instead relocate conditions and their actions to exceptions or alternate flows.

When it comes to use cases I often read success scenarios describing lots of conditions.

The use case goes like this:

Success scenario

Step 4: The system does <A>. But in case the actor has selected <option 1> in step 3 then the system checks if <option 2> is selected too. If that is the case then the system does <B>. If not the system does <C>.

I’m lost. Aren’t you too? It’s even hard to understand (decompile) if you write this down in a programming style. Unfortunately, I came across use cases with actually more levels of conditions.

The intention is to provide as much detail as possible. Of course business rules are important. But on the other side too much details are confusing. So how do we deal with that contradiction?

Ask yourself two questions:

1. How much detail is necessary to understand the use case?

2. What is the most likely scenario of the use case?

Reduce your success scenario to what is really needed. Relocate additional conditions and related actions to exceptions or alternate flows.

The answer to the first question tells you what to write. The answer to the second question tells you where to put it. Meaning in most cases you can reduce the amount of conditions that apply to a single use case step to one condition. In the success scenario you describe only this condition. By doing so you relocate the other conditions of that step to exceptions or alternate flows respectively. Whether you should take an exception or an alternate flow depends on the condition’s outcome. See Writing Use Cases: Exception or Alternate Flow?

Let’s try to rewrite the example above:

Success scenario

Step 4: The system does this <A>

Alternate flow

Step 4a – <option 1> selected: The system does <C>

Step 4b – <option 1> + <option 2> selected: The system does <B>

So what have we done? We reduced Step 4 of our success scenario to the one action that is most likely being performed. Furthermore, we relocated the other actions, which depend on particular conditions, to the alternate flow.

This is much easier to understand and you can follow the main scenario directly with no detours. Try it on your next use case. Your readers will love you.

#BusinessProcessAnalysis #Fachspezifikation #Methodik #AlternateFlow #UseCase #Exceptions