Page 113 -

Use Cases

Once the initial round of requirements elicitation is done and a discussion summary has
been distributed and reviewed, the requirements analyst is ready to begin creating use
cases. A use case is a description of a specific interaction that a user may have with the soft-
ware. 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 work-
ings 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.

A typical use case includes these sections, usually laid out in a table. Table 6-2 shows a
template for describing a use case.
TABLE 6-2. Use case template

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 of the 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 user 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 basic course of events is complete

Name, Summary, Rationale, and Users
Each use case must begin with information that allows the reader to uniquely identify it.
Every use case has a descriptive name and a unique identifying number. The number is
used as a way to refer to a specific use case in the SRS (see below). In addition to identify-
ing information, each use case has a summary, or a brief description of what the use case
does.

The “Rationale” section of the use case contains one or more paragraphs that describe why
the use case is needed. This serves as an important quality check to ensure the correctness
of the use case. While it is important that the team agrees on the behavior of the software,
it is equally important that they also agree on why the software is being created.
Each use case represents a series of interactions between the software and one or more
users. The users are divided into categories based on the way they interact with the soft-
ware; the “Users” section lists the kinds of users that interact with this use case. If all cate-
gories of users interact with this particular use case, it should list “any user” in this section.

SOFTWARE REQUIREMENTS 105