Usage scenarios, or scenarios for short, describe a real-world examples of how one or more people or organizations interact with a system. They describe the steps, events, and/or actions which occur during the interaction. Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not the indicating how they’re performed.Usage scenarios are applied in several development processes, often in different ways. In derivatives of the Unified Process (UP) they are used the help move from use cases to sequence diagrams. The basic strategy is to identify a path though a use case, or through a portion of a use case, and then write the scenario as an instance of that path. For example, the text of the “Withdraw Funds” use case would indicate what should happens when everything goes right, in this case the funds exist in the account and the ATM has the funds. This would be referred to as the “happy path” or basic course of action. The use case would include alternate paths describing what happens when mistakes occur, such as there being insufficient funds in the account or the ATM being short of cash to disburse to customers. You would write usage scenarios that would explore the happy path, such as the first scenario above, as well as each of the alternate courses. You would then develop a sequence diagram exploring the implementation logic for each scenario.
High-Level Example
Scenario: ATM banking for the week.
Sally Jones places her bank card into the ATM.
Sally successfully logs into the ATM using her personal identification number.
Sally deposits her weekly paycheck of $350 into her savings account.
Sally pays her phone bill of $75, her electric bill of $145, her cable bill of $55, and her water bill of $85 from her savings account
Sally attempts to withdraw $100 from her savings account for the weekend but discovers that she has insufficient funds
Sally withdraws $40 and gets her card back
Detailed Example
Scenario: A successful withdrawal attempt at an automated teller machine (ATM).
John Smith presses the “Withdraw Funds” button
The ATM displays the preset withdrawal amounts ($20, $40, and so on)
John chooses the option to specify the amount of the withdrawal
The ATM displays an input field for the withdrawal amount
John indicates that he wishes to withdraw $50 dollars
The ATM displays a list of John’s accounts, a checking and two savings accounts
John chooses his checking account
The ATM verifies that the amount may be withdrawn from his account
The ATM verifies that there is at least $50 available to be disbursed from the machine
The ATM debits John’s account by $50
The ATM disburses $50 in cash
The ATM displays the “Do you wish to print a receipt” options
John indicates “Yes”
The ATM prints the receipt
As you can imagine, there are several differences between use cases and scenarios. First, a use case typically refers to generic actors, such as Customer, whereas scenarios typically refer to examples of the actors such as John Smith and Sally Jones. There’s nothing stopping you from writing a generic scenario, but it’s usually better to personalize the scenarios to increase their understandability. Second, usage scenarios describe a single path of logic whereas use cases typically describe several paths (the basic course plus any appropriate alternate paths). Third, in UP-based processes use cases are often retained as official documentation whereas scenarios are often discarded after they’re no longer needed.
Usage scenarios are a major artifact in the Agile Microsoft Solutions Framework (MSF). They are used in combination with personas, descriptions of archetypical users such as John Smith or Sally Jones to explore the requirements for your system. With the Agile MSF you would write either style of usage scenario as appropriate, and you would keep the usage scenario only if your stakeholders are willing to make that investment in the documentation. The Agile MSF has been influenced by Agile Modeling, including the practice Discard Temporary Models.
