Use case writing guidelines

Use Case is a way to summarize the functionality of the system. Thus, Use Cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system. Example

1  Guidelines

1.1  EVERY USE CASE MUST HAVE A UNIQUE NAME

A Use Case must have a unique name assosiated with it, which identifies that particular Use Case. The name also includes the Use Case ID, which is a sequence number for that Use Case.

For example: UC396 -Withdraw Funds

1.2  USE CASE TITLES BEGIN WITH A STRONG VERB

A Use Case describes a sequence of actions so it should have a title that reflects this fact, a name that begins with a strong verb.

Use Case titles beginning with weak verbs include words such as “process”, “perform”, and “do” are often problematic. Such names often result in communication difficulties with your project stakeholders, people who are far more likely so say that they withdraw funds from accounts instead of process withdrawal transactions, and hence decreases your ability to understand their requirements. Furthermore, a name such as Process Withdrawal Transaction Request may be an indication that the use case was written with a systems-oriented view, as opposed to a user-oriented view, and therefore may be at risk of not reflecting the actual needs of your project stakeholders.

Examples:  Good Use Case titles:

Withdraw Funds

Register Student in Seminar

Deliver Shipment

Wrong Use Case titles:

Process Withdrawal Transaction

Perform Student Enrollment Request

1.3 NAME USE CASES USING DOMAIN TERMINOLOGY

The name of a Use Case should immediately convey meaning to your project stakeholders. Remember Use Cases provide an overview of your system’s usage requirements and therefore should reflect terminology that is common to your domain.

For example, if people cannot readily identify what the Convey Package Via Vehicular Transportation Use Case does, you might want to change it to Deliver Shipment.

1.4  NAME ACTORS WITH SINGULAR, BUSINESS-RELEVANT NOUNS

An actor is a person, organization, or external system that plays a role in one or more interactions with your system. An actor should have a name that accurately reflects its role within your model. Actor names are usually singular nouns.

Examples: Bank User, Corporate User, Grade Administrator, Customer, and Payment Processor.

1.5  ACTORS MODEL ROLES, NOT POSITIONS

A common mistake is to use the names of positions that people hold instead of the roles that the people fulfill while naming actors. This results in actors with names such as Junior CSR, Lead CSR, and CSR Manager instead of Customer Support.

1.6  DESCRIBE THE GOAL THAT USE CASE IS INTENDED TO ACCOMPLISH

General Description describes the goal that is to be achieved by the Use Case. It should be described briefly and precisely.

Example: For Withdraw Funds, the general description is as following:

This use case allows the actor to withdraw money from the account.

1.7  SPECIFY REVERSIBLE

If you have commited some Use Case and it is not possible to revert back the action performed by it, then specify “Reversible” as No otherwise Yes.

Example: For WithdrawFunds,

Reversible: No.

1.8   STATE ASSUMPTIONS

All the assumptions or pre-conditions must be specified briefly. These needs to be completed before the actor initiates the action specified in the Use Case.

Example: For Withdraw Funds, the pre-condition is as follows:

The Actor has the privilege to perform this operation.

1.9  STATE POST-CONDITIONS EXACTLY

Post-conditions are the actions after exceution of the Use case. Either the Use Case is successfully executed or is failed. So there are two possible post-conditions: Action on Success and Action on Failure. “Action on Success” specifies the system response after the successful execution of the Use Case. “Action on Failure” specifies the system response after the failure of the Use Case. These actions should be described exactly.

Example: For Withdraw Funds, the post-conditions are as follows:

Action on Success: Fund is withdrawn and the account status is updated.

Action on Failure: Fund is not withdrawn and the error is reported to the Actor.

1.10  LIST EACH STEP IN USE CASE

List all the steps under “Sequence of events”, which will be followed to complete the Use Case. A step completes when all its component interactions have completed. Each step has an Actor Input and corresponding System Response. If there are multiple steps then give sequence numbers to them.

1.11  LIST ANY ALTERNATIVE FLOW IN SEQUENCE

List any possible alternative flow for any step in “Sequence of events”. It should be listed under “AlternateFlow” section in the Use Case. It should have a Cause and corresponding System Response.

It must have a proper title, which describes the alternative behaviour. And it should have the same sequence number as that step has for which it is an alternate flow.

1.12  SPECIFY VERSION NUMBER, AUTHOR NAME, MODIFIED DATE, AND COMMENT FOR THE USE CASE

Above mentioned items must be specified in the Use Case. These are useful for keeping track.

1.13  LIST ALL IDENTIFIED ISSUES

Identify all issues or confusions that you have regarding the Use Case and note them in a separate section clearly.

1.14  USE PRESENT TENSE FOR WRITING USE CASES.

Don’t use Future tense in Use Case writing.