Use Case Scenarios

Elaborating a Use Case

A use case diagram by itself is useless. Each use case should be associated with a use case elaboration. A use case elaboration consists of the following information:

Name:
Actors:
Description:
Priority:
Risk:
Scenarios:
   Scenario 1:
this is usually the main scenario
   Scenario 2:
an alternate scenario
   Scenario 3:
another alternate scenario
   ...

Priority

Priority measures the importance of a function: high, medium, and low. High priority indicates that the function must be present in the next release or the system will be useless. Medium priority means the function should be available as soon as possible. Low priority means that at some point in the future it would be nice to have.

Risk

Risk combines two measurements into a single factor called the risk magnitude indicator:

the probability that some problem will occur

the severity of the problem

Examples of problems include:

loss of resources: personnel, money, equipment

unanticipated complexity

Values of the risk magnitude indicator are:

high, significant, moderate, minor, and low

Balancing priority and risk can be tricky. As a general rule of thumb, all of the risk should come at the beginning of a project. If the project fails, let it fail before large commitments of time and money have been made.

Example:

Name: Transfer Funds
Actors: Account Holder, Bank Server
Description: The account holder transfers a specified amount of money from a specified source account to a specified destination account.
Priority: high
Risk: medium
Scenarios:
   Scenario 1: Funds are transferred successfully
      ...
   Scenario 2: Insufficient funds in source account
      ...
   Scenario 3: Source or destination accounts are in use
      ...
   Scenario 4: Invalid PIN
      ...

The main or success scenario is the most typical conversation in which the goal is achieved. Secondary scenarios describe conversations in which errors or other unusual conditions arise.

Scenarios

The most important parts of a use case elaboration are the scenarios.

A scenario describes the dialog between user and the use case.

A scenario is an instance of a use case.

If we think of a use case as a function declaration, then we can think of a scenario as a function call.

Scenario as a script

We can model a scenario using a script. For example, the main or success scenario for "Transfer Funds" begins by validating the account holder:

1. holder: inserts card
2. ATM:     reads card
3. ATM:     requests PIN
4. holder:  enters PIN
5. ATM:     validates PIN
6. ATM:     displays menu

Next, the user specifies that he wants to transfer a certain amount of money from a source account to a destination account:

7. holder:  selects transfer funds
8. ATM:     requests source account
9. holder:  selects source account
10. ATM:    requests target account
11. holder: selects target account
12. ATM:    requests amount
13. holder: specifies amount

Now the ATM asks the bank to transfer the specified amount from the holder's source account to his destination account:

14. ATM:    requests transfer funds
15. bank:   requests source account
16. ATM:    selects source account
17. bank:   requests target account
18. ATM:    selects target account
19. bank:   requests amount
20. ATM:    specifies amount
21. bank:   transfers funds
22. bank:   sends success
23. ATM:    displays success

The system redisplays the menu:

24. ATM:    displays menu

The insufficient funds scenario is almost the same as the success scenario except for messages 21, 22, and 23:

21'. bank:  detects insufficient funds in source account
22'. bank:  sends failure: insufficient funds
23'. ATM:   displays insufficient funds

Technically, the transfer funds success scenario consists of steps 8 through 17 in the script. The insufficient funds scenario can be thought of as a branch that breaks off from the main sequence after step 20:

14->15->16->17->18->19->20->21->22->23->24
                         |             
                        21'->22'->23'-> 24