The Use Case Document is a business document which provides a story of how a system, and its actors, will be utilized to achieve a specific goal.

STANDARDS FOR PRESENTING USE CASES:

1) Use case name: The use case should be labeled so that it immediately describes the purpose of the use case. Usually, VERB/NOUN is sufficient. For example, “Place Order.”

2) Actors: Identify who the main individuals and systems involved in the use case are going to be. Any actor that is used in the use case’s flow of events must be named up front.

3) Assumptions/Pre-conditions: Define what the state of the world is prior to the beginning of the flow of events described in the use case.

4) Post-conditions: Explain what the state of the world will be once the flow of events described in the use case occurs.

5) Business rules: These are the operating rules that govern or constrain the environment in which the process flow happens. For example, “placing an order can only happen between 9AM and 5PM” is a business rule. The use case must obey these rules.

6) Normal process flow: Define the “happy path” for the process flow, step by step and sequentially numbered. The “happy path” essentially means what the default flow is, without accounting for exceptions, conditions, or errors. It should lead to the successful conclusion stated in the post-conditions.

7) Alternate process flows: When there are major decision points or exceptions that create a different path to the conclusion of the use case, then each of those alternate process flows must be defined step by step just like you did with the normal process flow. If you numbered the normal process flow sequentially and the alternate flow begins in a certain step, you can just start the description of the alternate flow from there.

Use Case Wiki template:

Copy and paste into new Wiki page then Edit.

Use Case: Name <Enter Use Case name here>
The use case should be labeled so that it immediately describes the purpose of the use case. Usually, VERB/NOUN is sufficient.

Description<Enter description here>
Briefly describe this use case.

Level: Optional
High Level Summary
Low level Summary

Primary Actor<List the Primary actor here>
List the Actor who’s goal is being satisfied by this Use Case and has the primary interest in the outcome of this Use Case. Identify who the main individuals and systems involved in the use case are going to be. Any actor that is used in the use case’s flow of events must be named up front.

Supporting Actors<List supporting actors here>

<List the Actors who have a supporting role in helping the Primary Actor achieve his or her goal.

e.g. Customer, Store Manager>

Stakeholders and Interests

Pre-Conditions

< List the system state/conditions which must be true before this Use Case can be executed.

e.g. Store Clerk must be logged in to system.>

Post Conditions

Success end condition

<Enter the successful end condition of the Use Case where the Primary Actor’s goal is satisfied.

e.g. Video is rented to the customer and customer is charged for the rental. Rental store’s inventory is updated to reflect the rented video.>

Failure end condition:

< Enter the failure end condition of the Use Case if the Primary Actor’s goal has not been achieved.

e.g. Customer is unable to rent the video. Rental Store’s video inventory remains unchanged.>

Minimal Guarantee

< The guarantee or assurance that this Use Case provides to all Actors and Stakeholders to protect their interest regardless of whether the Use Case ends with success or failure.

e.g. For Withdraw Cash (ATM Use Case), minimal guarantee could be, Customer is logged out of the ATM system.
This minimum guarantee ensures that the system will ensure that no unauthorized withdrawals can be made from the ATM thus protecting the interest of the Bank Customer as well as the Bank’s stakeholders. >

Trigger

<The event that starts this Use Case.

Example

For Rent Video Use Case - Customer brings the Video to the sales counter.

For Withdraw Cash Use Case - Customer inserts the bank card into the ATM machine.>

Main Success Scenario

<Enter steps here>
<Enter steps here>
<Enter steps here>

Extensions

<Enter any extensions here. Extensions are branches from the main flow to handle special conditions. They also known as Alternate flows or Exception flows. For each extension reference the branching step number of the Main flow and the condition which must be true in order for this extension to be executed.

Example of an Extension in Rent Video Use Case:

4a. In step 4, if the customer has accumulated late returns fee greater than ten dollars

System will prompt for payment of the dues
Customer pays the dues
Store clerk adds the amount to the total
Use Case resumes on step 4.

Variations

<Enter any data entry or technology variations such as – different methods of data input, screen/module invocation, etc.

e.g.
3’. In step 3, instead of reading Video Id using a bar code scanner, the store clerk may enter it directly using the keyboard.>

Frequency: <Enter Frequency of execution here>

< How often will this Use Case be executed. This information is primarily useful for designers.

e.g. enter values such as 50 per hour, 200 per day, once a week, once a year, etc.>

Assumptions

<Enter any assumptions, if any, that have been made while writing this Use Case.

e.g. For Withdraw Cash Use Case(ATM system) an assumption could be:
The Bank Customer understands either English or Spanish language.>

Special Requirements

<Enter any special requirements such as Performance requirements, Security requirements, User interface requirements, etc. Examples:

Performance

The ATM shall dispense cash within 15 seconds of user request.

User Interface

The ATM shall display all options and messages in English and Spanish languages.
The height of letters displayed on the display console shall not be smaller than 0.5 inches. (Reference - Americans with Disabilities Act, Document xxx, para xxx).

Security

The system shall display the letters of PIN numbers in a masked format when they are entered by the customer.
i.e. Mask the PIN with characters such as ****. Rationale – This is to ensure that a bystander will not be able to read the PIN being entered by the customer.
The ATM system will allow user to Cancel the transaction at any point and eject the ATM card within 3 seconds. Rationale – In case the customer in duress/in fear of own security he/she needs to quickly get away.

The ATM system shall not print the customer’s account number on the receipt of the transaction.

Issues

<List any issues related to the definition of the use case.

Example

1.What is the maximum size of the PIN that a use can have? >

To do

<List any work or follow-ups that remain to be done on this use case.

Example

Obtain the sales tax table for computation of tax on video rentals from user.
Need to ensure that we have covered all parties under the ‘Stakeholders and Interests’ heading. >

Name :

Technology Used

Links

The Use Case Document is a business document which provides a story of how a system, and its actors, will be utilized to achieve a specific goa

Get Visual Use Case^TM with advanced flow editor

Automatically keeps Main Flow and Alternate Flows numbering in synch
Lets you write structured English and converts your Use Case Flows into an Activity diagram automatically!

…and you can always get a document output with a single click!

Download Visual Use Case now and watch your productivity soar VisualUseCase.com

Browser not supported