Information Technology Reference
In-Depth Information
Define the subordinate as a complete stand-alone use case documenting the
applicable sequence. Use it to support the main use case, however, do not repeat
the information. For each main use case, consider the alternatives. For example, an
application received by mail may have slightly different processing, than an
application received in person. Identify the main exception processes. For exam-
ple, applicants for driver's license renewals may have their renewals automatically
issued, unless they have outstanding summonses. Review the interactions by
developing sequence diagrams for the subordinate use cases.
6.6.3 Scenario Development
The use of scenarios is a development technique by which the developer maps the
possible user interactions with the system. An individual scenario represents the
experience of a single actor during an interaction with the system. In order to identify
the scenarios that will be used, developers observe users and create a set of scenarios
to represent the functionality that the system will have. These scenarios represent
hard evidence for the way in which the system will be used. They also provide
another chance to gain user feedback on the system. Scenarios are distinct from use
cases in that they provide information about ''specific instances and concrete
events'' (Bruegge and Dutoit
2004
). For this reason, they cannot replace use cases,
but they are extremely useful tools for communication with the user and client, and
for classifying that information in a way that is meaningful to the development team.
The following list provides a number a scenario types (Carroll
1995
):
• As-is Scenario: Describes a current situation. Provides a picture of the system
based on scenarios derived from observing users and classifying their actions.
User input can be used to ensure that the scenarios are correct and accurate.
• Visionary Scenario: Describes a future system. Used in refining the developer's
understanding of the system being developed by serving as a point in the
modeling space. Also used as a way to communicate with users in order to elicit
new requirements. Commonly considered a cheap, idea-based prototype.
• Evaluation Scenario: Evaluates the system by describing user tasks which have
been selected for use as testing criteria for the system. Used to refine and
improve the functionality definitions that they test.
• Training Scenario: Tutorials designed to introduce a new user to, and allow
that user to get acquainted with, the system. The user is walked through com-
mon tasks via a step-by-step tutorial of the system.
A scenario represents a single actor's interactions with the system, and is thus a
sequence of events that the system will manage and handle. In this way, a specific
scenario describes one possible process and outcome for a single use case. Because
a use case may be worked through in various ways, multiple scenarios may be
needed to describe it completely (Stiller and LeBlanc
2002
).
