A use case describes the possible outcomes of a specific goal that the solution will support. It features different paths that can be followed such as the main and alternative flows.
The main flow depicts the most direct way to fulfill the use case goal. Exceptions that lead in a failure to complete the goal of the use case are documented in alternative flows.
Benefits of Use Cases
- Use case diagrams can simplify scope and provide a high-level understanding of requirements.
- Use case descriptions are easily understood by stakeholders due to their narrative flow.
Use Cases have the following information:
- Who is using the system.
- What the user want to do.
- The steps the user would take to accomplish a particular task.
- How the system should respond to an action.
A Use Case include the following elements :
- Actor : this is someone or something that connects with the solution.
- Stakeholder :this is someone who has a vested interest in the solution.
- Main Actor : this is the stakeholder who triggers an action to achieve a goal.
- Preconditions : these are the conditions which must be fulfilled before the use case runs.
- Postconditions : these are the conditions which must happen after the use case runs.
- Triggers : this is the event that causes the use case to be started.
- Main Flow : this is the use case in which the process goes as expected. It is also known as the “Happy Path”.
- Alternative Flow : these are the paths that are taken when something goes wrong and alternative path is taken.
How To Write a Use Case:
Take these steps when creating a use case:
- Identify who is going to be using the system.
- Pick one of those users.
- Define what that user wants to do on the system. Each thing the user does on the system becomes a use case.
- For each use case, decide on the normal path when that user is using the system.
- Describe the description for the use case. Describe it in terms of what the user does and what the system does in response that the user should be aware of.
- When the normal path is described, consider alternate paths and add those to expand the use case.
- Look for similarities between the use cases. These similarities should be noted down as common line use cases.
- Repeat the steps 2 through 7 for all other users.
Example of a Use Case:
- A User creates a new time-off request.
- They send the request to their supervisor for approval.
- Their supervisor receives the time-off request.
- The supervisor makes a decision on the time-off request.
Time-off request creation Use Case:
- Use Case 1: Create a new time-off request.
- Description: This scenario describes the situation where the end user creates a time-off request.
- Actor : End User
- Main Flow :
- 1. The End User logs into the system.
- 2. They open the time-off tab.
- 3. They select the date, number of hours and type of time-off request.
- 4. They submit the time-Off request.
- Alternative Flow 1: If they change their mind, they cancel the request.
- Alternative Flow 2: If they want to make some changes, they can amend the request. .
Time-off approval request Use Case:
- Use Case 2: Make a decision on the time-off approval.
- Description: This scenario describes the situation where the supervisor has to make a decision on the time-off request.
- Actor: Supervisor
- Main Flow:
- 1. The supervisor receives the time-off request.
- 2.The supervisor reviews the request.
- 3. The supervisor and approves the request.
- Alternative Flow 1: The supervisor notices an error in the request and sends it back to the end user for amendment.
- Alternative Flow 2: The Supervisor rejects the request and states the reason why.
- Alternative Flow 3A: Time-off request needs amendment Use Case
- Description: This scenario describes the situation where the time-off request needs to be amended.
- 3A1: The End User receives the amend time-off request notification.
- 3A2: The End user makes the necessary changes.
- 3A3: The End User submits the request.
- Termination outcome: The time-off request is sent for approval.
- Alternative flow 4B: Time-off request is rejected Use Case
- Description: This scenario describes the situation where the time-off request is rejected.
- 3B1: The End User receives the rejected time-off request notification.
- 3B2: The End User reads the reason why the request was rejected.
- Termination outcome: The time-off request was rejected.
Post conditions: The time-off request decision is made.
The Use Case should be created based on the business rules.
The business rules that are applicable to this Use case are:
- The End User or their supervisor can create the time-off request.
- The time-off request decision has to be made by the supervisor.
- The End User or their supervisor can amend the time-off request.
- The Supervisor must input a reason if they reject the request.
- The time-off request date must be the same day or a future date but not a past date.