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 these use case templates into your use cases document. This file itself should not be edited to hold specific use cases.
TODO: Use this template once in your use cases document. Anything you specify here will apply to all use cases in that file.
Use Case Document Header

Default Values for All Use Cases

Direct Actors:
ACTOR (default): DESCRIPTION
ACTOR: DESCRIPTION
ACTOR: DESCRIPTION
ACTOR: DESCRIPTION
Stakeholders: ONE SENTENCE DESCRIBING OTHER STAKEHOLDERS
Preconditions: CONDITIONS ASSUMED TO BE TRUE BEFORE THE FIRST STEP
TODO: Copy and paste these use case templates as many times as needed in your use cases document. Give each use case a unique ID. Only specify fields that are not the same as the default for all use cases.
One-Column Use Case Format

UC-00: USE CASE NAME

Summary: 1-3 SENTENCE SUMMARY
Priority: Essential | Expected | Desired | Optional
Use Frequency: Always | Often | Sometimes | Rarely | Once
Direct Actors: ACTOR1, ACTOR2, ACTOR3
Stakeholders: STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
Preconditions:
PREREQUISITE CONDITION
Main Success Scenario:
  1. visit STARTING-POINT
  2. STEP
  3. STEP
  4. see GOAL-WAS-ACHIEVED
Alternative
Scenario Extensions:
  • If CONDITION, then ALTERNATIVE STEPS.
    • NOTES or DETAILS.
  • If CONDITION, then ALTERNATIVE STEPS.
    • NOTES or DETAILS.
Notes and Questions
  • NOTE
  • NOTE
  • QUESTION
  • QUESTION

Two-Column Use Case Format

UC-00: USE CASE NAME

Summary: 1-3 SENTENCE SUMMARY
Priority: Essential | Expected | Desired | Optional
Use Frequency: Always | Often | Sometimes | Rarely | Once
Direct Actors: ACTOR1, ACTOR2, ACTOR3
Stakeholders: STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
Preconditions:
PREREQUISITE CONDITION
Main Success Scenario:
User Intention System Response
visit STARTING-POINT present INITIAL-SCREEN
STEP RESPONSE
STEP RESPONSE
STEP present GOAL-WAS-ACHIEVED
Alternative Scenario Extensions:
  • If CONDITION, then ALTERNATIVE STEPS.
    • NOTES or DETAILS.
  • If CONDITION, then ALTERNATIVE STEPS.
    • NOTES or DETAILS.
Notes and Questions
  • NOTE
  • NOTE
  • QUESTION
  • QUESTION

Use Case Attribute Values

Use Case Name Use case names are usually brief phrases that identify the actors' goal. If there are many use cases that accomplish the same goal, use trailing numbers to uniquely identify each use case.
Summary One to three sentences that briefly explain the actors' goal and strategy. This should have enough detail that another team member could understand it without reading the detailed steps.
Priority
  • Essential: The system would never be used without support for this use case, or it would be much harder to test, document, or package the product.
  • Expected: Key stakeholders strongly desire and expect support for this use case. It may have been promised to them in a certain release. Its absence would substantially reduce the success of the project.
  • Desired: Stakeholders desire support for this use case. Its absence would somewhat reduce the success of the project.
  • Optional: This use case would be nice to handle. Supporting it could have some advantage, but delaying support for it would not have a big effect on the success of the project.
Use Frequency
  • Always: Users carry out this use case every time that they use the product. E.g., all users must log in before using the system. Users can be expected to learn the steps and memorize them over time.
  • Often: Users perform this use case often. E.g., users can reasonably be expected to perform it at least once during a day of using the system.
  • Sometimes: This use case is done less often, but not rarely.
  • Rarely: Many users will never perform this use case. If a user ever needs to do it a second time, he/she probably will not remember his/her experience from the first time.
  • Once: Each user performs this use case once. E.g., registering for an account. That usage will always be a first-time usage.
  • If you can describe when a use case will occur, write a description as a phrase or sentence. E.g., "Once per user" or "Whenever a delivery contract expires".
Direct Actors Direct actors are users or other systems that directly interact with the system. The system itself is also listed as an actor. The actor marked with "(default)" is assumed to be performing each step that is not a system response or marked with the name of another actor.
Stakeholders Use case stakeholders are people who have a vested interest in how well the use case is carried out, even if they are not actually at the keyboard. E.g., in an e-commerce checkout use case, the manager of the shipping department is a stakeholder in all use cases where the user fills in a shipping address.
Preconditions Use case preconditions are conditions that are assumed to be true before the start of the use case. Using preconditions helps keep the use cases maintainable because common initial steps need not be repeated in several use cases. E.g., we assume that the user is logged in before he/she tries to edit his/her account information, we do not need to paste in the login steps here.
Main Success Scenario

Each step can be written very tersely using the following keywords:

login [as ROLE or USER]
The actor will log into the system as the named user or a user with the named role. Usually this is only stated explicitly when the use case involves actions that must occur immediately after login or when documenting a workflow between different users.
visit LOCATION
The actor will visit a web page or GUI window. State the user's intention, don't specify too much about UI details that could change later. E.g., WRONG: "Press the 'Advanced...' button on the File | Page Setup dialog". RIGHT: "Visit the print margin configuration dialog".
enter INFORMATION
The actor will fill in specific form fields. 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 widgets that might change later.
COMMAND-INTENTION
Describe a user choice or request that the user makes of the system. State the user's intent, not the label on a particular UI widget. This will usually be followed by a "see" step or a system response where the user sees a confirmation of their action. E.g., WRONG: "Control-P, OK". RIGHT: "Print the current document with default settings". WRONG: "Click 'OK'". RIGHT: "Confirm changes".
see CONTENT
"See" steps are used in the one-column format as one way to indicate system responses. 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". "See" steps can be omitted when the system response is obvious, e.g., "open pull-down menu", "see menu items".
perform USE-CASE-NAME
This is similar to 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.

Steps may begin with the name of the actor who is performing the step. E.g., in a two-person shopping application most steps might be done by actor "Consumer", but there could be a step "ShoppingAdvisor: enter product recommendation".

Note: Use case steps are intended for review by non-technical stakeholders, so they should avoid programming concepts such as branches, loops, or GOTOs. E.g., WRONG: "WHILE knows another coupon code, DO enter coupon code", RIGHT: "Enter any known coupon codes".

Alternative Scenario Extensions Use cases focus on the main success scenario. That main scenario is written as simple steps that do not normally include branches or loops. Instead, alternatives are listed as extensions. They can be:
  • Additional steps after the end that are only sometimes done
  • Error handling or exceptions
  • Alternatives that are not important enough to justify a separate use case
Note: if an alternative scenario exception becomes complex, it may be better expressed as a separate use case.
Notes and Questions Any notes that help explain the use case or relate it to the development process, and any questions that arise while specifying the use case.

Further Information

For more information on advice, see:

TODO: Check for words of wisdom for additional advice on this template.
Company Proprietary
Copyright © 2003-2004 Method Labs. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.