example use case templatesample test plan templateProject plan template
ICS 121: Use Cases
- What are use cases?
- Why write use cases?
- How to write use cases
- How to write better use cases
- Use case diagrams
- Use case suites
What are Use Cases?
- Use cases are step-by-step descriptions of how an actor uses the
system to accomplish a goal. These steps are called the main
- Use cases are part of a Software Requirements Specification
- An actor can be a user, or another software system that
interfaces with the system being designed.
- The use case should focus on one success. Possible error
conditions or other failures are simply noted as extensions to the
main success scenario.
- Each use case provides one example of how one or more features
of the software product can be used together.
- Use cases are written in structured text: small amounts of
English text in a pre-defined format.
- Use cases should be precise enough that stakeholders can review
them to find defects.
Why Write Use Cases?
- Use cases are fast and easy to write (after some practice).
They require no training to read.
- Use cases are fairly concrete examples of how the system could
be used. They are easier to understand than other, more abstract,
ways of writing requirements.
- Use cases are examples of usage. Starting with just a few
examples is easy. More examples can be added incrementally as
- Use cases can be reviewed by non-technical stakeholders to help
- Use cases can easily be refined from user stories, and can later
be refined into scenario diagrams and test cases.
- Use cases cut across the features of the product, thus providing
a good complement to the more abstract, individual feature
How to Write Use Cases
- Start with a use case template, like the ReadySET
use case template
- First, have in your mind a firm understanding of the scope of the
system and the characteristics of the actor. E.g., an average
person using an ATM machine.
- Second, think of a specific goal that that actor would like to
accomplish. E.g., getting cash.
- Third, give the use case a descriptive name.
- Fourth, write out the steps done by the actor, the system, and
any other actors to accomplish that goal. Fill in enough detail so
that a person could follow your steps exactly to actually accomplish
- As you go, add notes to yourself and questions to come back to.
- Are there any preconditions that you assumed?
- Are there alternative ways to accomplish the same thing? E.g.,
cash withdrawal vs. fast cash. You can note them as extensions, or
write whole new use cases.
- Are there ways that the user can fail? Note some as
How to Write Better Use Cases
- Make the system more usable by putting yourself in the actor's
shoes. Would you want to work through this use case every day? Are
there too many steps? Are there difficult steps?
- Don't just call the actor a "User". Choose a more descriptive
name for that particular class of actor. E.g., at an ATM, a user
who is a customer of that bank might be a "Cardholder", and a user
who is not a customer might be a "Non-member-cardholder".
- Don't write implementation details into the use case. E.g.,
don't write "Non-member-cardholder presses the left-most button",
because the screen layouts have not been designed yet and could
change later. Instead, describe what the user is hoping to
accomplish. E.g., "Non-member-cardholder agrees to the transaction
- Don't describe how the system works internally, just describe
the prompts or results that it presents to the actor.
- Practice writing use cases
Use Cases Diagrams
- Stick figure: Actor
- Oval: Use case
- White arrowhead: generalization
- The main purposes of a use case diagram:
- Show all the names of the use cases, like a table of contents
- Show types and sub-types of actors
- Show relationships between actors and use cases
- Group use cases into informal clusters
- Show relationships between use cases
- Overall, use case diagrams are probably the least useful of all
the UML diagrams. The important part of use cases is their steps.
The information in a use case diagram can also be expressed in
lists, trees, and tables.
Use Cases Suites
- "Use case suite" is my name for a table of contents and a set of
use cases. The term "suite" implies a sense of completeness that is
not emphasized in a UML use case diagram.
- Imagine that you just have an unordered list of things. Is the
list complete? Are there important items being missed? How can you
know? E.g., red, blue, green, olive, gold, brown, gray, yellow,
beige, bone, eggshell, ecru, ...
- Now imagine that you have a space. There are some dimensions to
this space. Every possible value fits somewhere in that space. Now
you can see when something is missing. E.g., a colorwheel.
- You can define a logical space for use cases you using an
indented list or table. The values listed in the indented list
sections, or table headers, are elements of a set that you believe
is complete. E.g., a list of stakeholders, business objects, or
- Each section of the indented list or cell in the table should
have some use cases. If nothing is listed there:
- A use case is missing and could be added
- It is logically impossible for a use case there, so it can be
explicitly marked "Not applicable"
- Here is an template
for a use case suite