Use Case - Alternative courses (2 of 2)

In our previous blog  we introduced the notion of alternative actions.  Alternative actions are deviations from standard behavior ranging from simple alternatives that do not disrupt the flow of the use case to full blown error exceptions.  How we document the alternative actions will depend on how that action affects the flow of the use case.

In the previous blog , we discussed alternative actions that could be handled inside the use case itself.  Now lets move on to alternative actions after state C.

State F

At this point the actor has successfully inserted his ATM card and it has been read.  We are now prompting the actor for his PIN. At this point we only have a few viable continuation paths:

1. The user enters a PIN
2. The user cancels the transaction
3. The ATM times out waiting for user input
   

The actor can enter his PIN in many different ways, but, between entering different digits and hitting the correction button most of these alternative actions do not change the flow of the use case.  We can handle this alternative by putting a table of valid inputs inside of the use case:

The user enters a PIN

Field	Type and Length	Comment
PIN	Numeric 4 digits	Digits to be entered with the keypad and will be drawn from left to right Digits will be masked with ‘*’ character
Correct	Button	Clears all entered key strokes
Ok	Button	Submits the form to the system

The user cancels the transaction (state G)

The actor canceling his transaction can certainly be handled inside of the use case by listing out all the alternative courses where the user can hit the cancel button.  However, the actor can hit the cancel in almost all use cases and to document all the alternative courses would be burdensome.

This kind of interruption in the flow of the use case is best documented on the use case diagram as a separate use case.  First we show the original use case diagram:

And we show virtually all of the use cases can be affected by the Cancel transaction functionality as follows:

An extended use case is functionality that extends an existing use case but is optional.

The Cancel Transaction use case would look as follows:

ATM times out (state Z)

An ATM time out can be handled the same way as the cancel transaction use case.  It should be in a separate use case that extends all use cases that have input, however, there are a few differences:

• This behavior is based on a system event, not a user event
• The user should be prompted on whether to continue or not, so the use case flow will depend on how the user responds to the prompt

 The ATM time out use case would look as follows:

Use cases

Use case	Actors	Type	Importance	Frequency
Authenticate user	Customer	Normal	Normal	1000 / day
Withdraw money	Customer	Normal	Very high	1000 / day
Cancel transaction	Customer	Extended	High	50 / day
Time out	Customer	Extended	High	100 / day

Summary

• Some alternative actions can be handled inside the use case, others are handled with separate use cases
• Optional use cases are shown by extensions on the use case diagram
• Alternatives during user input can be handled inside the use case
• When user inputs alter the flow of the use case or flow between the use cases it needs to be documented