Tuesday, December 22, 2009
Chapter 9: Use Cases and Scenarios and Stories, Oh My!
Chapter 9: Use Cases and Scenarios and Stories, Oh My!
Many
requirements analysts have learned that elicitation discussions that
focus on users and usage generally yield the best results. A
usage-centric approach to system specification is superior to the
traditional emphasis on system features and functions. Most users find
it more natural to talk about their business tasks and usage goals than
to try to identify all the functionality they expect to see in the
product. Use cases, scenarios, and user stories
are terms that are used frequently when describing a system's user
requirements (Alexander and Maiden 2004). These terms can be confusing.
This chapter more clearly defines these terms and concepts.
Use Cases
Use cases are all the rage in requirements circles these days.[1]
A use case is, literally, a case of usage. In other words, a use case
is a description of a sequence of interactions between the system and
one or more external actors—see Chapter 10, "Actors and Users"—that
results in an outcome that provides value to at least one actor.
Alistair Cockburn (2001) says that a use case "describes the system's
behavior and interactions under various conditions as a response to a
request on behalf of one of the stakeholders—the primary actor—showing how the primary actor's goal gets delivered or fails."
The name given to a use case should indicate the value
the use case will deliver to an actor. By convention, a use case name
always begins with a verb. The name also contains an object, which is a
noun. Adjectives and adverbs are optional. Good examples of use case
names are Reserve Rental Car, Print Invoice, Register for Payroll
Deduction, and Check Flight Status.
When
working with users to identify use cases, I often listen for the phrase
"I need to" to indicate that the user has a specific objective in mind
that the system can help him achieve. While discussing a proposed car
rental kiosk at an airport, for example, I might ask a user
representative, "When might you use a kiosk like this?" The user might
reply, "I would use it when I need to reserve a car." Parsing this
response tells us that one candidate use case for the product is
Reserve Rental Car. Another possible user response is, "I would use the
kiosk when I need to return a car I rented." This implies a use case
named Return Rental Car. Use strong, specific action verbs when naming
your use cases (Kulak and Guiney 2004).
You can describe use cases at various levels of detail. Figure 9-1
suggests a template for documenting use cases. You can download this
template, including guidance for completing each section, from http://www.processimpact.com/goodies.shtml.
Fully populating the various fields in the template creates quite a
rich description of the use case. However, it's not always necessary to
complete the entire template. For each of your use cases, consider
which of the following levels of detail is most appropriate.
Use Case ID: | |||
Use Case Name: | |||
Created By: | Last Updated By: | ||
Date Created: | Date Last Updated: | ||
Actors: | |
Description: | |
Trigger: | |
Preconditions: | |
Postconditions: | |
Normal Flow: | |
Alternative Flows: | |
Exceptions: | |
Includes: | |
Priority: | |
Frequency of Use: | |
Business Rules: | |
Special Requirements: | |
Assumptions: | |
Notes and Issues: |
Figure 9-1: Template for documenting a use case.
The simplest use case specification consists of a
unique identifier, a use case name, the actors involved in performing
the use case, a brief textual description, and perhaps the event that
triggers the use case execution. This is enough information to allow an
initial prioritization of your use cases, perhaps determining which
ones will be addressed in each
planned product release. Prioritizing makes sure the team invests its
energy working on the most timely and most important use cases.Most use cases will benefit from additional
information. At this level, you detail the normal flow of events,
showing the principal or default sequence of steps in the dialogue
between actor and system that leads to the actor's goal. Specify the
preconditions and postconditions for the use case, recognizing that
you'll refine them as you learn more about the use case and even as the
team gets into design and implementation of the use case. Also identify
the alternative flows and exceptions that could take place and any
pertinent business rules that affect the use case.A complete use case description includes the
previous items plus specifics about how the system will handle the
alternative flows and exceptions, as well as the remaining fields in
the use case template.
You can judge what level of detail is appropriate for a
given use case by considering how much information you need to
communicate to users, developers, and testers. You might perform an
initial use case analysis at the first level of detail and then refine
each use case further as it comes into scope for a particular release
iteration.
Use cases describe user requirements at a fairly high
level of abstraction. Use cases should be named to encompass a set of
logically related user tasks. These related user tasks constitute
separate scenarios, variations on a common theme. Scenarios represent
specializations of the general user goal stated in the use case name,
or alternative pathways by which the user could reach that goal. If you
find yourself caught in a use case explosion, with hundreds of use
cases for a modest-sized system, see whether you can combine related
use cases into a single, more general one. This merging involves moving
the use case to a higher level of abstraction that will encompass a set
of similar user tasks, thereby simplifying the requirements problem.
This past week, I had a discussion with a student
in a class I was teaching on use cases. He described two use cases from
his current project. One use case was Request Initial Reimbursement for
Travel Expenses and the second was Request Supplemental Reimbursement
for Travel Expenses. These sounded to me like two variations on a
single use case. Generalizing the use case name to be Request
Reimbursement for Travel Expenses could encompass both of these closely
related user objectives. This avoids the need to duplicate a lot of
functionality in two similar use case descriptions.
[1]I'm assuming that you already have some familiarity with use cases and the terminology associated with them: normal flow, alternative flows, exceptions, preconditions, postconditions, and so on. If these terms are unfamiliar, I refer you to Chapter 8 of Software Requirements, Second Edition (Wiegers 2003a) and to Use Cases: Requirements in Context, Second Edition
(Kulak and Guiney 2004). Note that the terminology used in various
books on use cases is not consistent, although the general principles
are.
No comments:
Post a Comment