- Customer requests a $300 withdrawal from checking, but the receipt roll is out of
paper. Customer is informed of the problem, and he chooses to proceed without a
receipt.
And so forth. Each scenario explores a variation on the original use case. Often, these
variations are exception conditions (not enough money in account, not enough money in
machine, and so on). Sometimes, the variations explore nuances of decisions in the use
case itself. (For example, did the customer want to transfer money before making the
withdrawal?)
Not every possible scenario must be explored. Rather, you are looking for those scenar-
ios that tease out requirements of the system or details of the interaction with the actor.
Establishing Guidelines
As part of your method, you need to create guidelines for documenting each scenario.
You capture these guidelines in your requirements document. Typically, you need to
ensure that each scenario includes the following:- Preconditions—What must be true for the scenario to begin
- Triggers—What event causes the scenario to begin
- What actions the actors take
- What results or changes are caused by the system
- What feedback the actors receive
- Whether repeating activities occur, and what causes them to conclude
- A description of the logical flow of the scenario
- What causes the scenario to end
- Postconditions—What must be true when the scenario is complete
In addition, you need to name each use case and each scenario. Thus, you might have the
following situation:
Use Case: Customer withdraws cash.
Scenario: Successful cash withdrawal from checking.
Preconditions: Customer is already logged in to system.
Trigger: Customer requests “withdrawal.”
Description: Customer chooses to withdraw cash from a checking account.
Sufficient cash is in the account, sufficient cash and receipt paper
are in the ATM, and the network is up and running. The ATM
asks the customer to indicate the amount of the withdrawal, and
344 Day 11