This Course has been replaced by CSE557

Contents


    SD's Agile Modeling Newsletter

      January 2006

      Modeling the Real-World: Usage Scenarios By Scott W. Ambler

      This monthly e-mail newsletter is a free service for subscribers to Software Development magazine and SD Online. This newsletter is supported by advertising, and we appreciate your continued patronage. If you do not wish to get this monthly update, please follow the unsubscribe directions at the bottom of this message.

      Adverts removed by RJBotting

      A usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. It describes the steps, events and/or actions that 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. Let's work through examples of each.

      The Nitty-Gritty: A Detailed Example

      Here's a scenario outlining a successful withdrawal attempt at an automated teller machine (ATM).

      1. John Smith presses the "Withdraw Funds" button.
      2. The ATM displays the preset withdrawal amounts ($20, $40, ...).
      3. John chooses the option to specify the amount of the withdrawal.
      4. The ATM displays an input field for the withdrawal amount.
      5. John indicates that he wishes to withdraw $50 dollars.
      6. The ATM displays a list of John's accounts: a checking and two savings accounts.
      7. John chooses his checking account.
      8. The ATM verifies that the amount may be withdrawn from his account.
      9. The ATM verifies that there is at least $50 available to be disbursed from the machine.
      10. The ATM debits John's account by $50.
      11. The ATM disburses $50 in cash.
      12. The ATM displays the "Do you wish to print a receipt" options.
      13. John indicates "Yes".
      14. The ATM prints the receipt.

      The Sky View: A High-Level Example

      Now let's define a wider range of ATM functionality:

      1. Sally Jones places her bank card into the ATM.
      2. Sally successfully logs into the ATM using her personal identification number.
      3. Sally deposits her weekly paycheck of $350 into her savings account.
      4. 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.
      5. Sally attempts to withdraw $100 from her savings account for the weekend, but discovers that she has insufficient funds.
      6. Sally withdraws $40 and gets her card back.

      Usage scenarios are applied in several development processes, often in different ways. In derivatives of the Unified Process (UP), such as the Rational Unified Process (RUP), ICONIX and the Agile Unified Process (AUP), you would use scenarios to move from use cases to sequence diagrams. Basically, you would 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 happen 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 also include alternate paths describing what happens when mistakes occur, such as an account having insufficient funds 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 alternate course. You would then develop a sequence diagram exploring the implementation logic for each scenario.

      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, while scenarios typically refer to specific actors such as John Smith and Sally Jones. You could write a generic scenario, but it's usually better to personalize it to increase 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; scenarios are often discarded when they're no longer needed.

      Usage scenarios are a major artifact in the Agile Microsoft Solutions Framework (MSF), and are used in combination with personas -- that is, 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 high-level or detailed scenarios as appropriate, keeping them only if your stakeholders want invest in the documentation. Agile MSF has been influenced by the Agile Modeling methodology, including the practice "Discard Temporary Models."

      Usage scenarios are often simple and to the point. In fact, the level of detail shown in this newsletter is often all you need. I'm a firm believer in discarding scenarios once you've begun working on another artifact, such as a UML sequence diagram or, better yet, working software. Of course, I believe in discarding most models that are created during development because I prefer to travel as light as possible.

      Because usage scenarios are straightforward and stakeholder- oriented, they're very inclusive in nature and stakeholders can actively participate in their creation. In short, usage scenarios are a valuable addition to your intellectual toolbox.

      --Scott W. Ambler

    Abbreviations

  1. TBA::="To Be Announced".
  2. TBD::="To Be Done".

    Links

    Notes -- Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] -- Choices [ c1.html ] [ c2.html ] [ c3.html ] -- Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] -- Rules [ r1.html ] [ r2.html ] [ r3.html ]

    Projects [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]

    Field Trips [ F1.html ] [ F2.html ] [ F3.html ]

    [ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]

End