Use Case Format

PIMS SRS > Use Case Suite > Use Case Format

Process impact: This reference page documents the format of use cases and gives tips on writing use cases. You can copy and paste the sample use case into your Use Cases document. This file itself should not be edited to hold specific use cases.

Some definitions

Use cases:	A use case is intended to document all possible sequences of interactions between a user and the system to accomplish a goal. The goal is defined in the title (UC_name), and summary sentences of the use case.
Scenario:	A sequence of interactions is called a scenario and the most likely sequence which achieves the goal is called the "Main Success Scenario". Where the goal can also be achieved via a different sequence of interactions, an "Alternative" scenario is documented, with the steps called "Extensions". Alternative scenarios are also documented which represent a "failure" to achieve the goal, and the steps to recover from that failure. For example, a use case might document the sequence of interactions between a customer and a cash dispenser to obtain money. A failure might occur if the user enters an incorrect code for their card. The recovery would be re-entering the correct code.

Use cases:

A use case is intended to document all possible sequences of interactions between a user and the system to accomplish a goal. The goal is defined in the title (UC_name), and summary sentences of the use case.

Scenario:

A sequence of interactions is called a scenario and the most likely sequence which achieves the goal is called the "Main Success Scenario".
Where the goal can also be achieved via a different sequence of interactions, an "Alternative" scenario is documented, with the steps called "Extensions".
Alternative scenarios are also documented which represent a "failure" to achieve the goal, and the steps to recover from that failure.

For example, a use case might document the sequence of interactions between a customer and a cash dispenser to obtain money.
A failure might occur if the user enters an incorrect code for their card. The recovery would be re-entering the correct code.

Aspects common to all use cases

Direct Actors:	User: end-user in any role System: The PIMS system being built When actors are not listed, assume User is doing it. Items beginning with "see" indicate that System has presented a new screen.
Stakeholders:	Project Owners and other members
Prereq:	User is logged in except for UC-Log in

TODO: Copy and paste this use case template as many times as needed in your Use Cases document. Only use those fields that are not the same as the default for all use cases and are required.

UC-name: USE CASE NAME

Summary:	1-3 SENTENCES
Importance:	Essential \| Expected \| Desired \| Optional
Priority:	Essential \| Expected \| Desired \| Optional
Use Frequency:	Always \| Often \| Sometimes \| Rarely \| Once
Direct Actors:	ACTOR1, ACTOR2, ACTOR3
Prereq:	PRECONDITION
Main Success Scenario:	STEP STEP STEP
Alternative "index" Scenario Extensions:	BRANCH CONDITION ALTERNATIVE STEP ALTERNATIVE STEP ALTERNATIVE STEP
Variations
Notes and Questions	NOTE NOTE QUESTION QUESTION

Format of Use Case Steps

Try to start each step with one of these action words:

login [as ROLE or USER]: Log into the system with a given user or a user of the given type. Usually usually only stated explicitly when the test case involves a workflow between different users.
visit LOCATION: Visit a page or GUI window. State the user's intention, don't say too much about UI choices that could change later. E.g., WRONG: "Press the 'Advanced...' button on the File | Page Setup dialog". RIGHT: "Visit the page margin configuration dialog".
enter INFORMATION: Fill in specific information. Try to state the information in some detail. E.g., WRONG: "Enter customer information." RIGHT: "Enter customer shipping address and discount code." Don't commit to details of a particular UI, i.e., don't name specific UI fields that might change later.
COMMAND: Describe a command that the user can tell the system to do. State the user's intent, not the label on a particular UI widget. This will usually be followed by a "see" step where the user sees a confirmation of their action. E.g., WRONG: "Control-P, OK". RIGHT: "Print the current document with default settings".
see CONTENT: The user should see the specified information on the currently presented web page or GUI window. Try to be specific about the information that is seen, but try not to refer to specific UI elements. E.g., WRONG: "see UserList.jsp" (what is the user supposed to notice on that page?) RIGHT: "see list of users with the newly added user in the list".
perform USE-CASE-NAME: This is like a subroutine call. The user will do all the steps of the named use case and then continue on with the next step of this use case.

Importance

This relates to how important the use-case is to the success of the project.

Priority

Relates to when the use-case is needed. Is it a high priority for a planned release?
There may be use-cases which are vital for the success of the project and so have a high "Importance" rating but can be postponed for a while

Alternative Scenario Extensions

These can be either failures, or sucesses via an alternative route.
Label each alternative with an "index" as follows:
The number of the step in the "main success scenario" at which the "alternative" occurs, followed by a lower case letter to indicate how many alternatives begin at this step.
e.g. Alternative 2a is the first alternative for step 2.
Then list all steps in the alternative scenario which will be numbered from "1"

Variations

These are where a step has significant alternatives but all are followed by the same next step.
Use the "VALUE" attribute to indicate the step in the Main Success Scenario where the variation occurs and give details

Further Information

For more information on advice, see:

Words of wisdom on use case suites.
Words of wisdom on use cases.

TODO: Check for words of wisdom and discuss ways to improve this template.