ICS 121: 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 success scenario.
Use cases are part of a Software Requirements Specification (SRS).
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.

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 needed.
Use cases can be reviewed by non-technical stakeholders to help validate requirements.
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 specifications.

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 the goal.
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 may note them as extensions, or write whole new use cases.
Are there ways that the user can fail? Note some as extensions.

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 fee."
Don't describe how the system works internally, just describe the prompts or results that it presents to the actor.
Practice writing use cases

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 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 by 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 operations.
- Each section of the indented list or cell in the table should have some use cases. If nothing is listed there, then a use case is missing and could be added. Or, 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