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.
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.
Here's a scenario outlining a successful withdrawal attempt at an
automated teller machine (ATM).
Now let's define a wider range of ATM functionality:
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
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/ ]