A use case is a description of a specific interaction that a user may
have with the software. Use cases are deceptively simple tools for
describing the behavior of the software. A use case contains a textual
description of all of the ways that the intended users could work with
the software through its interface. Use cases do not describe any
internal workings of the software, nor do they explain how that
software will be implemented. They simply show the steps that the user
follows to use the software to do his work. All of the ways that the
users interact with the software can be described in this manner.
Use Case TemplateA typical use case includes these sections, usually laid out in a table:
Name
| Use case number and name
| Summary
| Brief description of the use case
| Rationale
| Description of the reason that the use case is needed
| Users
| A list of all categories of users that interact with this use case
| Preconditions
| The state of the software before the use case begins
| Basic Course of Events
| A numbered list of interactions between the system and one or more users
| Alternative Paths
| Conditions under which the basic course of events could change
| Postconditions
| The state of the software after the use case ends
|
This example shows a final use case for a search-and-replace function (which is numbered UC-8):
Name
| UC-8: Search
| Summary
| All occurrences of a search term are replaced with replacement text.
| Rationale
| While editing a document, many users find that there
is text somewhere in the file being edited that needs to be replaced,
but searching for it manually by looking through the entire document is
time-consuming and ineffective. The search-and-replace function allows
the user to find it automatically and replace it with specified text.
Sometimes this term is repeated in many places and needs to be
replaced. At other times, only the first occurrence should be replaced.
The user may also wish to simply find the location of that text without
replacing it.
| Users
| All users
| Preconditions
| A document is loaded and being edited.
| Basic Course of Events
|
- The user indicates that the software is to perform a search-and-replace in the document.
- The software responds by requesting the search term and the replacement text.
- The user inputs the search term and replacement text and indicates that all occurrences are to be replaced.
- The software replaces all occurrences of the search term with the replacement text.
| Alternative Paths
|
- In Step 3, the user indicates that only the first
occurrence is to be replaced. In this case, the software finds the
first occurrence of the search term in the document being edited and
replaces it with the replacement text. The postcondition state is
identical, except only the first occurrence is replaced, and the
replacement text is highlighted.
- In Step 3, the user indicates that the software is only to
search and not replace, and does not specify replacement text. In this
case, the software highlights the first occurrence of the search term
and the use case ends.
- The user may decide to abort the search-and-replace
operation at any time during Steps 1, 2, or 3. In this case, the
software returns to the precondition state.
| Postconditions
| All occurrences of the search term have been replaced with the replacement text.
|
Use Case Development Script
As the use cases are developed, additional information about how the
software should behave will become clear. Exploring and writing down
the behavior of the software will lead a requirements analyst to
understand various aspects of the users’ needs in a new light, and
additional use cases and functional requirements will start to become
clear as well. As this happens, they should be written down with a
name, number and summary—once they are in this form, the analyst can
apply the four-step process to complete them.
The first step in developing use cases is identifying the basic ones
that will be developed. The list of features in the vision and scope
document is a good starting point, as there will usually be at least
one use case per feature (usually more than one). This will probably
not be the final set of use cases—additional ones will probably be
discovered during the development of the use cases.
Many requirements analysts have found that a four-step approach is
effective in developing use cases. The following script describes this
approach.
|
Name
|
Use Case Development Script
|
|
Purpose
|
A four-step approach to use case development
|
|
Summary
|
This approach to developing use cases allows the information to be
gathered and documented naturally, in a way that lends itself to an iterative
approach of alternating iteration, documentation and verification of use
cases.
|
|
Work Products
|
Output
Use cases
|
|
Entry Criteria
|
A requirements analyst has received feedback from elicitation and is ready
to develop use cases.
|
|
Basic Course of Events
|
- Identify the basic set
of use cases. Assign a name and number to each use case.
- Add a rationale and
summary to each use case. Identify which users will interact with each
use case and add them as well. Create a master list of user categories
that identifies all of the information known about each kind of user:
titles, roles, physical locations, approximate number of users in the
category, organizational policies they must adhere to, and anything else
that makes someone part of their category. Where possible, add
precondition and postcondition states to the use cases.
- Define the basic
course of events and the alternative paths for each use case. Finish
adding the precondition and postcondition states. If additional users
and use cases are discovered, add them as well (starting with just a
name and number, and then adding the other information as in Step 2).
- Verify each use case,
ensuring that all paths make sense and are correct. Go through each step
with user representatives to make sure that they accurately represent
the way they expect the users to interact with the software. Look for
any steps which are awkward for the user that could be made more
efficient. Finish all use cases which were added in Step 3.
|
|
Exit Criteria
|
The use cases are complete, and no additional information has been
uncovered which may lead to additional use cases being developed. If
additional use cases have been discovered, return to step 1 to fill them in.
|
|
