Use Case
A use case is a tool for identifying the business goals of a system. The identification of use cases helps define system scope, ensuring that the requirements to be found will all be aligned with the business values, needs and strategy.
What is a Use Case?
A use case represents a high level business goal to be achieved by someone, some parties, or some sub-systems through interacting with a system, which can be the system under developed, or the system to maintain, depends on the nature of your software project.
Use cases are neither system requirements nor the functions to be implemented. In fact, it is important to stay use cases away from requirements because you need a clear set of use cases that helps you define business goals and system scope. In fact, capturing of requirements would be done after the identification use cases (epics) and subsequently spitting into a set of corresponding user stories (business goals).
Graphical form of use case
Use Cases can be visualized in a UML Use Case Diagram. A use case is shown as an ellipse in diagram, with its name appear in the middle of the shape. Besides use case, a typical use case diagram contains two more elements - actor and link.
An actor is a role that interacts with the system to achieve one or more business goals as represented by the use cases. The occurrence of interaction between an actor and a use case is represented by an association (link). Note that an actor does not necessarily represent a specific physical entity (e.g. John), but just a role (e.g. Customer). In reality, a role can be played by different person and, conversely, a person can play multiple roles.
How to Identify Use Case?
Use cases are found by communicating with business owners or the senior executives of the company. We use to call them the business stakeholders. It is important to identify use cases with business stakeholders but not someone else, as they are clear about the directions and actual operations of the company. They also have the authority and information required for making business decisions. Thus, the use cases identified are all aligned with the business values, needs and strategy of the company.
Why Use Case?
Many people see the identification of use cases a redundant step. They would rather go straight into identifying system requirements. So, is use cases approach useless?
When you are going to develop a large scale system which typically involve a lot of stakeholders who have different expectations on the final system, ending up a large collection of requirements in an unmanageable manner. A use case could be served as a placeholder for accommodating a group of related user stories which share a larger and shared business goal and scope among them.
Keep in mind that use cases are found by communicating with business owners and senior executives who oversee the growth of their companies and have the ability to make strategic business decisions. Due to this reason, use cases directly reflect what the business goals the target system has to achieve. By finding requirements based on use cases, the requirements are highly likely to be within system scope and thus achieving the business values expected by the owners. Besides, use cases also facilitate meaningful categorizing of requirements. Proposed software features can be planned based on the importance of the use cases, instead of solely depending on the opinions of the front-line stakeholders, which may not be fully aligned with business owner's expectation.
Use Case Examples
Here are some examples to illustrate the usage of use cases. The example given here is just for illustration purposes, there is no definite way as to what use cases should be identified for a particular target system. The rule of thumb for the use case identification process is always be the result of active participations and involvements with the business stakeholders.
| System | Use Cases |
| ATM | Withdraw cash, transfer money, donation, settle bills, change PIN |
| Online photo album | Upload photo, share photo, delete photo |
| Health tracking app | Record workout, produce workout statistic, challenge a goal |
Based on the examples above, we might then have the following discussions:
Use Case Yields Observable Goal
ATM
ATM is a classic example when explaining the concept of use case or use case analysis. You may wonder why there isn't a use case for 'Login', which is an inevitable step of all ATM operations. As said, use cases are business goals to be achieved. They yield an observable result to the actor who interact with the system to achieve the use case. Here, 'login' is only a part of the other operations. 'Login' itself does not yield any observable result - no one would just login an ATM and go away, right? So, we do not consider 'login' as a use case.
Wouldn't 'change pin' be too small to be a use case? The answer is: the identification of use cases is neither based on the amount of work the user need to do, nor based on the number of system functions to develop. As long as it is a business goal that the business stakeholder want the target system to achieve, it is a use case. In this case, we consider the customers to change their PIN through ATM as a use case.
Online photo album
Typical online photo album allows users to tag their uploaded photos. Is 'tag photo' a use case then? The answer is: It depends. If the business stakeholders want to let users access the system to tag their photos, even without doing anything else within the session, then 'tag photo' should be a use case. However, if they think that tag photo is only a part of the photo upload process, and there is no other way to tag photo afterwards, then 'tag photo' would not be a use case. Another case would be that the stakeholders just want to let users edit the photos they uploaded for any properties like, title, description, tags, etc. Then, it's likely that a use case 'edit photo' will be created. So you can see the identification of use case is not a casual step. You can imagine the capability to tag photos will be supported quite differently under use cases 'tag photo' and 'edit photo'.
Health tracking app
Although use cases are not requirements, this doesn't mean that use cases are abstract and lack of focuses. Take health tracking app as example. Record workout, produce workout statistic and challenge a goals are all clear enough in defining the scope of the features. Can "maintain good health" be a use case? Well, it is a bad choice because its scope is too wide - Every health tracking app is trying to help the user to achieve this goal, however, with this 'big goal' we are not sure what functionality the apps could actually be able to fulfilling it!
How to Write Use Case?
The simplest form of a use case consist of a <verb> + <noun> or <noun phrase> that describe a business goal. Here are some examples:
- Register Account
- Place Order
- Withdraw Cash
- Post a Vacancy
- Investigate Failure of Cases
As said, use cases are designed to identify business goals. Do not use it for writing requirements, nor to describe the interactions between user and system. All these steps will be detailed in the subsequent development activities but not now.
Using Use Case with User Story
User stories is also an important tool in agile development. Each user story consists of a short description written from user's point of view. Here are some examples of a user story:
- User want to settle a payment by credit card.
- User want to settle a payment by PayPal.
- User want to optionally include shipping insurance during checkout.
- User want to choose a different delivery address during checkout.
- User want to receive an SMS upon the successful creation of order.
A use case is a tool for defining the scope of a feature, while a user story captures what a user does or needs to do as part of her work, ultimately lead to the creation of some requirements. We can utilize this two requirements capturing skills for identifying the right requirements. Here is the steps for performing it: First of all, communicate with business stakeholders to identify business goals as the use cases. Then, focus on a particular use case, communicate with the front-line users for identifying the user stories under that use case. Because the identification of user stories is driven by a use case, the requirements found in the end will align with the business goals.
Visual Paradigm provides all the tools you need in agile software development, which includes UML Use Case Diagram tool, (agile) user story, sprint, storyboard and wireframes for UX design, task management tool, etc.
