
This is the next post in the Use Case and User Story series. In this post, I'll introduce you to the components of a use case and provide a real-world example of how to write one.
As mentioned in the previous post, a use case is a detailed description of how a user interacts with a system to achieve a specific goal. It lists the steps, actions, and expected outcomes of the user's interaction with the system
1. Components of a Use Case
Use Case name: The name of the use case.
Objective: The purpose of the use case; what it is used for.
Actors: The participating entities, which can be users, groups of business users, or systems.
Pre-condition: A specific constraint or condition that must be met for the use case to be executed.
Trigger: An event or action that initiates the use case.
Basic flow: The main flow or 'Happy Case' – the steps the actor needs to take to complete the use case.
Alternative flows: Alternative processing flows or different conditions that may occur during the execution of the main use case.
Exceptional flows: Exceptional situations, errors, or incidents that occur during the execution of the use case.
Post condition: The condition the system needs to achieve after completing the use case.
2. Example of Writing a Use Case - According to IIBA
Use case | Create a Spotify Account. |
Objective | Allow users to create a new Spotify account to access and use the online music service. |
Actor | User. |
Pre-Condition | User does not have an existing Spotify account. |
Trigger | User clicks the "Sign Up" button on the Spotify website. |
Basic Flow |
|
Alternative Flows | Sign up using a Google or Facebook account.
|
Exceptional Flow |
|
Post condition |
|
3. Example of Writing a Use Case - My Way
In reality, there isn't a single standard for describing use cases. When you join a project, you need to understand how the company documents are written and follow their format. If you think the company's document format can be improved, you should suggest your ideas and discuss them with the team or lead, rather than arbitrarily changing the structure or writing style.
Next, I'll show you how I currently describe use cases in my documentation. This approach doesn't separate the three flows: main flow, exceptional flow, and alternative flow. Instead, the alternative flow is separated into a different use case. The main flow and exceptional flow are represented through an activity diagram, and the system's business logic is described through business rules.
Use case | Create a Spotify Account Using Email. |
Objective | Allow users to create a new Spotify account to access and use the online music service. |
Actor | User |
Pre-Condition | User does not have an existing Spotify account. |
Trigger | User clicks the "Sign Up" button on the Spotify website. |
Activity Diagram:

Business Rules:
Step 2 – Screen Displaying Rules | The system displays the email account registration screen. (In the document, I would use a reference to link the screen design with this rule). |
Step 4 – Validation Rules | The system will validate the following information:
|
Step 5 – Creation Rules |
|
I hope this explanation is helpful for you in documenting your projects. See you in the next post about User Stories!
Comentários