Use cases are a popular way to express software requirements.
They are popular because they are practical. A use case bridges
the gap between user needs and system functionality by directly
stating the user intention and system response for each step in a
Use cases are simple enough that almost anyone can read them.
Even customers or users can read use cases without any special
training. However, writing use cases takes some practice.
It is not difficult to start writing use cases, but really
mastering them takes training, practice, and insight.
No single use case specifies the entire requirements of the
system. Each use case merely explains one particular
interaction. An organized suite of use cases and other
specification techniques are needed to fully specify the software
The figure below illustrates where a use case document fits
into the overall software requirements specification (SRS) and
how it relates to other documents. This white paper focuses on
the yellow "Use Cases" box. Ideally, your use case document is
just one part of an overall set of project documents. But, don't
worry if you just want to jump straight into writing use
cases: this white paper focuses on them.
One goal of writing use cases is to specify the system to be
built, so that the resulting specification can be handed off to
someone else for implementation. Another important goal is to allow
potential customers to read the use cases and validate them. Long
before you reach these goals, you will find that the process of
writing use cases is itself a very useful way to clarify your own
thinking about the system requirements: by writing step-by-step
descriptions, you force yourself to think through the details of the
Use cases and feature specifications complement each other. Use
cases concretely explain how a user accomplishes a goal using one or
more features of the system. Feature specifications describe the
same system from a different perspective: a feature spec
abstractly describes everything about one software feature and all
it's possible uses.
It is a good idea to write the use cases and the feature specs in
parallel. For example, when working through a use case, you might
realize that a particular feature needs an additional option, so you
would note that in the feature spec. Likewise, when making a pass
over the feature specifications, you might realize that a feature
needs a particular input value to work properly, so you might need
to add a step to all use cases for that feature. Together, use
cases and feature specs provide checks and balances that help you
write requirements that are more complete, correct, and
The rest of this white paper works through the six steps shown in
yellow in the diagram below. Beside those steps, we show the
corresponding steps for writing feature specifications. (You may
notice that this is very similar to the test case writing steps.)
Note that in steps 4 and 5, we recommend that you only specify
the most important use cases in detail. In any complex system,
there will be a large number of potential use cases. It is usually
best to take a breadth-first approach: map out your use
case suite first, then fill in details incrementally as needed.
This concept is key to getting the most value out of the limited
time that you have to write specifications.
After the SRS is written, each part is used in later work on the
system. Both use cases and feature specs affect both the design and
quality assurance of the system. However, feature specifications
can affect the design more directly, and the use case suite can
provide a stronger starting point for the system test suite.
Step One: Identify Classes of Users
The first step in writing use cases is understanding the
users, their goals, and their key needs. Not all users are
alike. Some users will expect to walk up to the system and
accomplish one goal as quickly as possible. For example, some
banking ATM customers just want "fast cash". Others may be power
users who will master every option and shortcut over time.
It is important to identify and list classes of users so that
none of them are forgotten. Too often, an entire class of users
are initially overlooked, e.g., administrators. This leads to a
frustrating series of requirements changes when their
requirements must be added later.
Next, make sure that you know the key needs of each class of
user. For example, one class of user may simply need a speedy
transaction, whereas another class of user may need more guidance
in making choices, and a third class of user may expect to reuse
their knowledge of competing products.
Step Two: Outline the Use Case Suite
It is tempting to skip this step and jump directly into
writing a use case. After writing one use case, you would write
another, and so on. That process would be like coding your
application without outlining the design first. You would never
really know how much further you need to go before you are done,
if you were spending too much time in one area, or if you had
forgotten other important areas altogether.
The second step in our breadth-first approach to writing use
cases is to outline the use case suite. A use case suite is an
organized table of contents for your use cases: it simply lists
the names of all use cases that you intend to write. The suite
can be organized several different ways. For example, you can
list all the classes of users, and then list use cases under
One particularly good use case suite organization is to use a
grid where the rows are classes of users and the columns are
business objects. Each cell in the grid will list use case names
that are done by that class of user on that type of object. For
example, in an e-commerce system, shoppers would have use cases
for adding and removing products from their shopping carts. In
contrast, administrators might have some very different use
cases, for example, calculating the percentage of abandoned
The advantage of using an organized list or grid is that it
gives you the big picture, and helps you put your finger on any
area that needs more work. For example, in the e-commerce grid,
there might be a business object "Coupon". It is obvious that
shoppers use coupons, but it is easy to overlook the use cases
for administrators who must create coupons. If it is overlooked,
there will be a clearly visible blank space in the use case
suite. These clear indications of missing requirements allow you
to improve the requirements sooner rather than get bogged down in
too many frustrating requirements changes later.