For requirements collection and high-level stakeholder communication, product managers need to be able to describe how a consumer will interact with a system or product. This can include a description of the product’s users, how they interact with the product, and what it does.
A great way to visually represent this information is by creating a use case.
In this guide, we’ll define what a use case is, describe the elements therein and what they are designed to do, and walk through how to build a use case step by step.
We’ll also look at some use case examples to show what they look like in practice.
If you’d like to write your own use case while following along with this article, here is a free use case template. To use the template, select File > Make a copy from the top menu bar.
Table of a contents
- What is a use case?
- Who creates use cases?
- What is a use case designed to do?
- Elements of a use case
- What does a use case diagram look like?
- How to write a use case
- Use case template
- Use case example
What is a use case?
A use case is a description of how a user interacts with a system or product. Companies build use cases to establish success scenarios, failure scenarios, and any important variants or exceptions.
Many organizations use a use case modeling tools — such as Miro, LucidChart, and SmartDraw, for some examples — to write or visually represent a use case.
Use cases are frequently employed in software development environments to simplify complicated concepts, but they can be just as important in project management for gathering requirements and defining a project’s scope.
Who creates use cases?
Product management, product development, and product testing domains all use the use case methodology. Product managers and developers employ use cases in a similar manner: as a design tool to specify how the system will react to user activities. However, there are some key differences.
Product managers typically document user-focused use cases whereas developers document product-focused use cases. The user-focused use cases are primarily concerned with the user and their objectives. These are then passed to developers to guide decision-making during the product development process.
Product developers frequently add technical and design elements to provide crucial context. This set of improved use cases gives the development team the insight it needs to start designing, creating, and testing the product and its features.
What is a use case designed to do?
A use case is designed to reveal system demands early on in the process.
Use cases concentrate on the system’s users rather than the system itself. A user case should be understandable to all stakeholders, not only developers and testers, because they are mostly narrative prose. This includes customers, users, and executives.
During the early planning stages, you should involve whichever roles are best suited to solve the problem at hand. This encourages end users to buy into the solution and reduces surprises once the system is put into place.
Each use case is designed specifically to cover only one application of the system. That said, a key advantage of use case modeling is that it also covers all potential problems. Finding minor requirements early on in the project saves a ton of time by identifying exceptions to a successful scenario.
Finally, after you create a use case, you can use it to guide the creation of many other software development components, such as object models, test case definitions, user documentation, and project planning (cost, complexity, and scheduling estimations).
As a product manager, one of the best justifications for creating use cases is that they serve as genuine connecting points. They should be truly understandable to both business and technical users so that everybody can comment on them.
Business analysts leverage use cases as a communication tool to align people to take a common approach and share a common understanding of what the software aims to accomplish.
A technical product manager, on the other hand, might employ use cases to reach business stakeholders without using tech jargon — talking more about what the system does than how it does it. When you get down to the dirty work of coding, this will really help you accelerate and clarify communication to ensure that you’re building what the business genuinely needs and desires.
Elements of a use case
Let’s break down the components of a typical use case and explain the purpose and objective of each:
Actors
Actors are the people or things that interact with your system. An actor could be an individual, a company, a team, or something else entirely. Anything that exists outside of a system and engages in some sort of interaction with it qualifies as an actor.
The stakeholder who gets the ball rolling with an interaction to achieve a goal using your system is known as the primary actor.
Systems
Your system, which some people refer to as a scene, is composed of a number of decisions and interactions made by your actors.
Goals
The results of an actor’s interactions with the system are your goals.
Your system may produce several outputs in some circumstances while only producing one in others. Before continuing, consider modifying your method if you encounter any barriers to achieving your goal.
Preconditions
Preconditions are assertions or realities regarding what must occur prior to and following the use case.
Often, software developers are aware of the actions that must come before the next one.
For example, let’s say an online shopper clicks on a product to get a detailed description and customer feedback. The Add to cart button won’t show up until the item is in stock and accessible at the warehouse.
Basic flow
A use case that operates flawlessly and exactly as intended with no exceptions or mistakes in the run is known as the fundamental flow or main success scenario. This frequently serves as a starting point when developing various features.
Knowing how a typical scenario operates can help you write accurate code and come up with alternative flows.
Alternative flows
A deviation from the primary success scenario is known as an alternative path or alternative flow. This typically manifests when a system-level error occurs.
In this section of the use case, you frequently list the most probable or noteworthy exceptions an actor might make. Alternative flows in the e-commerce example might include:
- Adding items to favorites instead of a shopping cart
- Sharing items with friends or family members
- Looking at reviews and comments about a product or service
What does a use case diagram look like?
In a use case diagram, stick figures are the most typical way to depict actors.
The use cases/ goals you create will be horizontal ovals with a few words of text inside detailing each activity; you can use various colors to indicate different goals.
Associations that depict the connections between components use solid and dotted lines.
Each set of use cases within a system are grouped together by system boundary boxes, which are rectangles.
An example of a use case diagram for a medical clinic application might look something like this:
How to write a use case
To write a use case, complete the following steps:
- Determine the target audience for the product
- Select a user from that list
- Determine what, exactly, the user wants to do with the product and create a separate use case for each action
- Determine the typical flow of events for each use case when the user uses the product
- In the use case description, describe the fundamental course. Give examples of what the user performs and what the system responds with so that the user is aware of both
- Consider alternative courses of action and include them to “expand” the use case once the fundamental process has been presented
- Search for connections between the use cases. Extract these and mark them as typical use cases for courses
- Repeat steps 2–7 for all other users
Use case template
You can use the template below to assist you in writing your own use case:
To use this use case template, click here and make a copy by selecting File > Make a copy from the top menu bar.
Use case example
To show how the steps outlined above work in practice, let’s look at an example use case of a housekeeper doing laundry:
- Actors — Residents, housekeeper, etc.
- Primary actor — Housekeeper
- Goals — To do laundry, fold all items, iron clothes if necessary
- Preconditions — It is a Friday and there is laundry in the laundry room
The basic flow for this use case example is as follows:
The housekeeper comes to the laundry room on Friday. They organize the available laundry. After that, they clean and then dry each load. They folds the articles that need folding, then iron and hang the wrinkled items
Alternative flows:
- The housekeeper irons any wrinkled items before putting them on a hanger
- The housekeeper rewashes anything she finds to be still dirty
Summary
Use cases help product teams understand a system’s functions from the viewpoint of distinct users. They help stakeholders across the organization visually understand the various flows and how user groups interact with the system.
Use cases also support the development team when generating concepts and assessing the viability of the use cases. Use case definition is a crucial phase in the software development process and is a critical skill for any product manager.
The post What is a use case? Definition, template, and how to write one appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/lESrb8U
Gain $200 in a week
via Read more
