What is an extension use case?
We have already discussed the concept of alternative paths. An alternative path is an alternative sequence of interactions that branches off from the primary (or another) path at an extension point, if the alternative path's precondition is true at the extension point. The alternative path may finish as an alternative end to the use case (often failing to meet the use case goal, but in a controlled way), or may remerge back onto the original use case sequence at a merge point.
When developing the requirements, alternative paths are viewed as supplementary parts of the use case that has the specified goal name. Sometimes though, in conversation with the stakeholders, we discover that the stakeholder has what they consider to be an additional use case with a goal in its own right. As modellers, we realise that this supposed additional use case is to all intents and purposes an alternative path within another use case we have already modelled.
The definition of an extension use case, then, is a use case with a goal of its own, but that is in all other respects an alternative path within a separate use case that has its own goal, distinct from that of the extension use case.
Example
Consider our vending machine, dispensing drinks or phone top-ups. Our stakeholder might decide that he or she would like the machine to dispense receipts for items purchased, and views this as a use case goal significant in its own right. As modellers, we realise that this can only happen as some optional additional steps within the other use cases that represent purchases. Maybe the extension use case is described as follows:
Obtain receipt
When payment for an item has been made, and change dispensed, the system asks the user if they would like a receipt. The user may choose to press the 'receipt requested' button. If pressed within 5 seconds, a receipt is printed for the current transaction, giving the time and date, the item bought and the price paid. The user takes the receipt.
Notice the use of 'when' and 'if' in the first part of this use case. This is a textual representation of an extension point in one or more other use cases, and a precondition that will cause this optional sequence to be invoked. There is also an implied remerge point at the end of this use case description where it continues back on the originating use case where it left off.
In order to address the stakeholder's vision that this is a goal-driven requirement in its own right, we capture it as a separate named use case. The use case will have as its precondition the precondition that causes it to branch from the originating use case. It will also have an identified extension point in that originating use case. Thus in all respects it behaves like an alternative path, except that it has its own goal.