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 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 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.
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.
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.
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