Use Cases Design

Use cases as a description of the sequence of interactions

Use cases describe the sequence of interactions between a system and an actor where the actor needs to reach a defined goal, e.g., change profile data in an online store.

Let's consider a simple example.

Picture this: you enter an online bookstore website and find out that your profile data are no longer up-to-date because you changed your residence address. So, the change of profile data will be a use case here.

Use case: Example

A use case can look like this:

"Bookstore: Update your customer profile."

For example:

"I want to update my customer profile so that my future purchases can be delivered to my new address."

Use case vs. User Story

When dealing with use cases, a business analyst teams up with users.

Then, the business analyst can find out how users imagine a dialog with a system designed for a specific purpose. The collected data enables you to structure it according to a template.

However, remember that a use case shouldn't specify the details of a project, as it aims to focus on user ideas. Use cases will allow you to show the project participants the structure and context.

For acceptance tests, agile teams focus on the development of user stories. Such tests allow you to learn to what extent the user requirements have been met.

A major advantage of these tests is that they're conducted at an early stage of work.

But when we're talking about common features of use cases and user stories, it's worth noting that these focus on what the users want to achieve, not on their ideas of what a system should do.

With these two methods, you can describe the tasks users will need to perform in a system (or to identify user-system interactions).

How can use cases help you?

Developers don't implement business or user requirements. They code a program's functional and extra-functional requirements. Creating functional requirements without knowing the users' needs and business requirements is equally impossible.

Correctly formulated use cases are necessary to develop a software requirement specification, which includes both functional and extra-functional requirements.

Furthermore, use cases provide guidelines for user interface design. In addition, every use case is helpful in acceptance tests.

A list of use cases allows you to preliminarily estimate the time needed for software deployment, as their description helps you understand the system's complexity.

Benefits of creating use cases

The advantages above are just the tip of the iceberg. Use cases can improve your business process in multiple ways.

Simplify the design and development process

Use cases clearly define users' expectations and allow you to plan necessary features. This helps avoid wasting time on thinking about unnecessary functionalities and allows your team to focus on the most important parts of a design.

Therefore, use cases considerably speed up the development process and make it more effective.

Minimize development costs

When you know about users' needs and expectations and, consequently, potential system requirements at the beginning of a project, then you can save resources and money on the modifications. You won't have to go back and add features because they will be there already.

Increase user satisfaction

If you take time to write detailed use cases, the system will run smoothly, and users will encounter fewer issues or challenges during use.

Comprehensive use cases will describe all the primary and alternative paths users might take during their journey. As a result, the design and development team can actively plan for them and add necessary features.

Improve teamwork

Use cases introduce a unified vision of what a product is supposed to look like. The team doesn't need to wonder what kind of functionalities to introduce. Designers and developers have clear objectives they can work towards; there is no need for guessing and redesigning.

Drawbacks of use cases

Complex use cases

You may feel a strong urge to make use cases as detailed as possible. Although comprehensive use cases can be very helpful, it's also important to keep them concise. Otherwise, they may become challenging to understand and implement.

Overlooking alternative paths

There is always a risk that the team will overlook some alternative flows. That's why it's crucial to test use cases so that you can account for as many flows as possible.

Terminology

Use cases should be understood by all team members regardless of their technical experience. Therefore, you should write use cases with simple language devoid of jargon. The terminology used within use cases should also be consistent.

Continuous updates

Use cases should be revised periodically to ensure they align with user expectations and needs. This will enable you to keep the business and user goals in line.

Work on use cases

We have already mentioned use case diagrams. They're worth looking at in more detail, as they enable you to present system functionalities and their surroundings.

A use case diagram allows you to create a graphical depiction of system features, including the functionalities visible on the user's side. It enables you to present the services visible outside the system.

A case diagram is composed of functional requirements and system surroundings. It's a kind of aggregate of system service functions.

It presents the specification, allows you to identify functionalities, and verifies modeling and implementation progress. Its advantage is that it supports communication between the project participants.

A use case diagram enables you to define the system's requirements, i.e., what the system should do from the point of view of its surroundings. It also represents the boundaries of a system, i.e., of its surroundings and components interacting with it.

A diagram's basic applications include defining and clarifying system functions. Use cases usually necessitate new requirements.

Secondly, communication with customers. Simple names and intuitiveness make the use case diagrams a good way of communication between designers and future system users.

Additionally, you can generate functional test cases. The description of a specific use case can suggest testing methods, specific test data, and a better understanding of different system use scenarios.

The use case diagrams enable system designers and future users to communicate more effectively.

Typical elements of use cases:

• Actors: It's a user who performs actions in a system.
• Goals: Describes the objectives the actor wants to complete.
• Actions: Identify the steps a user needs to take to achieve the goal.
• Basic flow: Determines the main success scenario where the user fulfills the objective.
• Exception flow: Describes a path that ends in failure; the user doesn't achieve the goal.
• Alternative flows: Present alternative paths a user might take to reach the objective.

When do both use cases and user stories work well?

Use cases and user stories are important parts of every software design process. They're indispensable in web applications, mobile applications, and subscription services.

They'll assist you in creating websites. Wherever software is used, you need to find out what a program is supposed to do to fulfill the users' needs.

Actors are important in use cases

When discussing use cases, the term "actor" frequently pops up. It concerns a user's role in relation to a system and use cases. It has to do with every user carrying out a specific usage scenario.

A use case is a set of interconnected usage scenarios, and a scenario is a specific execution of a use case.

An actor should also be understood as a set of user roles. When interacting with a case, use case users play these roles.

The actor must perform a specific function in relation to the system and use case they're using. Notably, the actor is not part of a system but situated "outside," so to speak, and must interact with at least one use case.

Actor and system in use cases

1. An actor is a particular role in relation to a system.
2. An actor doesn't always mean a specific individual. One person can log into the system as a user and, at other times, as an administrator.
3. An actor can represent an entire group of individual system users.
4. Actors are not always active, e.g., an actor approving a bank transfer.

Types of actors in use cases

There are two types of actors that take part in the use case scenario.

Primary actor

A primary actor is a person, usually a user, who initiates the interaction with a system. They have a particular goal that they want to achieve by using it. Primary actors are the ones that draw the direct benefits of using a system.

Secondary actor

A secondary actor aims to support the primary actor in achieving its goal by providing the necessary information and services so that a system can fulfill the primary actor's objective. A secondary actor may be a web service or a customer service employee who looks for information on a user's behalf.

How to write use cases?

You should be careful not to write too many use cases. It's better not to write a separate use case for every possible scenario.

A minimalistic approach is also essential when describing a use case. We're talking about a description that is several pages long. The flow shouldn't include more than 10 to 15 steps.

For example, you should write "System allows you to choose" instead of "System displays a drop-down list."

So, the idea is for the use cases to focus on what the users want to achieve and not on the screen design. Also, avoid including data definitions in use cases.

The last tip concerns use cases that users don't understand. It's vital to write use cases from a user's perspective, not from a system's point of view.

Designing use cases: step-by-step process

Define target user groups

Performing user research is an essential step in defining the target audience. You need to know who will use your product to analyze their behavior. Once you collect the necessary data, you can describe it in the form of a persona.

A persona will help the team visualize the potential user and will make the design of use cases much smoother.

Identify goals

Once you have the user or customer personas, you can easily identify the goals they want to achieve. For example, an online store customer might want to change their credit card information.

Remember that you will probably have more than one persona, and each of them will have an objective to complete.

Write down actions and scenarios

During the case writing process, you need to list every action the user has to take to complete their task. If we take the above example of an online store customer, these actions may include "logging in," "navigating to profile settings," or "entering new credit card information."

The use case scenario should include a basic flow that will determine the typical user path that ends in success and alternative flows that will describe other routes a user might take that can either end with the user achieving a goal or failure.

Create prototypes and perform usability testing

When you and your team finish writing use cases, you can start working on wireframes, mockups, and prototypes. These will help you test your use cases with the defined personas.

To test use cases, you need to conduct usability testing with users who are the reflection of created personas. During the testing, you should record the steps taken by the users and note any abnormalities. Thanks to that, the team will be able to make corrections to the design.

Use cases: History and conclusion

A use case is a sequence of operations performed by a system. They're initiated by an actor who is an abstraction, a user assigned a specific role at a given time.

A use case models the expected system behavior toward an actor but doesn't specify how to implement this behavior.

A use case entails a goal; usually, a use case describes a longer process.

Let us add that the name of a use case usually includes a noun defining the purpose of case activation, preceded by a verb describing the type of activity.

As a result of working on a use case, you define the user documentation. Drawings or a user interface mockup are very helpful, allowing you to create a specific case description more easily.

You can also offer the above-mentioned activity diagram, which in UML serves to model the activities and scope of responsibility of the system components or users.

UML (Unified Modeling Language) is a semi-formal language for modeling systems of various types. Grady Booch, James Rumbaugh, and Ivar Jacobson created it, and the Object Management Group is currently developing it.

It's worth noting here that the origins of use cases date back to 1986. It was then that Ivar Jacobson, a computer scientist involved in the creation of the Unified Modeling Language (UML), Rational Unified Process (RUP), and the concept of object-oriented software engineering, described the technique for specifying use cases.

You should remember that he initially used the terms "usage scenarios" and "usage cases." By the 1990s, use cases had become a widely used method for describing functional requirements.

The use of use cases protects you against developing software that doesn't meet user expectations. Without the necessary knowledge, you can easily ignore implementing the most important functions and add useless functionalities. Also, with use cases, business requirements can be fulfilled.

When designing products and use cases, we need to get to know our users well. Personas facilitate this process. By persona, we mean a user (customer) representation.

This enables you to create a digital product for your company and in response to a market need. Consequently, it allows you to acquire traffic and create a sales funnel. You can read more about sales funnel in our article "How to create a sales funnel using a B2B buyer persona?".