What is a Business Use Case?

Systems and software engineering

Use cases are primarily created in software and systems engineering environments. They help developers and engineers understand how a user interacts with a system from a user interface (UI) perspective.

For example, if you have an online store, you’ll have to think about how your customers would interact with your website. If a customer visits your site and wants to purchase an item, how might they do that? Most online customers may be familiar with a website’s UI, but that still means your “customer makes a purchase” use case should specify the following:

• Are they a registered user or new customer?
• How can a user add something to their cart?
• How can a user delete an item from their cart?
• What information does the user need to provide before checkout?

Product development

Use cases are also created during the product development process. In this instance, use cases help project managers and developers understand from a business analysis and management perspective how a user interacts with a product.

For example, think of a glass jar with a tin lid. There are many uses for it: You can use it to store food, drink from it, or place household items in it.

Now imagine, instead of a glass jar, your company sells technology devices or software—something that’s complicated and requires a lot of thought on how users can interact with it. Here, your Product Development team will need to work with your engineers to identify each way a user would interact with that product.

Use case vs. user story vs. process flow

Use cases are similar to both user stories and process flows, but they serve different purposes.

A user story is more general to your audience. Unlike a use case that lists specific steps on how a user can complete a goal, a user story describes the user’s needs and desires for that goal.

User stories typically have the “As a / I can / so that” template and may look like this: “As a customer, I can shop for my favorite brand online so that I don’t have to spend hours looking around a department store.” Here, the user story emphasizes the customer’s desire, which is to find an item online without having to go to a physical store.

Alternatively, process flows, process documents, or step-by-step guides are general formats that outline necessary steps for anyone looking to accomplish a goal. A new employee onboarding guide or sales checklist are good examples of process flows.

What makes these different from a use case is that process flows broadly cover each step and focus on different interactions between people, objects, and other processes—whereas a use case focuses only on the user’s interaction with a system or product.

Why you need a use case model for business processes

Writing out a detailed use case description may take time at first. But once you have the process down, you can start reaping the benefits.

Breaks down large projects

Writing descriptive use cases is a part of Scrum and Agile marketing because they help streamline production and break down complex tasks. Of course, the idea of making an innovative and unique product may be easy to grasp conceptually. However, you need a use case model to help you break down each task so your users can accomplish their goal of actually using your unique product. This will also help guide your Product Development and Software Engineering teams as they navigate each use case.

Takes on customers' perspective

Use cases are ultimately about aligning with your customers’ needs and mapping out each task so your customers get the most value. By breaking down your customers’ main goals into smaller system use cases, you can give your team the necessary information they need to understand your customers’ holistic perspective through every task.

Prepares you for alternative outcomes and obstacles

Not every project goes 100% as planned. Use cases can help you prepare for alternative outcomes when tasks get blocked by new obstacles or even other tasks. By planning ahead and designing alternative routes, you and your team can bounce right back. Even the act of writing a use case can help you identify tasks that your customer base may not find valuable anymore, thus helping you align with your target audience.

Anatomy of a use case

Let’s break down the main elements found in writing business use cases.

Actors

The actors are who or what interacts with your product or system. In product development, these business actors are usually your customers, either individually or as a group. In software engineering, it can also be an external computer system that engages with your process, such as two-factor authentication or an inventory tracker.

A primary actor is the main actor that initiates interaction with your product or system. Some use cases may have secondary actors that also make interactions, but the primary actor is the star of the show—the one who usually triggers the use case.

Goals

The goal is the result of your actor’s interactions with your product or system. It’s what your actor is hoping to achieve at the end of the use case scenario.

Systems

The system in a use case is the process that enables your actors to achieve their goal. When writing a use case, this is the space where you’ll write out each step.

Normal and alternative courses

Within your system, you’ll write out a normal course of events. This is the detailed, step-by-step description that outlines how the actors will reach the goal. There are also alternative courses that cover different pathways for your actors.

Success scenarios and failure scenarios

A success scenario is when your actor is able to complete each step in your system successfully. For every use case, you should always outline the main success scenario where your actor achieves a goal. However, you also need to include a failure scenario, which is the outcome if your actor isn’t able to reach their goal.

How to write a business use case

Writing a use case for new systems can be easy when you’re starting fresh, and in most instances, you can follow a similar use case template each time you create a new one. But if you’re writing use cases for existing processes, be aware that you’ll likely need to keep breaking down systems into smaller goals.

Define your customer

First, you’ll have to define your primary actor. This will usually be your customers, but, as mentioned before, it can also be an external system. If you’re not sure who your customer base is, start segmenting your audience. This will help you identify your audience’s personality types, values, and behaviors.

Determine your customers’ goals

Next, you’ll need to think about what specific goals your customers will need to accomplish in order to interact with your product or system. For example, if you’re a blogger who sells merchandise, you’ll need to write out all the different use cases that describe how your customers can read your blog, buy a product, or contact you.

Map out your business use case model

Now, you’ll have to lay out your use case model. A great way to do this is through a visual representation, like a use case diagram. This is a simple sketch that identifies the primary actor, their goal, and the system they interact with. However, you can also simply write them out in a standardized template.

Your use case diagram should describe the normal and alternative course of events. For example, let’s say your use case model describes how a customer would purchase an item at your online store.

A normal flow would describe each of those steps, such as adding the desired item to a cart, going to the checkout, and filling in the shipping information. An alternative flow would include what might happen if a customer enters an incomplete address or incorrect credit card number. It’s important to note that even if a customer encounters an alternative flow of events, they should still reach their desired goal.

However, this use case system could turn into a failure scenario. If the customer finds that their desired item is not available in their size or is out of stock, this would lead to the customer not achieving their goal of making a purchase.

Identify relationships between use cases

Some use cases can be fairly easy to write down, but others can certainly be more complicated. When different actors get involved and you have multiple use cases with various flows, it’s important to make sense of how they may connect.

Say, for example, you run an online travel booking company. If you have a use case for a customer who needs help scheduling their trip and a use case for a customer who needs help rescheduling their trip, it may be a smart idea to combine the two. Besides, both types of customers have the same goal: They want to contact your customer support.

Write out user requirements specification

Once you have your use case written down, it’s time to create the user requirements specification. This is a list of fundamental requirements that a user must do in order to achieve their goal.

While use cases are mostly internally facing, user requirements are externally facing. They’re given to users who test out your product or system to see if it works properly, also known as user acceptance testing. If your user reaches their goal, then your system is successful. But if they encounter too many obstacles, it could mean going back to the drawing board.

Improve business operations with efficient use cases

Use cases are like the fabric that brings business concepts and scenarios into reality. They help give teams direction and identify roadblocks so your customers can ultimately have a seamless experience. Once you get more and more comfortable writing out use cases, you’ll be able to lead your business toward success.