Introduction
Use case analysis is a technique used in software engineering to help determine what the stakeholders of the system want it to do and how they want it to behave. When planning a new application or making changes to an existing application, user stories are often used to help capture these requirements, but use case analysis should be done first. The difference between these two methods is that user stories are typically written from the perspective of one person (or group) who has a stake in the project (i.e., a business owner or customer), whereas use cases are written from the perspective of all stakeholders involved with the project (i.e., developers, testers, managers).
A use case identifies, clarifies, and organizes system requirements. Each use case is a set of interactions between an actor and a system, to achieve a specific goal.
In the early phase of a project, use case analysis is a requirements gathering method. Later it can be used to analyze and model the code. A use case is made up of a set of possible sequences of interactions between systems and users in a particular environment that leads to an outcome, the goal. In this article, we will explore what use cases are and how to create them.
Getting started with use cases
Use case analysis starts with the creation of general use cases, they can be written in plain English. They are not a detailed design, test plan, or technical design but an outline of how the system should work from the user's perspective. Use cases capture an actor's behavior and their interactions with the system or other actors. The use case method has been widely recommended by many agile methodologies such as Scrum, XP, FDD, and others.
Creating the use cases diagram
A use cases diagram provides a visual representation of various use cases which depict the possible interaction of the user with the system and also includes the different types of users that might interact with the system and what they will be able to do. Each individual use case is represented by either circles or ellipses. The actors are often shown as stick figures.
We will create a use case diagram for an ATM. Imagine we collect the following use cases for an ATM that we wanted to visualize (not comprehensive, for the sake of example):
- Deposit cash and checks
- Withdraw cash
- Check balances
- Employees should be able to refill cash
- Technicians should have access to fix the ATM
We can visualize these use cases with the following diagram.
The diagram lets us clearly visualize the actors, and different use cases (see how to withdraw cash use case is dependent on getting the balance from the bank). We can see the bank supporting the transactions as well. By visualizing, you may come to a question how will the bank know to send an employee to refill cash? This requires an additional use case of reporting!
The diagram can be edited to support additional use cases:
The use cases for the bank to trigger technician calls etc can also be incorporated in the same or different diagrams. When starting out projects, by having a use case diagram, we can make sure we have a good understanding of the project, and we can make sure that our assumptions are correct. The use case diagram is also useful for new developers joining the project, as it gives them an overview of what each actor does, and how they interact with others.
A lot of details can be added in the diagram to use of generalization, and how some use cases depend on others (see deposit cash and checks depend on accepting "credit").
Creating use case description
After we have identified the use cases and created a diagram to visualize them, we can get into writing use case descriptions. Each use case description has the following main elements:
- Name (can be a number or unique human readable name)
- Description (what is the use case)
- Actors (the user interacting with the system)
- Pre-conditions (assumptions or states that are true before the use case starts)
- Triggers (how the use case starts, usually optional)
- Basic flow (the main sequence of events as a story)
- Alternative flows (possible sequences that can occur depending on the context)
- Exception flows (what happens when an exception occurs, e.g., when the user does not want to proceed with the normal flow or has forgotten his or her password)
- Post-conditions (the outcome after the interaction between the actor and system is complete)
If you're a programmer, perhaps this template is already part of the mental process by which you break down your algorithms.
The use case analysis will identify business rules that the system must abide by. This will be apparent when you are writing use cases. For example, if there is a requirement that the user must enter his or her password before accessing any system function, then this will be captured in the use case analysis. The use case analysis will also identify business rules that affect how the system behaves but are not directly related to interacting with actors. These rules may also be captured in the basic flow, exception flow, or alternative flows (you may also include pseudocode in the form of algorithms or flowcharts)
Why include business rules?
Business rules are used to ensure that the system operates as expected, and is reliable and secure. They are a set of conditions that must be satisfied before an action can take place. They describe how we want something to behave or what should happen during a given situation. They can be perceived as laws for your computer software application. If you break one of these laws, it could have serious consequences for your business! They are the ones that create conditional logic. That’s why it’s so important to include them in your use case analysis from the very beginning of an application’s creation process.
Use case description example
From the above use cases, let's pick the withdraw cash use case.
Name: "Use case 1" or "Withdraw cash"
Description: A customer should be able use the ATM to withdraw cash from their accounts, given they have the balance and don't exceed withdrawal limits.
Actor: Bank customer
Pre-Conditions: The customer is logged into the ATM
Trigger: Customer presses withdraw cash option from ATM
Flow:
Happy path (customer has enough amount):
- The customer enters an amount
- Validate customer balance and limits
- ATM outputs cash
- ATM display print receipt option
- (Optional) Print receipt based on user request
- ATM returns to home page
Not enough balance (alternate flow):
- The customer enters an amount
- Validate customer balance and limits (fails)
- ATM displays error for insufficient balance
- ATM returns to home page
Post-condition: The customer has the money (if they met limits and balance restrictions)
In the above example, we described the withdrawal use case. I presented different flows (there could be more), within a single use case. These can also be split into two separate use cases "Withdraw cash - customer has enough balance" and "Withdraw cash - customer has insufficient balance" if we want to simplify the conditional logic inside a single use case.
After you are done doing this, verify your use cases with your stakeholders to make sure the right product is being made without expensive iterations. The cost of getting feedback on a UI design or code post-development can be extremely high.
I will describe later on in this article how we can create test plans using the use cases.
Iterative development
Use case descriptions may be refined throughout the project to capture more detail and make it clear what needs to be built and tested. The scope of a use case may be expanded or narrowed. Requirements that were previously considered out of scope might be added to the use case description. A requirement that was not previously described can be added. Existing requirements might need to be modified to reflect changes in the business process being modeled or other factors such as an increase in system complexity.
Why can't we capture everything thing the first time? It's because use cases may also change over time because they must adapt to changing user needs, priorities, and technologies used by developers and testers on the project team.
In the software world, teams grow really fast, there are always new faces around. Middle of the project someone leaves, and someone shows up. How can they understand the product being built really fast? Use cases. Someone missed a requirement and they need to understand other edge cases -> use cases.
Maintenance of use cases can help keep the team focused on what needs to be built, reduce churn and increase overall project efficiency.
Creating test plans
If you are creating your end-to-end test plans based on your software design, you are testing what you built. Your test cases can be biased toward your solution and not the real-world expectations.
Create your test plan before development preferably. This is test-driven development. It has personally helped me (at Amazon) to identify flaws in my understanding of the use cases. Sometimes, I have also discovered new use cases. For project managers, this will help you estimate the effort required across teams, allowing you to plan ahead and not cut corners for testing.
Use cases should be used to test software designs. If you have use cases, perform the exercises for your software designs to see if all use cases will be covered, otherwise, you will end up with last-minute delays. One of my project releases got delayed 2 months due to skipping this process. I wrote this article so yours doesn't.
Conclusion
Use cases are an important part of software development. They can be used at all phases of the project lifecycle, but they're most useful during requirements gathering and analysis. Use them to communicate with all stakeholders without getting lost in tech designs and reduce the overall cost of any project.
If you enjoyed this article, follow me on Twitter to learn more about the software world, drop a 👋 in DM's!
