Use Case Diagram Tutorial (Guide with Examples)


Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems. They enable you to visualize the different types of roles in a system and how those roles interact with the system. This use case diagram tutorial will cover the following topics and help you create use cases better.

What is a UML Use Case Diagram

Importance of use case diagrams.

  • Use Case Diagram Objects

Use Case Diagram Guidelines

Relationships in use case diagrams, identifying actors, identifying use cases.

  • When to Use “Include”
  • How to Use Generalization
  • When to Use “Extend”
  • Use Case Diagram Templates of Common Scenarios

A UML (Unified Modeling Language) use case diagram is a visual representation of the interactions between actors (users or external systems) and a system under consideration. It depicts the functionality or behavior of a system from the user’s perspective. Use case diagrams capture the functional requirements of a system and help to identify how different actors interact with the system to achieve specific goals or tasks.

Use case diagrams provide a high-level overview of the system’s functionality, showing the different features or capabilities it offers and how users or external systems interact with it. They serve as a communication tool between stakeholders, helping to clarify and validate requirements, identify system boundaries, and support the development and testing processes.

As mentioned before use case diagrams are used to gather a usage requirement of a system. Depending on your requirement you can use that data in different ways. Below are few ways to use them.

  • To identify functions and how roles interact with them – The primary purpose of use case diagrams.
  • For a high-level view of the system – Especially useful when presenting to managers or stakeholders. You can highlight the roles that interact with the system and the functionality provided by the system without going deep into inner workings of the system.
  • To identify internal and external factors – This might sound simple but in large complex projects a system can be identified as an external role in another use case.

Use Case Diagram objects

Use case diagrams consist of 4 objects.

The objects are further explained below.

ActorActor in a use case diagram is any entity that performs a role in one given system. This could be a person, organization or an external system and usually drawn like skeleton shown below.
Use CaseA use case represents a function or an action within the system. It’s drawn as an oval and named with the function.
SystemThe system is used to define the scope of the use case and drawn as a rectangle. This an optional element but useful when you’re visualizing large systems. For example, you can create all the use cases and then use the system object to define the scope covered by your project. Or you can even use it to show the different areas covered in different releases.
PackageThe package is another optional element that is extremely useful in complex diagrams. Similar to class diagrams, packages are used to group together use cases. They are drawn like the image shown below.

Although use case diagrams can be used for various purposes there are some common guidelines you need to follow when drawing use cases.

These include naming standards, directions of arrows, the placing of use cases, usage of system boxes and also proper usage of relationships.

We’ve covered these guidelines in detail in a separate blog post. So go ahead and check out use case diagram guidelines .

There are five types of relationships in a use case diagram. They are

  • Association between an actor and a use case
  • Generalization of an actor
  • Extend relationship between two use cases
  • Include relationship between two use cases
  • Generalization of a use case

We have covered all these relationships in a separate blog post that has examples with images. We will not go into detail in this post but you can check out relationships in use case diagrams .

How to Create a Use Case Diagram

Up to now, you’ve learned about objects, relationships and guidelines that are critical when drawing use case diagrams. I’ll explain the various processes using a banking system as an example.

  • Look for Common Functionality to Reuse

Is it Possible to Generalize Actors and Use Cases

Optional functions or additional functions.

  • Validate and Refine the Diagram

Actors are external entities that interact with your system. It can be a person, another system or an organization. In a banking system, the most obvious actor is the customer. Other actors can be bank employee or cashier depending on the role you’re trying to show in the use case.

An example of an external organization can be the tax authority or the central bank. The loan processor is a good example of an external system associated as an actor.

Now it’s time to identify the use cases. A good way to do this is to identify what the actors need from the system. In a banking system, a customer will need to open accounts, deposit and withdraw funds, request check books and similar functions. So all of these can be considered as use cases.

Top level use cases should always provide a complete function required by an actor. You can extend or include use cases depending on the complexity of the system.

Once you identify the actors and the top level use case you have a basic idea of the system. Now you can fine tune it and add extra layers of detail to it.

Look for Common Functionality to Use ‘Include’

Look for common functionality that can be reused across the system. If you find two or more use cases that share common functionality you can extract the common functions and add it to a separate use case. Then you can connect it via the include relationship to show that it’s always called when the original use case is executed. ( see the diagram for an example ).

There may be instances where actors are associated with similar use cases while triggering a few use cases unique only to them. In such instances, you can generalize the actor to show the inheritance of functions. You can do a similar thing for use case as well.

One of the best examples of this is “Make Payment” use case in a payment system. You can further generalize it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All of them have the attributes and the functionality of payment with special scenarios unique to them.

There are some functions that are triggered optionally. In such cases, you can use the extend relationship and attach an extension rule to it. In the below banking system example “Calculate Bonus” is optional and only triggers when a certain condition is matched.

Extend doesn’t always mean it’s optional. Sometimes the use case connected by extending can supplement the base use case. The thing to remember is that the base use case should be able to perform a function on its own even if the extending use case is not called.

Use Case Diagram for ATM Machine - Use Case Diagram Tutorial

Use Case Diagram Templates

Use Case Diagram for Travel Agency - Use Case Diagram Tutorial

We’ve gone ahead and created use case diagram templates for some common scenarios. Although your problem or scenario won’t be exactly like this you can use them as a starting point. Check out our use case diagram templates .

Questions Regarding the Use Case Diagram Tutorial

We’ve tried to comprehensively cover everything you need to know about creating use case diagrams. If you have doubts about any section or can think of ways to improve this tutorial please let us know in the comments.

More Diagram Tutorials

  • Sequence Diagram Tutorial: Complete Guide with Examples
  • Business Process Modeling Tutorial (BPM Guide Explaining Features)
  • Ultimate Flowchart Guide (Complete Flowchart Tutorial with Examples)

Join over thousands of organizations that use Creately to brainstorm, plan, analyze, and execute their projects successfully.

FAQs on Use Case Diagrams

  • Requirement analysis : Use case diagrams aid in understanding and documenting the functional requirements of a system by identifying actors and their interactions.
  • System design : Use case diagrams provide a high-level overview of system functionality, helping to define scope and design system components.
  • Communication with stakeholders : Use case diagrams facilitate discussions and ensure a shared understanding with stakeholders.
  • Project planning and management : Use case diagrams assist in defining scope, prioritizing requirements, and identifying risks.
  • Test planning : Use case diagrams help identify scenarios and generate test cases for comprehensive test coverage.
  • Documentation : Use case diagrams serve as documentation artifacts for future development, maintenance, and upgrades.
  • Identify actors and use cases : Clearly identify the actors, representing external entities interacting with the system, and the use cases, representing system functionalities.
  • Use descriptive names : Choose meaningful and descriptive names for actors and use cases to ensure clarity and understanding.
  • Define relationships : Establish relationships between actors and use cases to depict their interactions. Use arrows to show the direction of the interaction.
  • Keep it simple : Avoid overcomplicating the diagram by focusing on the most essential actors and use cases. Too many details can make the diagram confusing and less effective.
  • Use appropriate notation : Follow the standard UML notation for use case diagrams, including ovals for use cases, stick figures for actors, and arrows for relationships.
  • Organize and layout : Arrange the actors and use cases in a logical and organized manner, ensuring a clear flow of information. Use lines and connectors to connect related use cases.
  • Use hierarchical structure : If the system has complex functionality, consider using a hierarchical structure with primary use cases at the top level and detailed use cases nested beneath.

In a use case diagram, the following elements are typically included:

  • Actors: Represent external entities interacting with the system.
  • Use cases: Represent specific functionalities or actions performed by the system.
  • Relationships: Connect actors and use cases to show interactions and dependencies.
  • System boundary: Encloses use cases and actors within the scope of the system.
  • Communication paths: Arrows or lines indicating the flow of communication.

On the other hand, use case diagrams do not include the following:

  • Internal system details: Focus on high-level functionality, not specific components.
  • Sequence of actions: No specific order of execution shown.
  • Implementation details: Independent of implementation specifics.
  • User interface details: No depiction of visual design or interface elements.

More Related Articles

Network Diagram Examples & Templates Available at Creately

Software engineer turned tech evangelist. I handle marketing stuff here at Creately including writing blog posts and handling social media accounts. In my spare time, I love to read and travel.

Our site and app needs some cookies to function and perform better. And we also use them to optimize and improve our product. Could you please set your preferences?

Cookies help us tailor your experience, making it smoother and more intuitive. They also give us insights on how to improve our platform for you and all our users. By accepting cookies, you're saying 'yes' to a better Creately experience. If you want to know more about the cookies we use and the choices you have, check out our Privacy Policy.

Skip to main content

  • Contact sales
  • Get started Get started for free

Figma Design

Design and prototype in one place

use case and analysis

Collaborate with a digital whiteboard

use case and analysis

Translate designs into code

use case and analysis

Figma Slides

Co-create presentations

use case and analysis

Explore all Figma AI features

Get the desktop, mobile,
and font installer apps

See the latest features and releases

  • Design systems
  • Prototyping
  • Wireframing
  • Online whiteboard
  • Team meetings
  • Strategic planning
  • Brainstorming
  • Diagramming
  • Product development
  • Web development
  • Design handoff
  • Engineering
  • Product managers


Config 2024

Register to attend in person or online — June 26–27

use case and analysis

Creator fund

Build and sell what you love

User groups

Join a local Friends of Figma group

Learn best practices at virtual events

Customer stories

Read about leading product teams

Shortcut: The Figma blog

Stories about how products take shape—and shape our world

use case and analysis

Get started

  • Developer docs
  • Best practices
  • Reports & insights
  • Resource library
  • Help center

What is a use case? How to write one, examples, + template

what is a use case cover photo

Designing a product takes more than listing features and goals. Before the first smartphone came out, how would you describe the ways users interact with it? Calling it a cellphone you can browse the web on is a good start, but that doesn’t explain the complexity of its systems. To map out the ways users interact with a system, tool, or product, you need a use case.

Use cases are descriptions of the ways users interact with systems to accomplish tasks or reach goals. Mapping these interactions can improve early planning and ensure a smooth development cycle. To help you work them into project planning, we’ll define a use case, explain how to write one, and share examples.

What is a use case

A use case explains how users interact with a product or system. It outlines the flow of user inputs, establishing successful and failed paths to meeting goals. This allows product teams to better understand what a system does, how it performs, and why errors occur. You can write one out or diagram a use case model for visual thinkers.

what is a use case

Use cases vary in complexity depending on your audience or system. But across the board, your use case should identify a few key components. The most important ones include:

  • Actor: anything exhibiting behavior that interacts with a system, such as a single user, a team, or another piece of software
  • System: the product or service with defined functionality
  • Goal: the purpose or objective users reach with a system’s features

Actors, systems, and goals build the foundation for a use case. When you begin tracking system interactions, a few new elements come into play:

  • Stakeholder(s): someone with a stake or interest in a system’s performance
  • Primary actor: the actor who initiates a system’s function to reach a goal
  • Preconditions: underlying factors required for the use case to happen
  • Triggers: events that begin a use case
  • Basic flows: use cases where systems work as intended to reach a goal
  • Alternate flows: different outcomes based on when and how a system veers off course

Types of use cases

Use cases come in two forms: business and system. A system use case is a detailed look at how users interact with each part of a system. It highlights how unique inputs and contexts cause the system to reach different outcomes. This level of detail highlights how a system’s individual functions work in any scenario.

Business use cases paint a more general picture of how a user might interact with your business to reach their goals. Instead of focusing on technical detail, it’s a cause-and-effect description of different inputs. For example, if you run a code debugging platform, your business use case explains how users enter their code and receive error notices.

types of use cases

Some teams like to write a business use case to outline a system’s processes before development. As developers begin their work, a manager will outline more technical system use cases to follow.

Use scenario vs. use case

Use cases show all the ways a system functions when trying to reach goals, but a scenario only depicts one example. In a scenario, the system can succeed or fail at reaching the user’s goals. Put simply, multiple use scenarios build a use case.

Use case vs. user story

Use cases depict how users interact with a system, and user stories describe features from the user’s perspective. As a result, user stories are much shorter than use cases, typically consisting of brief descriptions teams use as a jumping-off point in development. Additionally, use cases can assist multiple teams in an organization, while user stories help product teams build their tool.

Use case vs. test case

While a use case covers how users and system features work to reach goals, test cases verify if a single feature works correctly. Unlike use cases, test cases look at functionality in isolation.

For example, a test case might involve validating login functionality on an email platform, ensuring users can log in on any browser at any time after creating their account.

How to write a use case

Writing a use case sounds complex, but only requires understanding your system and its users. You can write a use case by following these six steps:

how to write a use case

1. Describe your system

Start by describing your system, or the product or service you and your team will build. Focus your description on what your system does for users. In a business use case, you can keep this background general and explain what it accomplishes. For a system use case, give an under-the-hood description of how your product functions.

Define your system by asking:

  • What form does it take: product, service, or software?
  • What features does it offer?
  • What goals can you accomplish with it?
  • How does it meet those goals?
  • What can you learn about the system from other documents like project charters ?

2. Identify the actors

Actors generally refer to users and customers but can apply to any outside force that engages with your system. Your actor needs well-defined behaviors explaining how and why actors use your system.

Identify actors by asking:

  • Are they individuals, teams, hardware, or another system?
  • Will primary and secondary actors share the same behavior?
  • Will stakeholders take on the role of actors in your use case?

3. Define your actors’ goals

Use cases highlight the outcome actors want from a system. Remember to focus on your actors’ wants over the system’s capabilities to understand why users come to your system. In some cases, customers want to use systems for more than one objective. Listing each of these objectives creates a more robust use case.

4. Create a scenario

In a use case, scenarios are the sequence of actions customers take when using a system and the flow of effects from that interaction. Your basic flows cover scenarios where a system works as intended. A user approaches the system, enters the right inputs, and your system helps them reach their goals.

Start with these successful, basic flows to create a baseline. You can use process mapping techniques to identify potential issues in the next flows.

5. Consider alternate flows

After writing a successful scenario, write alternate flows that lead to different outcomes. Typically, alternate flows involve the misuse of a system that keeps actors from reaching their goals. However, you can also note internal errors that cause a system to break down or unintended ways systems can reach goals.

Alternate flows show how different actors use a system and succeed or fail. They give a more nuanced view of everything your system can do to help you troubleshoot.

6. Repeat steps 2–5 to compile your use case

With enough variation of actors, goals, and scenarios, you can show how your system functions. Compiling these flows together gives you a use case, which can improve development and inform other documents like project status reports .

With simple systems, you can change a few elements to see every potential outcome. However complex systems may have too many elements to see each outcome. In cases like this, you can focus on testing the most common interactions. You can also design systems to prevent untested com

Try Figma’s use case template

Ready to start brainstorming use cases? Try the Figma use case template to break down your systems and find new solutions.

figma use case template

Use case example

Assume you’re a product manager developing a mobile banking app for your company. Your platform needs to streamline user registration and account setup. Here’s a sample use case format based on this app:

Background information:

  • System: a mobile banking app
  • Primary actor: customers who want to open an account
  • Secondary actor: underwriters and automated tools calculating interest rates and maximum principal balances
  • Goals: save time on account registration and onboarding
  • Stakeholders: the CEO and product VP of your company
  • Preconditions: users download the app and meet account requirements
  • Triggers: the user chooses to create a new account from the app
  • Basic flow: Users download your app and choose to create a new account. The application collects information about the user’s other accounts and credit scores. From there, it automatically shares the accounts they qualify for and their interest rates. The user finds an account that suits their needs and registers.
  • Alternate flow 1: Users enter their financial information and the app quickly generates account options. However, each account defaults to the highest interest rate their financial background allows. So, users abandon the app to find a lower rate.
  • Alternate flow 2: The onboarding process works as intended, but the app faces compliance issues such as Know Your Customer (KYC) requirements. While the app can provide account options, extra compliance steps slow the process.
  • Alternate flow 3: Because the app only looks at other accounts and credit scores, it can’t offer a full range of account options. For example, it can only offer credit cards and lines of credit. So, customers looking for mortgages have to go elsewhere.

Benefits of use cases

In the planning stage, use cases define your project scope, requirements, and roadmap. Teams can also discuss the best user outcomes and design a path to them. With alternate flows, you can also anticipate risks before they hurt a user’s experience. If that isn’t enough reason to pen one, here are a few other benefits of use cases:

  • Explains value: Use cases explain a system’s features in plain terms. So, when pitching your plans to stakeholders, a use case makes your system easier to understand.
  • Predicts costs: A use case outlines the complexity of a system. More complexity may come with additional features or safeguards. By learning how complex your system is, you can estimate development costs.
  • Improves planning: Without a use case, designers and developers focus on what a system does, not how it does it. However, use cases help teams consider all the ways to implement features and safeguards.
  • Shares alternative uses: Not all alternative flows in a system lead to failed outcomes. Mapping out different scenarios finds new solutions to old problems or expands your understanding of what a system can accomplish.

Perfect your use cases with FigJam

Use cases go beyond describing what your product can do. They give stakeholders and teams a clear picture of user interactions and successful outcomes. Whether adding a new feature, rapid prototyping , or redesigning a system, your planning should start with writing a use case.

The more insights into actors, interactions, and outcomes, the better—which is why it's important to collaborate on use cases with your team and stakeholders. A shared online whiteboard like FigJam streamlines collaboration between remote teams to help you build out comprehensive use cases. Our gallery of 300+ templates can bring teams together at any stage of development.

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

LogRocket blog logo

  • Product Management
  • Solve User-Reported Issues
  • Find Issues Faster
  • Optimize Conversion and Adoption

What is a use case? Definition, template, and how to write one

use case and analysis

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.

What is a use case? Definition, template, and how to write one

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.

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 leverage 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 case and analysis

Over 200k developers and product managers use LogRocket to create better digital experiences

use case and analysis

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 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.

More great articles from LogRocket:

  • How to implement issue management to improve your product
  • 8 ways to reduce cycle time and build a better product
  • What is a PERT chart and how to make one
  • Discover how to use behavioral analytics to create a great product experience
  • Explore six tried and true product management frameworks you should know
  • Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

The stakeholder who gets the ball rolling with an interaction to achieve a goal using your system is known as the primary actor.

Your system, which some people refer to as a scene, is composed of a number of decisions and interactions made by your actors.

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 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.

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:

Use Case Diagram Example

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:

Use Case Template

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

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.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

Get your teams on the same page — try LogRocket today.

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Reddit (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • #product strategy

use case and analysis

Stop guessing about your digital experience with LogRocket

Recent posts:.

Using BLUF Acronym to Improve Communication

Using the BLUF acronym to improve communication

As a product manager, you wield significant influence through your communication. Using BLUF in your emails will save time for you and those you work with.

use case and analysis

10 tips for a great project kickoff

Step up your game and make your next kickoff the best meeting you’ve ever facilitated — a meeting that people will remember for months.

use case and analysis

Associate product manager role and responsibilities

An associate product manager doesn’t have prior product management experience, but can grow into this role via training and mentorship.

use case and analysis

Aligning product metrics with business objectives

Product metrics are quantitative measures used to evaluate product performance and identify actionable insights.

use case and analysis

One Reply to "What is a use case? Definition, template, and how to write one"

ok. This was useful

Leave a Reply Cancel reply

Filter by Keywords

Product Management

How to create user-focused use cases for ideal success scenarios [with examples].

Engineering Team

December 30, 2023

Are you steering a project, deciphering intricate business processes, or engineering complex software solutions? If so, you’re well aware that success hinges on clarity and precision. Good news! Use cases may spare you and your clients a great deal of trouble.

Imagine you’re constructing a building. Blueprints guide you, outlining each room’s purpose and layout. This is exactly what a use case is: a blueprint to guide system requirements and resulting project operations. It helps map out processes across user interactions, helping you build a system tailored to user goals and needs. 🏗️

A stitch in time saves nine, and similarly, mastering use cases now can save you countless hours later. In this practical guide, we’ll explain:

  • The significance of a use case-driven approach in software development
  • Steps to write a use case for multiple scenarios

Benefits of use cases in business processes

Step 1: come up with the title and description, step 2: identify the actors, step 3: identify the actors’ goal, step 4: capture stakeholders and their interests, step 5: specify pre-conditions or assumptions, step 6: outline basic flow, step 7: determine exceptions or error conditions, step 8: include extensions or variations to how the system functions, step 9: consider alternative flows, create and manage your use cases in clickup docs, try writing use cases with ai, use case #1: online shopping wishlist, use case #2: travel itinerary management.

Avatar of person using AI

What Is a Use Case, and What Purpose Does It Serve?

Use cases are indispensable for understanding user-specific interactions and narratives (or user stories) to create the intended design for a system.

In technical terms, a use case is a detailed description that outlines how a user will interact with an IT solution to achieve a specific goal. It maps out the steps they take , with a clear beginning, middle, and end.

If you’re new to use cases, you’re probably wondering why you should care about it. The truth is that every software development process carries the burden of user-focused project planning. It’s critical to understand the service or system requirements beforehand so that your end product works perfectly and is profitable.

This is where a use case comes in, helping you visualize user interactions from start to finish and pinpoint any hiccups along the way . Think of it as a walkthrough in a strategic game where every move is crucial. Your input, the system’s response, specific processes, and the final outcome are all explicitly stated, leaving no room for ambiguity in decisions.

The idea here is to help project managers, business analysts, and software developers align themselves on what the end user desires in a software application or a system , taking the guesswork out of the picture. The result? Smarter decisions on:

  • Features to prioritize
  • Design scope
  • Bugs to fix

Tip: Need a quick start? Use the ClickUp User Story Mapping Template to initiate use case mapping right away! Its built-in infinite Whiteboard helps you track and prioritize user stories within minutes.

User Story Mapping Whiteboard Template by ClickUp

Use cases offer several benefits in developing and managing software systems and projects . Here are seven key advantages for various business stakeholders:

  • Clarity into specific interactions : Use cases provide a clear understanding of how users interact with a system, helping define and document functional requirements
  • Focused communication : Use cases serve as a bridge between business stakeholders , aligning developers, designers, project managers, and clients
  • Identification of how a system behaves : They help identify and document various ways users interact with the system. This includes both normal and exceptional scenarios, providing a comprehensive view of the system’s expected behavior
  • Project planning : Use cases help in planning by breaking down the desired functionalities into manageable units addressing specific system goals
  • Flexibility : They provide a flexible framework that can accommodate modifications (alternative flows) or additions without disrupting the overall system flow
  • Documentation and training : Use cases serve as valuable workflow documentation for future reference. They provide insights that can be useful for training new development team members
  • Risk identification : By exploring various success and failure scenarios, use cases assist in identifying potential risks and challenges early in the development process

What to Include in a Project’s Use Case: With Practical Steps

Use cases can include a number of elements depending on the scale and complexity of the system you’re building. Here are some of the most significant options:

  • Title and description
  • Actors (users)
  • Stakeholders
  • Pre-conditions
  • Exception to the basic flow
  • Variations or what-if scenarios
  • Alternative flows

These points can be better explained when we explore the practical side of things. Refer to the sections below to understand how to include these elements and distill complex use case scenarios into actionable steps .

Any use case study must have an engaging title. Keep it concise, specific, and indicative of the use case’s purpose. For instance, the title Optimizing Online Checkout: A Use Case for E-Commerce Conversion Enhancement immediately conveys the focus and scope.

Next, your case description should set the context concisely, pinpointing the use case actor or user, the system in question, and the ultimate goal. Here’s an example: This use case outlines the steps taken by an online shopper to complete a purchase, highlighting the system’s response at each interaction to ensure a smooth transaction and reduce cart abandonment.

Keep your language sharp, directly addressing the innovative outcomes you seek.

These are not Hollywood stars but rather the key entities— individuals, groups, or even other systems —interacting with the system under scrutiny. Identifying these actors is akin to casting characters in a play; each has a role, a purpose, and a set of actions that contribute to the unfolding narrative. 🎭

Actors within a use case diagram can be categorized as either primary or secondary . A primary actor seeks the system’s assistance by themselves to achieve a specific goal. On the other hand, a secondary actor provides a service to the system as a direct result of the primary use case. The system initiates interaction with the secondary actor for information or completion of a goal.

Let’s say a user applies for a loan online, which makes them the primary actor. In response to the loan application, the system triggers another resource to calculate interest rates—that resource is the secondary actor.

If you’re still in the research phase and need help identifying the primary actor, you may want to document your findings through the ClickUp User Research Plan Template . Its built-in features help software and UX teams map out user behavior and resolve problems within apps, websites, or projects in an orderly manner. 

ClickUp User Research Plan Template

Whether an actor is buying a product, signing up for a newsletter, or using a website, their goal is the driving force behind their interaction with your services . It’s your job to understand these goals so you can design a system that helps them achieve them in the most efficient way possible.

Let’s consider a real-world example: if you’re running a retail website, a customer’s goal might be to purchase a product in minimal steps. This use case would require you to outline the steps customers need to take to complete that purchase, from selecting the item to finalizing the payment.

Use this ClickUp SMART Goal Action Plan Template to list out the goals of all identified actors and monitor how they’re addressed by your team.

ClickUp Smart Goal Action Plan Template

It’s super vital to identify all the stakeholders and understand their interests to ensure your use case is effective. A stakeholder could be an end-user, a system administrator, or even external actors or systems interacting with your service. They all have unique needs and expectations. Here’s what you should do:

  • List all possible stakeholders involved in the use case
  • For each stakeholder, identify their interests or what they aim to gain from the use case. For instance, a potential Interest for an online shopper would be an Intuitive and efficient user experience
  • Consider how the use case can be fulfilled without compromising the overall goals
  • Regularly revisit this list as your project or product develops , ensuring new needs are accounted for

Stakeholder analysis can be a stressful job, especially when there are multiple use cases to monitor. We recommend using quality stakeholder mapping templates to structure the process. 

ClickUp Stakeholder Analysis Template

Pre-conditions set the stage for action, ensuring that all necessary conditions are in place before the use case is initiated. Think must-haves for your scenario to work—like having an internet connection for an online transaction or a user account for access to a members-only area. Imagine the scenario from the user’s perspective and identify and list these prerequisites clearly.

Here’s an illustration showing how pre-conditions are used to outline use cases and automate the workflow for a banking website:

Use Case Pre-conditions Diagram.png

This is the minimum viable product (MVP) scenario, the one where everything clicks, and your use case unfolds just as envisioned. No errors, no hiccups, just a straightforward path to a happy user.

Imagine a scenario where a customer purchases a book from an online store. The basic flow would be:

  • The customer logs in to their account
  • They search for a book by title, author, or genre
  • The customer reviews the book and adds it to their cart
  • They proceed to checkout, confirm shipping details, and select a payment method
  • They review the order summary and place the order
  • A confirmation email is sent to the customer

Each step here is supposed to be clear and necessary, guiding the user towards a satisfying transaction. Fall back on the ClickUp User Flow Template to design efficient use case pathways and share them with your team.

These exceptions represent scenarios where the standard process flow doesn’t apply. Think about what could go wrong and how your system should respond. You can:

  • Consider realistic scenarios : Think about all the ways an operation might deviate or lead to failure scenarios. This could be due to technical issues, user errors, or unexpected circumstances
  • Document each exception : Clearly describe each exception, including its cause, effect, and how your system should respond
  • Prioritize exceptions : Rank exceptions based on their likelihood and impact on user experience

Think of these as what-if scenarios that keep your processes agile . Say if a customer abandons their shopping cart, what’s the next step? This perhaps calls for creating an extension that activates a follow-up email sequence or a special discount offer to re-engage them.

Use cases should adapt to real-world complexities, offering innovative solutions that maintain user engagement. It’s about anticipating the unexpected and scripting a response that turns challenges into opportunities.

Consider alternative courses if challenges or process deviations occur. Imagine you’re designing a use case for an online shopping cart system.

Main Success Scenario (MSS):

  • The user adds items to the cart
  • The user proceeds to checkout and confirms payment

What if an item is out of stock?

  • The system notifies the user immediately
  • The system recommends similar products

What if the payment is declined?

  • Prompt the user to try a different payment method
  • Offer to save the cart for later completion

What if network issues occur?

  • Save the user’s progress automatically
  • Inform the user and attempt to reconnect

For each what-if , develop an alternative path that guides your system to a successful outcome. 

How to Write Effective Use Cases with ClickUp

Now that we have a thorough knowledge of the process of developing use cases, let’s explore how to write one professionally with ClickUp . This all-in-one project management tool comes with abundant user documentation and use case writing features. Let’s break down the process to showcase just how effortless it can be.🌹

To kick off your business use case model in ClickUp, head to ClickUp Docs , the platform’s integrated solution for creating and storing all types of documents—from user manuals and test case definitions to technical requirements.

Starting fresh? Great, create a new doc. You can use one of ClickUp’s free flowcharting templates to create use case diagrams or case study templates to document user research. Everything will be accessible from a centralized location, making it easier to keep track of the best possible outcome scenario or develop alternative paths.

Invite members from product and marketing teams to work on your use case document in real time. You may want to create Folders to store multiple use cases for your project. The best part is that you can connect your Docs with other project tasks to ensure a smooth work experience.

Let’s dive into the fun stuff! In the Doc editor, just type /ai. Boom! The ClickUp AI modal appears, ready for action. Click on Write with AI to get the party started. Type in your use case topic and add relevant technical requirements to generate a professional-grade, well-structured use case presentation within seconds.

Even with the AI-generated use cases, you’re in control. You can:

  • Insert the content elsewhere : Seamlessly insert the AI-generated content into your Doc. Or, just copy-paste and merge it with manually written use cases
  • Edit inputs : If the narrative needs a personal touch, edit your prompt or topic to guide the AI in the direction you want
  • Regenerate : Fancy a different twist? Explore varied responses from the AI with the same prompt
  • Give AI more direction : Extend the conversation by providing additional prompts or directions and get more contextual responses 🤖

Besides generating text, ClickUp AI can also fix the grammar and tone of your existing documents and even summarize lengthy case studies to save you time.

Examples of Use Cases for Software Development Projects

Let’s dive into some business use case examples to better illustrate what they look like and how they can streamline your projects.

An e-commerce platform aims to introduce a wishlist feature that enhances the online shopping experience for users.

Actors : Online shoppers

Goals : Add items to a wishlist; view wishlist contents

Stakeholders : E-commerce platform, online shoppers, product vendors, marketing team, developers

Pre-conditions : User must be logged in and browsing available products

Basic flow :

  • User logs into the e-commerce platform
  • User browses available products
  • User selects the option to add a product to their wishlist
  • System adds the selected product to the user’s wishlist
  • User can view and manage their wishlist at any time
  • System provides personalized product recommendations based on wishlist items


  • Implement a notification system to alert users when wishlist items are on sale
  • Allow users to share their wishlist with friends or family for gift suggestions

Exceptions/Error conditions:

  • If a selected product is no longer available, notify the user and provide alternate courses
  • In case of technical issues, ensure users can still browse and add items to their wishlist without disruptions

Alternative flow :

  • User selects the option to view their existing wishlist
  • System displays a list of items in the user’s wishlist
  • User can remove items from the wishlist or proceed to purchase
  • System updates the wishlist and provides relevant suggestions for additional items

A travel planning app wants to implement a feature for users to create and manage their travel itineraries.

Actors : Travelers, travel app

Goals : Create and edit travel itineraries; receive recommendations

Stakeholders : Travel app companies, travelers, local businesses, tourism boards, developers

Pre-conditions : User must be logged in and have a trip planned

  • User logs in
  • User selects the option to create a new travel itinerary
  • User inputs trip details, including destinations and dates
  • System generates an initial itinerary and suggests local attractions
  • User can modify the itinerary and add custom activities
  • System provides real-time updates and recommendations based on user preferences

Extensions/Variations :

  • Integrate a weather forecast feature for each destination
  • Allow users to share their itineraries with fellow travelers.

Exceptions/Error conditions :

  • If a selected attraction is closed or unavailable during the planned date, notify the user and suggest alternatives
  • In case of a connectivity issue, ensure users can still access and modify their itineraries offline
  • User logs into the travel app
  • The user chooses an existing route
  • System displays the current itinerary, including booked accommodations and activities
  • User can modify the itinerary, add new activities, or remove existing ones
  • System updates the itinerary and adjusts recommendations accordingly

Closing the Case on Success

Whether you’re looking to fine-tune your business process or enhance customer experience, use case modeling is a great tool for visual problem-solvers. If you need an observable result quickly, rely on the strategic use case development tools within ClickUp to accelerate your project timelines and bring your business objectives to fruition. 🍉

Sign up to explore the free-to-use solution .

Questions? Comments? Visit our Help Center for support.

Receive the latest WriteClick Newsletter updates.

Thanks for subscribing to our blog!

Please enter a valid email

  • Free training & 24-hour support
  • Serious about security & privacy
  • 99.99% uptime the last 12 months
  • System Design Tutorial
  • What is System Design
  • System Design Life Cycle
  • High Level Design HLD
  • Low Level Design LLD
  • Design Patterns
  • UML Diagrams
  • System Design Interview Guide
  • Crack System Design Round
  • System Design Bootcamp
  • System Design Interview Questions
  • Microservices
  • Scalability

What are UML Diagrams

  • Unified Modeling Language (UML) Diagrams
  • UML Full Form

Structural Diagrams

  • Class Diagram | Unified Modeling Language (UML)
  • Object Diagrams | Unified Modeling Language (UML)
  • Deployment Diagram in Unified Modeling Language(UML)
  • Package Diagram | Introduction, Elements, Use Cases and Benefits

Behavioral Diagrams

  • Behavioral Diagrams | Unified Modeling Language(UML)
  • State Machine Diagrams | Unified Modeling Language (UML)
  • Activity Diagrams | Unified Modeling Language (UML)

Use Case Diagrams | Unified Modeling Language (UML)

  • Sequence Diagrams | Unified Modeling Language (UML)
  • Interaction Overview Diagrams | Unified Modeling Language (UML)

A Use Case Diagram is a vital tool in system design, it provides a visual representation of how users interact with a system. It serves as a blueprint for understanding the functional requirements of a system from a user’s perspective, aiding in the communication between stakeholders and guiding the development process.


Important Topics for the Use Case Diagrams

  • What is a Use Case Diagram in UML?
  • Use Case Diagram Notations
  • Use Case Diagram Relationships
  • How to draw a Use Case diagram in UML?
  • What are common Use Case Diagram Tools and Platforms?
  • What are Common Mistakes and Pitfalls while making Use Case Diagram?
  • What can be Use Case Diagram Best Practices?
  • What are the Purpose and Benefits of Use Case Diagrams?

1. What is a Use Case Diagram in UML?

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents the interaction between actors (users or external systems) and a system under consideration to accomplish specific goals. It provides a high-level view of the system’s functionality by illustrating the various ways users can interact with it.


2. Use Case Diagram Notations

UML notations provide a visual language that enables software developers, designers, and other stakeholders to communicate and document system designs, architectures, and behaviors in a consistent and understandable manner.

1.1. Actors

Actors are external entities that interact with the system. These can include users, other systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use cases and receive the outcomes. Proper identification and understanding of actors are crucial for accurately modeling system behavior.


1.2. Use Cases

Use cases are like scenes in the play. They represent specific things your system can do. In the online shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or “Update Product Information”. Use cases are represented by ovals.


1.3. System Boundary

The system boundary is a visual representation of the scope or limits of the system you are modeling. It defines what is inside the system and what is outside. The boundary helps to establish a clear distinction between the elements that are part of the system and those that are external to it. The system boundary is typically represented by a rectangular box that surrounds all the use cases of the system.

Purpose of System Boundary:

  • Scope Definition: It clearly outlines the boundaries of the system, indicating which components are internal to the system and which are external actors or entities interacting with the system.
  • Focus on Relevance: By delineating the system’s scope, the diagram can focus on illustrating the essential functionalities provided by the system without unnecessary details about external entities.


3. Use Case Diagram Relationships

In a Use Case Diagram, relationships play a crucial role in depicting the interactions between actors and use cases. These relationships provide a comprehensive view of the system’s functionality and its various scenarios. Let’s delve into the key types of relationships and explore examples to illustrate their usage.

3.1. Association Relationship

The Association Relationship represents a communication or interaction between an actor and a use case. It is depicted by a line connecting the actor to the use case. This relationship signifies that the actor is involved in the functionality described by the use case.

Example: Online Banking System

  • Actor: Customer
  • Use Case: Transfer Funds
  • Association: A line connecting the “Customer” actor to the “Transfer Funds” use case, indicating the customer’s involvement in the funds transfer process.


3.2. Include Relationship

The Include Relationship indicates that a use case includes the functionality of another use case. It is denoted by a dashed arrow pointing from the including use case to the included use case. This relationship promotes modular and reusable design.

Example: Social Media Posting

  • Use Cases: Compose Post, Add Image
  • Include Relationship: The “Compose Post” use case includes the functionality of “Add Image.” Therefore, composing a post includes the action of adding an image.


3.3. Extend Relationship

The Extend Relationship illustrates that a use case can be extended by another use case under specific conditions. It is represented by a dashed arrow with the keyword “extend.” This relationship is useful for handling optional or exceptional behavior.

Example: Flight Booking System

  • Use Cases: Book Flight, Select Seat
  • Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use case when the user wants to choose a specific seat, but it is an optional step.


3.4. Generalization Relationship

The Generalization Relationship establishes an “is-a” connection between two use cases, indicating that one use case is a specialized version of another. It is represented by an arrow pointing from the specialized use case to the general use case.

Example: Vehicle Rental System

  • Use Cases: Rent Car, Rent Bike
  • Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions of the general use case “Rent Vehicle.”


4. How to draw a Use Case diagram in UML?

Step 1: identify actors.

Determine who or what interacts with the system. These are your actors. They can be users, other systems, or external entities.

Step 2: Identify Use Cases

Identify the main functionalities or actions the system must perform. These are your use cases. Each use case should represent a specific piece of functionality.

Step 3: Connect Actors and Use Cases

Draw lines (associations) between actors and the use cases they are involved in. This represents the interactions between actors and the system.

Step 4: Add System Boundary

Draw a box around the actors and use cases to represent the system boundary. This defines the scope of your system.

Step 5: Define Relationships

If certain use cases are related or if one use case is an extension of another, you can indicate these relationships with appropriate notations.

Step 6: Review and Refine

Step back and review your diagram. Ensure that it accurately represents the interactions and relationships in your system. Refine as needed.

Step 7: Validate

Share your use case diagram with stakeholders and gather feedback. Ensure that it aligns with their understanding of the system’s functionality.

Let’s understand how to draw a Use Case diagram with the help of an Online Shopping System:

2. use cases:.

  • Browse Products
  • Add to Cart
  • Manage Inventory (Admin)

3. Relations:

  • The Customer can browse products, add to the cart, and complete the checkout.
  • The Admin can manage the inventory.

Below is the usecase diagram of an Online Shopping System:


5. What are common Use Case Diagram Tools and Platforms?

Several tools and platforms are available to create and design Use Case Diagrams. These tools offer features that simplify the diagram creation process, facilitate collaboration among team members, and enhance overall efficiency. Here are some popular Use Case Diagram tools and platforms:

6.1. Lucidchart

  • Cloud-based collaborative platform.
  • Intuitive drag-and-drop interface.
  • Real-time collaboration and commenting.
  • Templates for various diagram types.
  • Integration with other tools like Jira and Confluence.


  • Free, open-source diagramming tool.
  • Works offline and can be integrated with Google Drive, Dropbox, and others.
  • Offers a wide range of diagram types, including Use Case Diagrams.
  • Customizable shapes and themes.

6.3. Microsoft Visio

  • Part of the Microsoft Office suite.
  • Supports various diagram types, including Use Case Diagrams.
  • Integration with Microsoft 365 for collaborative editing.
  • Extensive shape libraries and templates.

6.4. SmartDraw

  • User-friendly diagramming tool.
  • Templates for different types of diagrams, including Use Case Diagrams.
  • Integration with Microsoft Office and Google Workspace.
  • Auto-formatting and alignment features.

6.5. PlantUML

  • Open-source tool for creating UML diagrams.
  • Text-based syntax for diagram specification.
  • Integrates with various text editors and IDEs.
  • Supports collaborative work using version control systems.

6. What are Common Mistakes and Pitfalls while making Use Case Diagram?

Avoiding common mistakes ensures the accuracy and effectiveness of the Use Case Diagram. Here are key points for each mistake:

6.1. Overcomplication:

  • Mistake: Including excessive detail in the diagram.
  • Impact: Confuses stakeholders and complicates understanding.
  • Prevention: Focus on essential use cases and maintain an appropriate level of abstraction.

6.3. Ambiguous Relationships:

  • Mistake: Unclear relationships between actors and use cases.
  • Impact: Causes misinterpretation of system interactions.
  • Prevention: Clearly define and label relationships with proper notation.

6.3. Inconsistent Naming Conventions:

  • Mistake: Inconsistent naming of actors and use cases.
  • Impact: Causes confusion and hinders communication.
  • Prevention: Establish and adhere to a consistent naming convention.

6.4. Misuse of Generalization:

  • Mistake: Incorrect use of generalization relationships.
  • Impact: Misrepresentation of the “is-a” relationship between use cases or actors.
  • Prevention: Ensure accurate usage to represent specialization relationships.

6.5. Overlooking System Boundaries:

  • Mistake: Not clearly defining the system boundary.
  • Impact: Challenges understanding of the system’s scope.
  • Prevention: Clearly enclose relevant actors and use cases within a system boundary.

6.6. Lack of Iteration:

  • Mistake: Treating the diagram as a static artifact.
  • Impact: May become outdated and not reflect the current state of the system.
  • Prevention: Use an iterative approach, updating the diagram as the system evolves.

7. What can be Use Case Diagram Best Practices?

Creating effective and clear Use Case Diagrams is crucial for communicating system functionality and interactions. Here are some best practices to follow:

7.1 Keep it Simple:

  • Focus on High-Level Functionality: Avoid unnecessary details and concentrate on representing the system’s primary functionalities.
  • Use Concise Language: Use clear and concise language for use case and actor names to enhance readability.

7.2 Consistency:

  • Naming Conventions: Maintain a consistent naming convention for use cases and actors throughout the diagram. This promotes clarity and avoids confusion.
  • Formatting Consistency: Keep a consistent format for elements like ovals (use cases), stick figures (actors), and lines to maintain a professional look.

7.3. Organize and Align:

  • Logical Grouping: Organize use cases into logical groups to represent different modules or subsystems within the system.
  • Alignment: Maintain proper alignment of elements to make the diagram visually appealing and easy to follow.

7.4. Use Proper Notation:

  • Consistent Symbols: Adhere to standard symbols for actors (stick figures), use cases (ovals), and relationships to ensure understanding.
  • Proper Line Types: Clearly distinguish between association, include, extend, and generalization relationships using appropriate line types.

7.5. Review and Iterate:

  • Feedback Loop: Regularly review the diagram with stakeholders to ensure accuracy and completeness.
  • Iterative Process: Use an iterative process, updating the diagram as the system evolves or more information becomes available.

By following these best practices, you can create Use Case Diagrams that effectively communicate the essential aspects of a system, fostering a shared understanding among stakeholders and facilitating the development process.

8. What are the Purpose and Benefits of Use Case Diagrams?

The Use Case Diagram offers numerous benefits throughout the system development process. Here are some key advantages of using Use Case Diagrams:

  • Use Case Diagrams provide a visual representation of the system’s functionalities and interactions with external entities.
  • This visualization helps stakeholders, including non-technical ones, to understand the system’s high-level behavior.
  • Use Case Diagrams serve as a powerful communication tool, facilitating discussions between stakeholders, developers, and designers.
  • They provide a common language for discussing system requirements, ensuring a shared understanding among diverse team members.
  • During the requirements analysis phase, Use Case Diagrams help in identifying, clarifying, and documenting user requirements.
  • They capture the various ways users interact with the system, aiding in a comprehensive understanding of system functionality.
  • Use Case Diagrams center around user goals and scenarios, emphasizing the perspective of external entities (actors).
  • This focus on user interactions ensures that the system is designed to meet user needs and expectations.
  • In the system design phase, Use Case Diagrams aid in designing how users (actors) will interact with the system.
  • They contribute to the planning of the user interface and help in organizing system functionalities.
  • Use Case Diagrams are valuable for deriving test cases and validating system behavior.
  • Testers can use the diagrams to ensure that all possible scenarios, including alternative and exceptional paths, are considered during testing.

9. Conclusion

In conclusion, a Use Case Diagram in UML serves as a powerful tool for capturing and visualizing the functional requirements and interactions within a system. By representing actors, use cases, and their relationships in a clear and concise manner, this diagram provides a high-level overview of the system’s behavior.

Please Login to comment...

Similar reads.

  • Geeks Premier League 2023
  • Geeks Premier League
  • System Design

Improve your Coding Skills with Practice


What kind of Experience do you want to share?

A Comprehensive Guide to Use Case Diagrams: Tips and Free Templates

Harry Foster

Harry Foster

Published on May 29, 2024, updated on May 29, 2024

A Use Case Diagram is a graphical modeling tool in UML (Unified Modeling Language) used to depict the interactions between a system and its external entities. As a crucial tool for requirement analysis and system design, a Use Case Diagram helps team members understand the system’s functional requirements and interaction processes, facilitating effective system design and development. This article will provide an in-depth analysis of Use Case Diagrams, covering their definition, purposes, application cases, and usage techniques to help readers fully leverage this powerful tool, optimize the development process, and ensure the system meets user expectations.

Three Components of a Use Case Diagram

Actors: Actors represent external entities interacting with the system, such as people, other systems, or devices. In a Use Case Diagram, actors are depicted by simple icons, usually a stick figure or a rectangular box.


Use Cases: Use cases describe the interaction processes between the system and external actors, providing an abstract description of system behavior. Each use case in the diagram has a name and a unique identifier and can be associated with other use cases to form relationships.


Relationships: These depict the interactions between actors and use cases or between different use cases. Common types include associations, inclusions, extensions, and generalizations, usually represented by different lines and arrows.

Four Common Relationship Types in Use Case Diagrams

The table below summarizes the common relationship types between actors and use cases, and between use cases themselves, along with their representations in the diagram:



The association represents the interaction between an actor and a use case or between two use cases, indicating communication or interaction. For example, in an e-commerce system, there is an association between "Browse Products" and "Add to Cart," as well as between "User" and "Purchase Products."

In this relationship, a use case includes another use case to achieve more complex functionality. For instance, in a banking system, "Transfer Funds" might include "Verify Balance," and "Withdraw Cash" might include "Authenticate User."

This relationship allows a use case to extend another use case to add additional functionalities. For example, in a hotel booking system, "Book Room" might extend to "Select Additional Services," and "Login" might extend to "Forgot Password."


set boundaries of the system

Used to represent that a use case is a specialized form or sub-use case of another base use case. For example, "Buy Used Car" is a specialized form of "Buy Car," and "Login with Account" are sub-use case of "Login to System."

The Role of Use Case Diagrams

Requirement Analysis: Use Case Diagrams present the system’s functional requirements, aiding team members in understanding the system's behavior and functionality. They help define the system’s functional boundaries and the interactions with external actors.

System Design: They transform functional requirements into executable tasks and operations, helping the team identify and define the main functional modules and their interrelations and dependencies.

Communication and Collaboration: Use Case Diagrams allows team members to quickly grasp the functional requirements and interaction relationships, fostering better understanding and collaboration. They also facilitate effective communication with clients and stakeholders.

Validation and Testing: These diagrams clarify the system’s functional requirements and the expected behaviors of actors, assisting the testing team in designing and executing effective test cases. They help verify whether the system meets the requirements and identify and resolve potential issues and risks.

How to Draw a Use Case Diagram

Choose a Suitable Drawing Tool

Here, we recommend a powerful online drawing tool— Boardmix . It offers robust drawing functionalities and supports efficient team collaboration.


Standard symbols and customization options

Boardmix provides a library of standard use case diagram symbols and supports text, fill color, line direction, and color customization. It also offers quick access to official configuration styles, making it easy to use!

Efficient team collaboration


Boardmix supports real-time collaboration, allowing project teams to discuss around a shared whiteboard, edit documents online, conduct remote presentations, and hold audio/video meetings anytime, anywhere.

Rich template resources

The Boardmix community section offers a wealth of templates, including Use Case Diagrams, available for free use to help you quickly create your diagrams!

Drawing Steps


Identify Actors: Determine the external actors interacting with the system, such as users, other systems, or entities.

Identify Use Cases: Identify the system’s functional requirements, representing user goals or system operations. Each use case represents a specific function or business scenario.

Establish Relationships Between Actors and Use Cases: Use lines to connect actors with the use cases they are involved in, indicating the interactions.

Add Relationship Types: Add associations, includes, extends, and generalizations to appropriately describe the interactions between use cases.

Detail Use Cases: For complex use cases, break them down into smaller sub-use cases to better describe the system’s functionality.

Application Analysis of Use Case Diagrams

Online Shopping System Use Case Diagram

Suppose we are developing an online shopping system with roles like regular users and system users, supporting functionalities such as browsing products, adding products to the cart, searching for products, and submitting orders. By identifying all actors and their relationships with use cases, we can draw the Use Case Diagram.


The diagram presents the main functions and interactions, helping the development team understand the user's needs and expectations during the shopping process. It defines core functions like product browsing and cart management, ensuring the system meets basic shopping requirements. UI designers can also better understand the interaction flow, designing user-friendly interfaces and processes, and enhancing user experience.

Hospital Appointment System Use Case Diagram

Suppose we are developing a hospital appointment system with roles like patients, nurses, registration desk, and administrators, supporting functionalities like viewing doctor schedules, making appointments, and canceling appointments.


The diagram helps the development team understand user needs better, designing a system that meets user expectations, thus improving user satisfaction and hospital operational efficiency. It also aids the team in considering potential issues and exceptions during development, increasing efficiency and system quality.

In conclusion, Use Case Diagrams are essential tools for requirement analysis and system design, facilitating communication and understanding, and optimizing system design. For a powerful combination of functionality, ease of use, collaboration, and creativity, we highly recommend Boardmix . It enhances thinking capabilities and promotes teamwork and creativity.

How to Create a Comprehensive Project Plan: A Step-by-Step Guide with Templates

How to Create a Comprehensive Project Plan: A Step-by-Step Guide with Templates

How to Create Gantt Charts: Tips and Guide

How to Create Gantt Charts: Tips and Guide

Xmind Program: How to Use It and Online Alternatives!

Xmind Program: How to Use It and Online Alternatives!

go to back

Visual Paradigm Guides

Home » Use Case Analysis » Mastering the Art of Developing Use Case Diagrams and Scenarios

Mastering the Art of Developing Use Case Diagrams and Scenarios

  • Posted on October 11, 2023
  • / Under UML , Use Case Analysis


Use Case Diagrams and Use Case Scenarios are essential tools in the field of software development and system analysis. They provide a visual representation of how users interact with a system and help in understanding the various paths and possibilities within a system. In this article, we will explore the process of developing Use Case Diagrams and delve into the importance of creating detailed Use Case Scenarios.

What is Use Case Diagram?

Developing Use Case Diagrams

  • Begin by reviewing business specifications to identify the actors involved. Actors are entities that interact with the system.
  • High-level events should be identified, and primary use cases should be developed to describe these events and how actors initiate them.
  • Carefully examine the roles played by actors to identify all possible primary use cases initiated by each actor.
  • Review each primary use case to determine variations in flow through the use case and establish alternative paths.
  • If available, use a context-level data flow diagram as a starting point for creating a use case. External entities in the diagram can be potential actors.
  • Examine the data flow to determine if it initiates a use case or is produced by a use case.
  • The provided example illustrates a use case diagram for a conference planning system. It identifies actors such as Conference Chair, Participants, Speakers, Hotel Reservations, and Caterers, along with their respective roles.

Developing Use Case Scenarios

Select Open Use Case Details...

  • Each use case has a corresponding description known as a use case scenario . The primary use case represents the standard flow of events in the system.
  • Alternative paths describe variations in behavior. These could include scenarios like dealing with out-of-stock items or handling a credit card rejection.
  • While there is no standardized use case scenario format, organizations often use predefined templates to document use cases. This ensures consistency, readability, and standardized information in the model.

Example: Use Case Modeling

Let’s continue with the example of the conference planning system mentioned earlier and identify some specific use cases along with a sample template for a use case scenario.

Example: Conference Planning System

  • Actors: Participants
  • Description: Participants register for the conference.
  • Alternate Path: Payment failure, registration cancellation.
  • Actors: Conference Chair
  • Description: Conference Chair arranges speakers for different sessions.
  • Alternate Path: Speaker unavailability, changes in session topics.
  • Actors: Participants, Hotel Reservations
  • Description: Participants reserve rooms for accommodation.
  • Alternate Path: Room unavailability, reservation modification.
  • Actors: Conference Chair, Caterer
  • Description: Conference Chair and Caterer plan meals and banquets.
  • Alternate Path: Dietary restrictions, changes in catering requirements.

Use Case Scenario Template

Use Case: Register for Conference

Primary Actor: Participant

Description: Participants can register for the conference online. They provide necessary personal information, select sessions they wish to attend, and proceed to payment. The system verifies the payment details and sends a confirmation email upon successful registration. In case of payment failure, the system notifies the participant and provides instructions for resolving the issue. Participants can also cancel their registration, and in such cases, the system updates the records accordingly.

Alternative Paths:

  • Description: If the payment transaction fails, the system displays an error message with details about the failure.
  • Participant receives an error message.
  • Participant reviews payment details.
  • Participant retries payment or contacts support.
  • Description: Participants can choose to cancel their registration.
  • Participant accesses registration details.
  • Participant selects the cancellation option.
  • System confirms cancellation and updates records.

This template provides a structured way to document the main flow of events and alternative paths for a specific use case. It helps in ensuring clarity, consistency, and ease of understanding for both developers and stakeholders involved in the system development process.

Mastering the development of Use Case Diagrams and Scenarios is crucial for effective system analysis and software development. These tools not only provide a clear visual representation of system interactions but also help in anticipating and addressing various scenarios that users may encounter. As organizations continue to evolve their processes, adopting best practices in developing these diagrams and scenarios will contribute to streamlined and efficient system development.

Leave a Comment Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

use case and analysis

  • Visual Paradigm Online
  • Request Help
  • Customer Service
  • Community Circle
  • Demo Videos
  • Visual Paradigm
  • YouTube Channel
  • Academic Partnership

Diagramming Build diagrams of all kinds from flowcharts to floor plans with intuitive tools and templates.

Whiteboarding collaborate with your team on a seamless workspace no matter where they are., data generate diagrams from data and add data to shapes to enhance your existing visuals., enterprise friendly easy to administer and license your entire organization., security see how we keep your data safe., apps & integrations connect to all the tools you use from microsoft, google workspace, atlassian, and more..

  • What's New Read about new features and updates.

Product Management Roadmap features, brainstorm, and report on development, so your team can ship features that users love.

Software engineering design and maintain complex systems collaboratively., information technology visualize system architecture, document processes, and communicate internal policies., sales close bigger deals with reproducible processes that lead to successful onboarding and training..

  • Getting Started Learn how to make any type of visual with SmartDraw. Familiarize yourself with the UI, choosing templates, managing documents, and more.
  • Templates get inspired by browsing examples and templates available in SmartDraw.

Diagrams Learn about all the types of diagrams you can create with SmartDraw.

Whiteboard learn how to combine free-form brainstorming with diagram blueprints all while collaborating with your team., data visualizers learn how to generate visuals like org charts and class diagrams from data., development platform browse built-in data visualizers and see how you can build your own custom visualization., open api the smartdraw api allows you to skip the drawing process and generate diagrams from data automatically., shape data add data to shapes, import data, export manifests, and create data rules to change dashboards that update..

  • Explore SmartDraw Check out useful features that will make your life easier.
  • Blog Read articles about best practices, find tips on collaborating, learn to give better presentations and more.

Support Search through SmartDraw's knowledge base, view frequently asked questions, or contact our support team.

  • Site License Site licenses start as low as $2,995 for your entire organization.
  • Team License The SmartDraw team License puts you in control with powerful administrative features.

Apps & Integrations Connect to all the tools you use.

  • Contact Sales

What's New?

New Google Slides Integrations

Solutions By Team

License everyone for as low as $1 per user per month.

Save money, and replace Visio, Lucidchart, Lucidspark, and Miro with a SmartDraw site license.

Smartdraw replaces them all

Getting Started Learn to make visuals, familiarize yourself with the UI, choosing templates, managing documents, and more.

Templates get inspired by browsing examples and templates available in smartdraw., developer resources, additional resources.

Explore SmartDraw

Site License As low as $1 per user per month for your entire organization.

Team license get powerful administrative features for your team., solutions for your team.

New SmartDraw Dashboard

Use Case Diagram

Easily visualize your system's functionality with use case diagrams, what is a use case diagram, why make use case diagrams, use case diagram symbols, use case diagram tutorial, use case diagram tips, use case diagram examples, how to make uml diagrams, uml diagram tips, other uml diagrams, with smartdraw, you can create many different types of diagrams, charts, and visuals.

A use case diagram is a dynamic or behavior diagram in UML . Use case diagrams model the functionality of a system using actors and use cases. Use cases are a set of actions, services, and functions that the system needs to perform. In this context, a "system" is something being developed or operated, such as a web site. The "actors" are people or entities operating under defined roles within the system.

User management subsystem

Use case diagrams are valuable for visualizing the functional requirements of a system that will translate into design choices and development priorities.

They also help identify any internal or external factors that may influence the system and should be taken into consideration.

They provide a good high level analysis from outside the system. Use case diagrams specify how the system interacts with actors without worrying about the details of how that functionality is implemented.

Basic Use Case Diagram Symbols and Notations

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries.

System symbol - use case diagram

Draw use cases using ovals. Label the ovals with verbs that represent the system's functions.

Use case symbol - use case diagram

Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor stereotype.

Actor symbol - use case diagram


Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.

Relationship symbol - use case diagram

Use Case Diagram Tool Tutorial

Start with one of SmartDraw's blank UML diagram templates or an included use case diagram example. You can quickly add shapes and users and connect them. To add text, just click and type.

Tips for UML Use Case Diagrams

When thinking of use cases, think of the end goal of a user. They don't want to "login" or "sign up." That's not a use case. The use case is more like "make a purchase."

Actors don't have names. They're not "Bob." They represent the role of someone interacting with the system.

Keep your names short and the size of your use cases consistent for a professional look.

For a detailed implementation of a user's goal use a sequence diagram .

Simple Use Case Example

Use Case Diagram and Other UML Examples

The best way to understand use case diagrams is to look at some examples of use case diagrams.

Click on any of these UML diagrams included in SmartDraw and edit them:

UML Use Case Diagram

Browse SmartDraw's entire collection of UML diagram examples and templates

More Use Case Diagram Information

  • UML diagram tool
  • Software design diagram templates
  • Data flow diagram software
  • Game design software

Try SmartDraw's Use Case Diagram Software Free

Discover why SmartDraw is the best use case diagram software today.

Visual Paradigm logo

  • Demo Videos
  • Interactive Product Tours
  • Request Demo

What is Use Case Diagram?

What is Use Case Diagram?

Here are some questions that have been asked frequently in the UML world are: What is a use case diagram? Why Use case diagram? or simply, Why use cases? . Some people don't know what use case is, while the rest under-estimated the usefulness of use cases in developing a good software product. Is use case diagram underrated? I hope you will find the answer when finished reading this article.

So what is a use case diagram? A UML use case diagram is the primary form of system/software requirements for a new software program underdeveloped. Use cases specify the expected behavior (what), and not the exact method of making it happen (how). Use cases once specified can be denoted both textual and visual representation (i.e. use case diagram). A key concept of use case modeling is that it helps us design a system from the end user's perspective. It is an effective technique for communicating system behavior in the user's terms by specifying all externally visible system behavior.

A use case diagram is usually simple. It does not show the detail of the use cases:

  • It only summarizes some of the relationships between use cases, actors, and systems.
  • It does not show the order in which steps are performed to achieve the goals of each use case.

As said, a use case diagram should be simple and contains only a few shapes. If yours contain more than 20 use cases, you are probably misusing use case diagram.

The figure below shows the UML diagram hierarchy and the positioning of the UML Use Case Diagram. As you can see, use case diagrams belong to the family of behavioral diagrams.

Use Case Diagram in UML Diagram Hierarchy

  • There are many different UML diagrams that serve different purposes (as you can see from the UML diagram tree above). You can describe those details in other UML diagram types and documents, and have them be linked from use cases.
  • Use cases represent only the functional requirements of a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately, again, with other UML diagrams.

Learn UML Faster, Better and Easier

Are you looking for a Free UML tool for learning UML faster, easier and quicker? Visual Paradigm Community Edition is a UML software that supports all UML diagram types. It is an international award-winning UML modeler, and yet it is easy-to-use, intuitive & completely free.

Origin of Use Case

These days use case modeling is often associated with UML, although it has been introduced before UML existed. Its brief history is as follow:

  • In 1986, Ivar Jacobson first formulated textual and visual modeling techniques for specifying use cases.
  • In 1992 his co-authored book Object-Oriented Software Engineering - A Use Case Driven Approach helped to popularize the technique for capturing functional requirements, especially in software development.

Purpose of Use Case Diagram

Use case diagrams are typically developed in the early stage of development and people often apply use case modeling for the following purposes:

  • Specify the context of a system
  • Capture the requirements of a system
  • Validate a systems architecture
  • Drive implementation and generate test cases
  • Developed by analysts together with domain experts

Use Case Diagram at a Glance

A standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use Case Diagram example below:

Use Case Diagram at a glance

Notation Description Visual Representation

Structuring Use Case Diagram with Relationships

Use cases share different kinds of relationships. Defining the relationship between two use cases is the decision of the software analysts of the use case diagram. A relationship between two use cases is basically modeling the dependency between the two use cases. The reuse of an existing use case by using different types of relationships reduces the overall effort required in developing a system. Use case relationships are listed as the following:

Use Case Relationship Visual Representation

use case may include (subject to specified in the extension) the behavior specified by base use case .

Use Case Examples

Use case example - association link.

A Use Case diagram illustrates a set of use cases for a system, i.e. the actors and the relationships between the actors and use cases.

Use Case Diagram Example

Use Case Example - Include Relationship

The include relationship adds additional functionality not specified in the base use case. The <<Include>> relationship is used to include common behavior from an included use case into a base use case in order to support the reuse of common behavior.

Use Case Diagram Include Example

Use Case Example - Extend Relationship

The extend relationships are important because they show optional functionality or system behavior. The <<extend>> relationship is used to include optional behavior from an extending use case in an extended use case. Take a look at the use case diagram example below. It shows an extend connector and an extension point "Search".

Use Case Diagram Extend Example

Use Case Example - Generalization Relationship

A generalization relationship means that a child use case inherits the behavior and meaning of the parent use case. The child may add or override the behavior of the parent. The figure below provides a use case example by showing two generalization connectors that connect between the three use cases.

Use Case Diagram Generalization Example

Use Case Diagram - Vehicle Sales Systems

The figure below shows a use case diagram example for a vehicle system. As you can see even a system as big as a vehicle sales system contains not more than 10 use cases! That's the beauty of use case modeling.

The use case model also shows the use of extend and include. Besides, there are associations that connect between actors and use cases.

Use Case Diagram Example - Vehicle Sales Systems

How to Identify Actor

Often, people find it easiest to start the requirements elicitation process by identifying the actors. The following questions can help you identify the actors of your system (Schneider and Winters - 1998):

  • Who uses the system?
  • Who installs the system?
  • Who starts up the system?
  • Who maintains the system?
  • Who shuts down the system?
  • What other systems use this system?
  • Who gets information from this system?
  • Who provides information to the system?
  • Does anything happen automatically at a present time?

How to Identify Use Cases?

Identifying the Use Cases, and then the scenario-based elicitation process carries on by asking what externally visible, observable value that each actor desires. The following questions can be asked to identify use cases, once your actors have been identified (Schneider and Winters - 1998):

  • What functions will the actor want from the system?
  • Does the system store information? What actors will create, read, update or delete this information?
  • Does the system need to notify an actor about changes in the internal state?
  • Are there any external events the system must know about? What actor informs the system of those events?

Use Case Diagram Tips

Now, check the tips below to see how to apply use case effectively in your software project.

  • Always structure and organize the use case diagram from the perspective of actors.
  • Use cases should start off simple and at the highest view possible. Only then can they be refined and detailed further.
  • Use case diagrams are based upon functionality and thus should focus on the "what" and not the "how".

Use Case Levels of Details

Use case granularity refers to the way in which information is organized within use case specifications, and to some extent, the level of detail at which they are written. Achieving the right level of use case granularity eases communication between stakeholders and developers and improves project planning.

Alastair Cockburn in Writing Effective Use Cases gives us an easy way to visualize different levels of goal level by thinking in terms of the sea:

Different levels of details of use case

  • While a use case itself might drill into a lot of detail about every possibility, a use-case diagram is often used for a higher-level view of the system as blueprints.
  • It is beneficial to write use cases at a coarser level of granularity with less detail when it's not required.

I hope you can answer "what is use case diagram" now and can apply use case in your project. If you want to learn more about other UML diagram types, please check the UML guide: Overview of the 14 UML Diagram Types .

Try to Draw UML Use Case Diagram Now

You've learned what a Use Case Diagram is and how to draw a Use Case Diagram. It's time to draw a Use Case Diagram of your own. Get Visual Paradigm Community Edition, a free UML software, and create your own Use Case Diagram with the free Use Case Diagram tool. It's easy-to-use and intuitive.

Related Links

  • What is Unified Modeling Language?
  • A list of UML diagram tools

Turn every software project into a successful one.

We use cookies to offer you a better experience. By visiting our website, you agree to the use of cookies as described in our Cookie Policy .

© 2024 by Visual Paradigm. All rights reserved.

  • Privacy statement
  • Agile, DevOps and software development methodologies

Kate Brush

What is a use case?

A use case is a methodology used in system analysis to identify, clarify and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. The method creates a document that describes all the steps taken by a user to complete an activity.

Business analysts are typically responsible for writing use cases and they are employed during several stages of software development, such as planning system requirements, validating design, testing software and creating an outline for online help and user manuals. A use case document can help the development team identify and understand where errors may occur during a transaction so they can resolve them.

Every use case contains three essential elements:

  • The actor. The system user -- this can be a single person or a group of people interacting with the process.
  • The goal. The final successful outcome that completes the process.
  • The system. The process and steps taken to reach the end goal, including the necessary functional requirements and their anticipated behaviors.

Characteristics of use case

Use cases describe the functional requirements of a system from the end user's perspective, creating a goal-focused sequence of events that is easy for users and developers to follow. A complete use case will include one main or basic flow and various alternate flows. The alternate flow -- also known as an extending use case -- describes normal variations to the basic flow as well as unusual situations.

A use case should:

  • Organize functional requirements.
  • Model the goals of system/actor interactions.
  • Record paths -- called scenarios -- from trigger events to goals.
  • Describe one main flow of events and various alternate flows.
  • Be multilevel, so that one use case can use the functionality of another one.

How to write a use case

There are two different types of use cases: business use cases and system use cases.

A business use case is a more abstract description that's written in a technology- agnostic way, referring only to the business process being described and the actors that are involved in the activity. A business use case identifies the sequence of actions that the business needs to perform to provide a meaningful, observable result to the end user.

On the other hand, a system use case is written with more detail than a business use case, referring to the specific processes that must happen in various parts of the system to reach the final user goal. A system use case diagram will detail functional specifications, including dependencies, necessary internal supporting features and optional internal features.

When writing a use case, the writer should consider design scope to identify all elements that lie within and outside the boundaries of the processes. Anything essential to the use case that lies outside its boundaries should be indicated with a supporting actor or by another use case. The design scope can be a specific system, a subsystem or the entire enterprise. Use cases that describe business processes are typically of the enterprise scope.

As mentioned, the three basic elements that make up a use case are actors, the system and the goal. Other additional elements to consider when writing a use case include:

  • Stakeholders , or anybody with an interest or investment in how the system performs.
  • Preconditions, or the elements that must be true before a use case can occur.
  • Triggers, or the events that cause the use case to begin.
  • Post-conditions, or what the system should have completed by the end of the steps.

Developers write use cases in narrative language, describing the functional requirements of a system from the end user's perspective. They can also create a use case diagram using a unified modeling language, with each step represented by its name in an oval; each actor represented by a stick figure with their name written below; each action indicated by a line between the actor and step; and the system boundaries indicated by a rectangle around the use case.

Visual example of use case methodology

The writing process includes:

  • Identifying all system users and creating a profile for each one. This includes every role played by a user who interacts with the system.
  • Selecting one user and defining their goal -- or what the user hopes to accomplish by interacting with the system. Each of these goals becomes a use case.
  • Describing the course taken for each use case through the system to reach that goal.
  • Considering every alternate course of events and extending use cases -- or the different courses that can be taken to reach the goal.
  • Identifying commonalities in journeys to create common course use cases and write descriptions of each.
  • Repeating steps two through five for all other system users.

When writing a use case, developers may use a sequence diagram -- which shows how objects react along a timeline -- to model the interactions between objects in a single use case. Sequence diagrams allow developers to see how each part of the system interacts with others to perform a specific function as well as the order in which these interactions occur.

Benefits of use case

A single use case can benefit developers by revealing how a system should behave while also helping identify any errors that could arise in the process.

Other benefits of use case development include:

  • The list of goals created in the use case writing process can be used to establish the complexity and cost of the system.
  • By focusing both on the user and the system, real system needs can be identified earlier in the design process.
  • Since use cases are written primarily in a narrative language, they are easily understood by stakeholders, including customers, users and executives -- not just by developers and testers.
  • The creation of extending use cases and the identification of exceptions to successful use case scenarios saves developers time by making it easier to define subtle system requirements.
  • By identifying system boundaries in the design scope of the use case, developers can avoid scope creep .
  • Premature design can be avoided by focusing on what the system should do rather than how it should do it.

In addition, use cases can be easily transformed into test cases by mapping the common course and alternate courses and gathering test data for each of the scenarios. These functional test cases will help the development team ensure all functional requirements of the system are included in the test plan.

Furthermore, use cases can be used in various other areas of software development, including project planning, user documentation and test case definitions. Use cases can also be used as a planning tool for iterative development.

Use case vs. user story

While both a use case and a user story are used to identify system users and describe their goals, the two terms are not interchangeable; they serve different purposes. While a use case is more specific and looks directly at how a system will act, a user story is an Agile development technique that focuses on the result of the activities and the benefit of the process being described.

More specifically, the use case -- often written as a document -- describes a set of interactions that occur between a system and an actor to reach a goal. The user story will describe what the user will do when they interact with the system, focusing on the benefit derived from performing a specific activity.

In addition, user stories are often less documented than use cases and deliberately neglect important details. User stories are primarily used to create conversations by asking questions during scrum meetings, whereas use cases are used by developers and testers to understand all the steps a system must take to satisfy a user's request.

Examples of use case

Outside of software and systems development, another example of a use case is driving directions.

A driver is looking to get from Boston to New York City. In this scenario, the actor is the driver, the goal is getting to New York and the system is the network of roads and highways they will take to get there. There is likely one common route that drivers take between Boston and New York -- this is the common course use case. However, there are various detours the driver can take that will still eventually lead to New York City. These different routes are the extending use cases. The goal of the driving directions is to identify each turn the driver must take to reach their destination.

More specifically related to software and system development, a use case can be used to identify how a customer completes an order through an online retailer . First, developers must name the use case and identify the actors. In this scenario, the use case will be called "complete purchase" and the actors are:

  • the customer;
  • the order fulfillment system; and
  • the billing system.

Next, the triggers, preconditions and post-conditions are defined. In this case, the trigger is the customer indicating that they would like to purchase their selected products. The precondition for the use case is the customer selecting the items they eventually want to buy. The post-conditions include the order being placed; the customer receiving a tracking ID for their order; and the customer receiving an estimated delivery date for their order.

Once the title, actors, triggers, preconditions and post-conditions are identified, the basic flow -- or common course use case -- can be outlined. This starts with the customer indicating they want to make a purchase and ending with the customer exiting the system after their order has been confirmed. After the normal flow is written, all extending use cases should be detailed, recorded and included in the document.

Editor's note: This article was written by Kate Brush in 2020. TechTarget editors revised it in 2022 to improve the reader experience.

Continue Reading About use case

  • Review these 9 low-code use cases and industry examples
  • 6 use cases for Docker containers -- and when to pass
  • Common use cases for observability
  • Top 10 edge computing use cases and examples
  • UML use case diagrams: Tips and FAQ

Related Terms

Dig deeper on agile, devops and software development methodologies.

use case and analysis

impact mapping


How to apply impact mapping to software with examples


CISA posts incident response guide for water utilities


Malware vs. ransomware: What's the difference?


Centralized identity management is vital to the protection of your organization's resources. Do you know how to secure Azure ...

CIOs are taking a hard look at the VMware portfolio as the number of alternatives rises in the hybrid cloud infrastructure market.

Building AI apps in the cloud requires you to pay more attention to your cloud workload management because of how AI impacts ...

Managing microservices without API gateways might be uncommon, but not unheard of. Consider the benefits, downsides and available...

The switch from microservices to monolith could save costs and improve performance. Explore key considerations and questions to ...

The RESTful API Modeling Language, or RAML, can be a powerful tool for developers looking to create an efficient, standardized ...

Former Proofpoint CEO sets an AI-focused agenda, including an Nvidia partnership launched this week, while denying layoff rumors ...

A series of product updates at Datadog DASH broke out of the vendor's usual observability domain and into territory held by ...

JFrog plans to meld AI/ML development with established DevSecOps pipelines through the acquisition of Qwak in a bid to help more ...

Does the world really need another programming language? Yes, say developers behind Zig. Here are five of the top features Zig ...

Virtual threads in Java currently lack integration with the stream API, particularly for parallel streams. Here's how a JDK 22 ...

The three-level DBMS architecture makes database design more secure, extensible and accessible for client applications. Learn the...

Compare Datadog vs. New Relic capabilities including alerts, log management, incident management and more. Learn which tool is ...

Many organizations struggle to manage their vast collection of AWS accounts, but Control Tower can help. The service automates ...

There are several important variables within the Amazon EKS pricing model. Dig into the numbers to ensure you deploy the service ...

use case and analysis

UML Use Case Diagram Tutorial

Why use a uml diagram, i want to create my own use case diagram in lucidchart., i want to create a use case diagram from a lucidchart template..

The purpose of a use case diagram in UML is to demonstrate the different ways that a user might interact with a system. Create a professional diagram for nearly any use case using our UML diagram tool.

4 minute read

Do you want to create your own UML diagram? Try Lucidchart. It's fast, easy, and totally free.

What is a use case diagram?

In the Unified Modeling Language (UML), a use case diagram can summarize the details of your system's users (also known as actors) and their interactions with the system. To build one, you'll use a set of specialized symbols and connectors. An effective use case diagram can help your team discuss and represent:

Scenarios in which your system or application interacts with people, organizations, or external systems

Goals that your system or application helps those entities (known as actors) achieve

The scope of your system

When to apply use case diagrams

A use case diagram doesn't go into a lot of detail—for example, don't expect it to model the order in which steps are performed. Instead, a proper use case diagram depicts a high-level overview of the relationship between use cases, actors, and systems. Experts recommend that use case diagrams be used to supplement a more descriptive textual use case.

UML is the modeling toolkit that you can use to build your diagrams. Use cases are represented with a labeled oval shape. Stick figures represent actors in the process, and the actor's participation in the system is modeled with a line between the actor and use case. To depict the system boundary, draw a box around the use case itself.

UML use case diagrams are ideal for:

Representing the goals of system-user interactions

Defining and organizing functional requirements in a system

Specifying the context and requirements of a system

Modeling the basic flow of events in a use case

Use Case Diagram Example

Use case diagram components

To answer the question, "What is a use case diagram?" you need to first understand its building blocks. Common components include:

Use case diagram components

Use case diagram symbols and notation

Associations:, system boundary boxes:, use case diagram examples, book publishing use case diagram example.

Use case diagram example

Railway reservation use case diagram example

You can adapt this template for any process where a customer purchases a service. With attractive color schemes, text that’s easy to read and edit, and a wide-ranging UML shape library, you’re ready to go! Click to try out this template on your own.

Use case diagram example

Chainsaw use case diagram example

Consider this example: A man with a chainsaw interacts with the environment around him. Depending on the situation and the context of the situation, he might fall into one of many different use cases. Does he seem to be on his way to work? Is there anything ominous about the way he is wielding his chainsaw? For example, if he is using the chainsaw in a non-occupational setting, we might have reason to think that he falls within the scope of "scary."

UML Use case diagram example

Additional Resources

  • Communication Diagram Tutorial
  • How to Draw a Sequence Diagram in UML
  • All about composite structure diagrams
  • System Sequence Diagrams in UML
  • UML Sequence Diagram Tutorial
  • State Machine Diagram Tutorial
  • All about UML interaction diagrams
  • All about UML package diagrams
  • How to Draw an Object Diagram in UML
  • How to Draw a Timing Diagram in UML
  • How to Draw a Deployment Diagram in UML
  • How to Draw a State Machine Diagram in UML
  • How to Draw a Communication Diagram in UML
  • How to Draw a Component Diagram in UML
  • How to Draw a Class Diagram in UML
  • Deployment Diagram Tutorial
  • Timing Diagram Tutorial
  • Object Diagram Tutorial
  • UML Activity Diagram Tutorial
  • What is Unified Modeling Language
  • UML Class Diagram Tutorial
  • Component Diagram Tutorial

Use Lucidchart to collaborate and create UML diagrams when you start an account for free today! No plugins or download required.

Adaptive US Logo 2024-min-2

  • BA Bootcamp
  • Skill Training
  • BA Mentoring Support
  • Certifications
  • Free Resources

Use Cases and Scenarios - A Comprehensive Guide


Creating use cases and scenarios is one of the most valuable tools in a business analyst's arsenal. Whether you're an aspiring BA or a seasoned pro, understanding this technique can elevate your skills and career. This guide will explore use cases and scenarios, its historical significance, components, strengths, limitations, and how they can be leveraged for optimal results.

What are Use Cases and Scenarios?

Use cases and scenarios are powerful tools used in business analysis to define the functional requirements of a system or software. A use case describes how a user interacts with a system to achieve specific goals, while a scenario is an instance or sequence of events that illustrates how the system behaves in response to those user interactions.

Consider use cases as real-life examples demonstrating how users can interact with a system, while scenarios provide detailed step-by-step descriptions of each interaction. Both play crucial roles in capturing and validating requirements, ensuring all stakeholders understand what needs to be built.

Using use cases and scenarios, a business analyst can effectively communicate complex ideas by breaking them into manageable units. This technique helps identify potential issues early on, allowing for timely adjustments and mitigations during development.

Creating comprehensive use cases involves identifying primary actors (users), defining their goals or objectives within the system being analyzed, outlining preconditions necessary for executing each use case successfully, documenting steps actors take to accomplish their goals, and specifying post-conditions or expected outcomes.

Scenarios expand upon these use cases by providing concrete examples based on possible situations or inputs. Each scenario details user actions and corresponding responses from the system being analyzed. These realistic illustrations clarify functional requirements and help uncover gaps or inconsistencies before implementation begins.

History of Use Cases and Scenarios

The history of use cases and scenarios as a business analysis technique can be traced back to the 1980s. During this time, a computer scientist, Ivar Jacobson, introduced the concept in his work on Object-Oriented Software Engineering.

Use cases were initially developed to capture functional requirements for software systems. They provided a structured approach to understanding how users interact with the system and what actions they need to perform. Analysts could gain deeper insights into user needs and system behavior by defining specific scenarios or situations in which these interactions occur.

Over the years, use cases have evolved and become integral to the business analysis toolkit . They are now widely used across various industries in software development, process improvement, system design, and product development.

One key aspect of use case modeling is its ability to facilitate communication between stakeholders from different backgrounds. Use cases provide a common language that enables everyone involved in a project to understand user requirements and expectations.

Another significant development in recent years has been the incorporation of agile methodologies into business analysis practices. Use cases have adapted well to these iterative approaches by allowing for continuous refinement and prioritization based on changing customer needs.

In conclusion, the history of use cases and scenarios showcases their effectiveness as a valuable tool for business analysts. From their humble beginnings as functional requirement-capturing techniques to their current widespread adoption across industries, use cases continue to prove their worth by helping organizations better understand user needs and deliver solutions that meet those requirements effectively.

Assosiations Use Case

Associations Use Case is a powerful technique in business analysis that helps identify and define the relationships between different actors or entities within a system. It allows the business analyst to understand how these associations impact the system's functionality.

In an Associations Use Case, we capture the interactions and dependencies between various actors and entities. This can include relationships such as "customer places an order," "supplier delivers goods," or "manager approves expense reports."

By defining these associations, we gain valuable insights into how information flows through the system and how different components interact. This knowledge is crucial for designing efficient processes and ensuring smooth communication between stakeholders.

One key benefit of Associations Use Cases is its ability to capture complex scenarios involving multiple actors and entities. It allows us to visualize these interactions, making it easier to analyze potential bottlenecks or areas for improvement.

However, like any technique, Associations Use Cases also have their limitations. They may not be suitable for all systems or projects, straightforward ones. Additionally, creating detailed use case diagrams for complex systems can be time-consuming and require collaboration from various stakeholders.

Associations Use Cases are a valuable tool in a business analyst's toolkit for understanding relationships within a system. By leveraging this technique effectively, we can ensure that our solutions align with stakeholder needs and facilitate effective communication among all parties involved.

Extend Use Case

Extend Use Case is an essential concept in the field of business analysis. It allows for expanding and customizing a primary use case to accommodate additional functionality or variations. An extended use case adds optional steps or actions that can be triggered based on certain conditions.

In this technique, one primary use case acts as the base scenario, while other secondary use cases are added as extensions. These extensions represent different possible outcomes or alternate paths that can be taken within the main flow of the primary use case.

Using extended use cases, business analysts can capture all possible scenarios and variations during system interactions. This helps ensure comprehensive coverage of requirements and provides a clear understanding of how different parts of a system will interact with each other.

One advantage of extended use cases is their ability to handle complex systems by breaking them down into manageable portions. Dividing functionalities into smaller units makes it easier to analyze each component and identify potential issues or conflicts.

However, it's important to note that there are limitations to using extended use cases. They can become overly complex if not properly managed and documented. Tracking multiple extensions for a single base scenario can become cumbersome over time.

Extend use cases provide valuable insights into how various components within a system interact with each other under different circumstances. Business analysts can leverage this technique to enhance their understanding of user requirements and design more robust solutions for their organizations' needs.

Elements of Use Case Description

Use case descriptions are an essential part of the business analysis process. They provide a detailed understanding of how a system or application should behave in various scenarios.

The elements of a use case description typically include the following:

  • Title: A concise and descriptive name for the use case.
  • Actors: The individuals or entities interacting with the system.
  • Description: A brief overview of what happens within the use case.
  • Preconditions: The conditions must be met before the use case can be executed.
  • Main Flow: The step-by-step sequence of events during normal execution.
  • Alternate Flows: Any deviations from the main flow, such as error handling or exception scenarios.
  • Postconditions: The system's state after completing the use case.
  • Related Use Cases: Any other use cases related to or triggered by this one.

By including these elements in a use case description, business analysts can effectively communicate requirements to stakeholders and development teams, ensuring everyone understands how the system should function in different situations.

Strengths and Limitations of Use Cases and Scenarios

Use Cases and Scenarios have become crucial tools for business analysts in gathering requirements and designing solutions. They offer several strengths that make them valuable in the analysis process.

One major strength is their ability to provide a clear and comprehensive understanding of how users interact with a system or software. Use Cases outline specific actions, actors, and expected outcomes, allowing stakeholders to visualize the entire user journey.

Analysts can identify potential edge cases or exceptions impacting system behavior by capturing different scenarios within a Use Case. This helps uncover hidden requirements or dependencies early on, leading to more robust solutions.

Moreover, Use Cases promote effective communication among project teams by providing a common language for discussing requirements. Developers find it easier to translate these documented interactions into functional code.

However, like any technique, Use Cases also come with certain limitations. One limitation is that they focus more on functionality than non-functional aspects such as performance or security requirements. Analysts must supplement this technique with other approaches to address all aspects adequately.

Another limitation is that creating detailed Use Case diagrams can be time-consuming and resource-intensive when dealing with complex systems or large-scale projects. A balance must be struck between documenting enough detail without overwhelming the team.

Despite these limitations, when used effectively alongside other techniques like user stories or prototypes, Use Cases remain an essential tool for business analysts in capturing requirements accurately while keeping end-users at the center of design decisions.

50 BABOK Techniques - Cover Image - Square - 3D-1

Worked Out Example

Let us learn the process model by means of an example. Governance, Risk, and Compliance (GRC) management system is developed for the IT and ITES domains. The primary objective of the GRC management system is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, including planning and tracking projects and programs using standards such as CMMI, ISO 9001, and ISO 27001.

This example lets us understand how a user logs in to the Governance, Risk, and Compliance (GRC) management system.


Allow users who have legitimate user profile ID and password to business analysts use restricted functionalities within Governance, Risk and Compliance (GRC) management system and to restrict users whom are not authorized to go into system


1. User has legitimate Governance, Risk and Compliance (GRC) management user login profile ID and password

Success End Conditions

1. System redirect user to user home page with main menu

Failed End Conditions

1. System redirect user back to login page with appropriate error message

Primary, Secondary Actors

1. Governance, Risk and Compliance (GRC) management Users (not login yet)


1. User clicks on Login button




User visit URL of login page of Governance, Risk and Compliance management


System display login page of Governance, Risk and Compliance management


User input user profile ID and password and submit


System validate input, accept and record user login


System redirect user to home page with main menu


Branching Action


If user input is incomplete, System prompt user with alert message


If password (case-sensitive) is incorrect, System record failure attempt and redirect user to login page with error message

4.b 1

If over failure attempt limit, System lock profile and redirect user to forget password page


If user profile is not valid, System redirect user to login page with error message


If user profile is expired, System redirect user to login page with error message


If user profile is locked, System redirect user to login page with error message


If over login session limit, System redirect user to login page with error message


If user is required to change password, System redirect user to change password page


If user is required to update profile, System redirect user to update profile page

Related business analysts use Cases

List any other business analysts use cases that are included ("called") by this business analysts use case. Common functionality that appears in multiple business analysts use cases can be split out into a separate use case that is included by ones that need that common functionality.

Business rules

Follow corporate password policy for passwords. 


Highest - Most of business-critical functionalities are dependent on this business analysts use Case

Non-functional requirements (Performance, Security, Usability etc.)

System shall response to User within 5 seconds regardless of login acceptance, failure or redirection to other pages


Per Entity (country) - Estimated 1 request for this business analysts use Case every 5 minutes


1. User has a broadband access or relatively fast connection to Internet


2. User Internet browser is a supported version and can support JavaScript

Use Cases and Scenarios are valuable tools for business analysts to understand and document the requirements of a system or software application. Use cases clearly understand how users interact with the system by focusing on the interactions between actors and the system.

Use cases have been widely adopted in various industries since their introduction in the 1980s. They offer a structured approach to capturing functional requirements and help ensure all stakeholders understand how the system should behave.

The parts of a use case, such as associations, extended relationships, and descriptions, allow for comprehensive documentation that both technical and non-technical stakeholders can easily understand.

While there are strengths to using use cases - such as their ability to define user interactions clearly - they also have limitations. Use cases may not capture all possible scenarios or edge cases, requiring additional analysis techniques to supplement them. Additionally, they may become complex when dealing with highly intricate systems or large-scale projects.

As technology evolves and new methodologies emerge within business analysis practices, business analysts must adapt their techniques accordingly. However, use cases remain essential in documenting functional requirements and ensuring successful project outcomes.

So next time you embark on a new project as a business analyst or work alongside one, consider utilizing Use Cases and Scenarios as part of your analysis toolkit. These techniques will undoubtedly contribute towards better stakeholder communication and pave the way for successful project delivery.

You May Also Like

These Related Stories

use case and analysis

Introduction to UML With Worked Out Examples - Adaptive US

use case and analysis

Interface Analysis with Worked Out Example

use case and analysis

IIBA CCA vs. ISO 27001 Lead Auditor: Which one should you go for?

Get email notifications, no comments yet.

Let us know what you think

We use essential cookies to make Venngage work. By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts.

Manage Cookies

Cookies and similar technologies collect certain information about how you’re using our website. Some of them are essential, and without them you wouldn’t be able to use Venngage. But others are optional, and you get to choose whether we use them or not.

Strictly Necessary Cookies

These cookies are always on, as they’re essential for making Venngage work, and making it safe. Without these cookies, services you’ve asked for can’t be provided.

Show cookie providers

  • Google Login

Functionality Cookies

These cookies help us provide enhanced functionality and personalisation, and remember your settings. They may be set by us or by third party providers.

Performance Cookies

These cookies help us analyze how many people are using Venngage, where they come from and how they're using it. If you opt out of these cookies, we can’t get feedback to make Venngage better for you and all our users.

  • Google Analytics

Targeting Cookies

These cookies are set by our advertising partners to track your activity and show you relevant Venngage ads on other sites as you browse the internet.

  • Google Tag Manager
  • Infographics
  • Daily Infographics
  • Popular Templates
  • Accessibility
  • Graphic Design
  • Graphs and Charts
  • Data Visualization
  • Human Resources
  • Beginner Guides

Blog Graphic Design 10 Use Case Diagram Examples (and How to Create Them)

10 Use Case Diagram Examples (and How to Create Them)

Written by: Letícia Fonseca Feb 15, 2022

10 Use Case Diagram Examples (and How to Create Them) Blog Header

Use case diagrams are a great tool that can help businesses and developers alike to design processes and systems.

By capturing requirements and expectations from a user’s point of view, they ensure the development of correct and efficient systems that will properly serve a user’s goals.

In this article, we will define what a use case diagram is and provide you with different use case diagram examples.

You can create your own use case diagrams using Venngage’s  Diagram Maker  and use case diagram templates . No design experience is required!

Click to jump ahead:

What is a use case diagram?

  • 5 Use case diagram examples and templates that you can use

What are the benefits of a use case diagram?

Types of use case diagrams, what are the elements of a uml use case diagram, faqs about use case diagrams.

A use case diagram is a visual representation of the different ways and possible scenarios of using a system. It illustrates how a user will perform actions and interact with a particular system, such as a website or an app.

For example, this use case diagram depicts the different functions of a banking system for customers:

use case diagram example

In Unified Modeling Language (UML), systems are presented at different levels of detail to show a specific perspective in the system’s design. Use case diagrams are considered UML diagrams.

UML diagrams define and organize the high-level functions and scope of a system. By modeling the basic flow of events in a use case, they help identify the goals that you need to achieve with every system-user interaction.

5 Use case diagram examples and templates that you can use:

Here are some use case diagram templates and examples to guide your diagram creation process:

Retail use case diagram

This use case diagram example depicts the internal functions and employee interactions within a retail system.

use case diagram example

It features basic system functions represented by color-coordinated boxes to signify use cases based on the user’s role. A use case diagram like this can be of great use to retail stores with B2C e-commerce systems.

Design a use case or UML diagram that reflects your brand with Venngage’s My Brand Kit feature. 

Add your website when prompted and the editor automatically imports all your brand assets, including your logo, colors, and fonts.

Restaurant use case diagram

In this example, a restaurant’s daily operations serve as the system, the staff represent the actors, and their tasks are the use cases.

use case and analysis

This use case diagram can be particularly helpful to restaurants or fast-food chains in terms of systemizing routine processes and presenting day-to-day activities to employees in a simpler and more orderly way.

Travel use case diagram

Here is a use case diagram that maps out how different types of users can engage with a travel booking website or application.

use case diagram example

This comprehensive template includes extended use cases marked by dotted lines and arrows instead of simple lines. It can be scaled down or up for hotels, airlines, and other travel reservation systems.

Banking use case diagram

Designed for automated teller machine (ATM) systems, this use case diagram portrays different types of transactions as use cases.

use case diagram example

As this example is very simple and contains only essential elements, it can be adapted for other banking systems like branch banking or online banking.

Consumer electronics store use case diagram

Last but not least, this use case diagram example illustrates how sales and management teams can use a retail system to carry out tasks.

use case diagram example

It can be applied to retail systems for consumer electronics and home appliances, fast-moving consumer goods, and other retail sectors.

Ready to master use case diagrams? Check out our blog for everything you need to know and more use case diagram examples for your inspiration.

Use case diagrams can aid your development process with the following benefits:

  • Guiding development:  Use case diagrams can help establish the cost and complexity of your system. It does so by specifying which functions become requirements that will make it to the development stage.
  • User-driven approach:  Use case diagrams are written in natural language, which helps users easily understand them. Additionally, they provide businesses an excellent way to communicate with customers. Here is a use case diagram example that shows the basic transactional path of a banking customer:

use case and analysis

  • Simplifying solutions:  By breaking down solutions into practical functions or features, use case diagrams can decrease the complexity of the problem that your system is trying to solve.
  • Tracking progress:  Use case diagrams can be used to monitor which use cases have been implemented, tested, and delivered and help you identify which functions work and which ones don’t.

Create use case diagrams that are easy to understand with Venngage’s extensive icon library. We offer 40,000+ icons, including diverse people icons, so your diagrams can reflect your users more accurately.

Double-click an icon in your chosen template, and choose from the options in the menu. 

There are many different  types of diagrams  that can be used for designing and representing systems and processes. As for UML use case diagrams, they are classified into two types: behavioral and structural UML diagrams.

Behavioral UML diagrams

Behavioral UML diagrams provide a standard way to visualize the design and behavior of a system. Under them are 7 other types of diagrams which are:

  • Activity diagrams
  • State machine diagrams
  • Sequence diagrams
  • Communication diagrams
  • Interaction overview diagrams
  • Timing diagrams
  • Use case diagrams

As an example, this use case diagram portrays how an ATM system will behave or react when a customer or administrator performs an action.

use case diagram example

Structural UML diagrams

Structural UML diagrams on the other hand focus on depicting the concepts involved in a system and how they relate to each other. There are also 7 types of structural UML diagrams:

  • Class Diagram
  • Component Diagram
  • Deployment Diagram
  • Object Diagram
  • Package Diagram
  • Profile Diagram
  • Composite Structure Diagram

Use case diagrams contain a combination of different elements and specialized symbols and connectors. Whether you want your use case diagram to be simple or in-depth, it should include the following basic components:

  • Actors  – An actor is anyone who performs an action using your system. Actors or users can be a person, an organization, or an external system. Actors are represented by stick figures in a use case diagram. In this example, the functions of a system are modeled for two types of actors: persons and organizations.

use case diagram example

  • System  – The system scope covers a sequence of actions and interactions between users and the system. To depict the system boundary, system boundary boxes are used to signify that a use case is within the scope of the system.
  • Use cases  – Use cases are the different uses or applications that your system can offer users. Horizontally shaped ovals are used to symbolize use cases while lines are drawn to connect the user to the use case. Here is an example to illustrate the relationship between users and use cases:

use case diagram example

  • Goals  – The goal is the end result of a use case. An effective use case diagram should describe the activities involved in reaching the goals behind each use case.

What is included and not included in a use case diagram?

Use case diagrams describe the relationship between the users, the system, and its use cases. They do not need to go into a lot of detail and explain how the system operates internally. Here is a guide on what to include and what not to include in your use case diagram:

What to include:

  • Who is using the system
  • How the user will use the system
  • What the user’s goal is
  • What steps the user takes to accomplish a task
  • How the system responds to a particular action

What not to include:

  • The order in which steps are performed
  • Details about user interfaces
  • Programming language

When to apply use case diagrams

Here are some situations where applying use case diagrams can be particularly useful:

Early stages of system development:

  • Gather and visualize requirements:  Capture the needs and goals of different user groups and how the system interacts with them.
  • Define system scope:  Ensure you’re building the right features and functions based on user needs.
  • Identify potential issues:  Spot inconsistencies or missing functionalities early on in the development process.

Communication and collaboration:

  • Explain system functionality to stakeholders:  Offer a clear and concise visual representation of what the system does and how it works.
  • Facilitate discussions and feedback:  Use the diagram as a starting point for discussions and encourage user input into the design process.
  • Align teams on system goals:  Ensure everyone involved has a shared understanding of the user experience and system objectives.

Testing and documentation:

  • Derive test cases:  Use the diagram to identify different use cases and scenarios to test the system functionality.
  • Document system behavior:  Provide a clear and easily understandable reference for future maintenance and updates.
  • Support ongoing communication:  Explain complex system features to new team members or users.

Beyond these situations, consider using use case diagrams when:

  • You want to focus on the  “what” and “why”  instead of the technical details.
  • You need to deal with  multiple user types  with different needs and functionalities.
  • You want to  increase understanding and agreement  among stakeholders.

How do you write a use case diagram?

Writing a use case diagram involves deconstructing processes in order to reveal a basic overview of your system. Here are some steps that you can follow:

Step 1:  Identify the actors (users) who are going to be engaging with your system. Categorize each type of user based on their roles.

Step 2:  Pick one type of user and list what actions they would take using the system. Each action becomes a use case.

Step 3:  Create a goal for every use case. Identify what is required from the system to achieve these goals.

Step 4:  Structure the use cases. Include in the description for each use case the basic course of events that will happen when a user performs a certain action. It should describe what the user does and how the system responds.

Step 5:  Take into consideration alternate courses of events and add them to extend the use case.

Step 6:  Repeat steps 2-5 to create a use case diagram for each type of user.

What software is used to create a use case diagram?

There are various tools and software available for creating a use case diagram. For starters, you can try Microsoft Visio which is a diagramming and vector graphics application that is part of the Microsoft Office family.

You can also go for web-based software if you don’t want the hassle of downloading, installing, and updating programs. Venngage’s diagram features include pre-made use case diagram templates that you can customize for your business and development needs.

Don’t guess, visualize: Use case diagrams map how you gain from this system

Creating a use case diagram can help you illustrate how your system can fulfill the needs and goals of your users. Make sure to use Venngage’s  diagram maker  to create a successful use case diagram for your next project.

Discover popular designs

use case and analysis

Infographic maker

use case and analysis

Brochure maker

use case and analysis

White paper online

use case and analysis

Newsletter creator

use case and analysis

Flyer maker

use case and analysis

Timeline maker

use case and analysis

Letterhead maker

use case and analysis

Mind map maker

use case and analysis

Ebook maker

3 August 2004

Martin Fowler

requirements analysis

Use cases are a technique for organizing and eliciting requirements. They were originally popularized by Ivar Jacobson in the late 80's and early 90's.

People commonly ask questions about use cases, most of which can be answered by Alistair Cockburn's book , which is by far the best book on use cases. You should read this book before using or asking questions about use cases.

Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value - the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.

Use case are at their best when they are short and readable. You should not be spending weeks, let alone months, generating use case documents before you begin development.

Also see UseCasesAndStories

Bridging the Gap

How to Write a Use Case: Template + Tutorial

A use case is a powerful tool to both analyze and communication the software requirements.

  • If you have a business background, a use case will help you define what the software needs to do, even if you don’t have much (or any) technology/coding knowledge.
  • As a technical professional, a use case will help you communicate about what the software does using less “tech speak”.

In this use case tutorial, you’ll learn exactly how to apply use cases in your analytical work. I’ll also share favorite use case template, with detailed annotations and descriptions so you know exactly what goes into each section.

>> Click here to download the use case template <<

For those who like to read instead of watch, here’s the full text of the video:

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about how to write a use case. I’m super excited because these cases are my absolute favorite analytical technique . Hopefully, as I share this tutorial of how to actually put one together, you start to see why and are encouraged to start experimenting with them, as well, or maybe have a takeaway if you’ve done them before about you can make them a little bit better.  

Why Write a Use Case

First of all, why would you write a use case? What is this for? Why do you need to do it? As a businessperson, you might be concerned about how to actually communicate the technical requirements or the software requirements to a—I don’t even know what those are, first of all. How do I communicate with my software developers to make sure I get what I want out of the software system?

That’s one of the great tools or reasons to use a use case is that they are really a connection point. Both business and technical users should be able to really understand them and provide feedback on them. As business analysts, we use them as a communication tool, really, to literally bridge that gap or really connect people together, in terms of a common technique, common language about what the software will do.  

As a technical person, you might be looking for a way to communicate with your business stakeholders, build stakeholder engagement , and get rid of that “text” speak, less about how the system does it and more about what the system does. That really is going to help speed up the communication and clarify and make sure you’re building what the business actually needs and wants when you sit down and work on the code.  

What is a Use Case?  

What is a use case? How does it solve these problems for us as analysts, as technical people, as business users?

A use case is a textual description that captures the interaction between a user and a system to achieve a specific goal.

This is really important. It’s the interaction between the user and a software system.

It’s different than a business process , which might capture all the things that that user would do to achieve a bigger picture goal or outcome in the organization. Use case is very specific and dialed in, in terms of how that user actually interacts with that software system to achieve a goal. This is a more granular goal.

Use Case Examples

Some example use cases include:

  • Purchase Course
  • Watch Video
  • Subscribe to Free Training
  • Download Template

Use cases represent specific and concrete things that a user can do with the software system, and it captures all the ways that that user and system can interact.

The details of the use case include all the exceptions and variations and what happens if you go to purchase a course, and your email address is invalid or your credit card’s not valid or something like that. All those variations of what can go wrong in variant paths in the scope of the system only. This is what allows us to get at the software requirements.

Use Case Template + Step-by-Step Tutorial

use case and analysis

You can take notes if you want, but you can also download our template.

It’s one of the thirteen templates we include with our Business Analyst Template Toolkit .

How to Name a Use Case

You want to start with a name , and just like with a business process, you want that name to be verb-noun. So, “Purchase Course,” “Subscribe to Free Training,” not just “The Free Training Use Case.”

You want to know: what is the action that user is taking that’s going to be described in the use case?   

Writing a Brief Description for a Use Case

Next is a brief description , and one of the things I really like to include in my brief description is a sentence that really gets clear about the scope. “This use case starts when…” and “This use case ends when…” because what happens when you start to write all those steps is you find all these variations.

Then, all of a sudden, your use case is all over the place, and you’re like, “Laura, this isn’t a sequence of steps. It’s a web.” It’s usually because you’re going off track, or exploring alternates in too much detail, or really are just not staying within the scope of the steps that need to happen for the specific goal of that use case.

Get clear on your: Starts when / Ends when.

Define Use Case Actors

The actors : who are the users, or the roles, or the types of actors that might use the system? It’s not job title; it’s actor.

Multiple people can fill that role with the system. It’s what the system can identify about you.

Are you a purchaser?

Are you an administrator?

Are you a reporter?

Something like that.  

Define Preconditions

Preconditions : what must be true before the use case starts?

This, again, is a very system-level. What can the system know to be true before the use case starts?

Write the Basic Flow of the Use Case

Then, you get into the Basic Flow , and I like to think of the basic flow like ping pong.   The user does one thing, the system does another thing. The user does one thing, the system does another thing. “Ping pong, ping pong.” It’s not always that clear-cut. Sometimes it’s like, “Ping, ping, pong, pong, pong. Ping pong.” It doesn’t have to be just one back-and-forth like that, but thinking about it as ping pong really helps make sure that you’re getting that user-system interaction.

What we see very commonly among our business analysis course participants is that those with more of a business background are like, “Ping, ping, ping. User, user, user, user, user, user.” System does one thing. Really, the system is doing things all along, they’re just not seeing it because they’re not used to looking for what the system does to support them, and because they’re the business user, they’re thinking about all the things that are happening in the business. So, they’re not seeing.

That’s part of the way that the use case is such a powerful tool. It really dials you into, as a businessperson, what the system is doing to support you and what those requirements actually are of the system that you might not see otherwise. It becomes very important when you’re just like the, “Ping, ping, ping, ping. User, user, user, user.”  

On the flip side, a more technical person will often say, “The user does one thing in a ‘Boom, boom, boom, boom.’” It’s like, “Pong, pong, pong, pong, pong.” It’s all the technical details of what the system is doing, which is way more depth than what the business actually cares about because you just lose them with “text” speak of, “Oh, the system executes this sort of procedure, and updates this data, and sends this to this API, and updates the web form,” and all this technical detail. That’s not what goes into the use case.

Instead, explore data modeling techniques such as a data dictionary , system context diagram , and data map to be sure you have a full understanding of the data requirements.

The use case is not a technical specification. It’s not a system specification.

You want to the requirements, or what would go into a functional specification . This involves what’s the observable piece that the system, that the user can see the system doing and experience the system doing? Not how the system is doing all that. I realize there’s a lot of magic and juicy stuff that happens there; it doesn’t go in your use case. Ping pong. Sometimes, “Ping, ping, pong,” but not all one or all the other. Otherwise, you really have a different kind of document, not a use case.

Break out Alternate and Exception Flows in a Use Case

Then, alternate flows and exception flows . These are the variant paths. Sometimes—Let’s just see an example. For “Watch Video,” you might have “Pause.” You can pause the video. You can end the video (please don’t do that!). You can do different things. You can “Like” the video. You might have—Sometimes it might not fit within the scope of that use case but all the different things you can do. These are the alternate flows.

An exception flow might be: what happens if your Internet connection cuts out and the stream ends? How does that get presented to the user? Things that go wrong and keep people from, stopping reaching the end goal or the end of the use case.  

Finally, decide on Post Conditions

Post-conditions are what are true after the use case is over. If there’s any information that needs to be stored or outputs that need to be generated, those all need to have steps in your use case, and you can capture them as post-conditions, as well. Again, you don’t have to remember all of these details. Be sure to download our use case template, which will give you an annotated template, all these sections, a quick synopsis of what’s included. Again, that’s just one of the thirteen templates that we include in our Business Analyst Template Toolkit.  

Use Cases Do Not Require Technical Knowledge  

One thing I want to cover—and I’ve alluded to this as I described a use case, but we still get a lot of questions about it—is: doesn’t that use case require technical knowledge? “What do I do if I don’t know the tech? How do I communicate with developers, and how do I do things like requirements? It seems like I’ve got to know all this technology, and I have to know the business analysis.”

Really, you’ve got to think of the use case as a tool that allows you to communicate about what the technology needs to do without actually knowing how it’s built because you’re not doing all those “Pong, pong, pong, pongs.” You’re not seeing all of the different pieces of the tech that happen behind the scenes.

You’re saying, “As a user, what is my observable functionality? What do I see the system doing for me?” We should be able to be very clear about that as a business analyst. That’s part of the clarity we bring to the table.   

Use Cases Help You Ask Smart Questions

That’s why use cases are such a great tool; they help us ask really, really smart questions that uncover gaps in thinking and understanding and requirements.   

As an example, say we’re talking about “Purchase Course.” We have a step for the user choosing a course, a step for the system presenting the order form. Then, the user fills in the order form; the user submits the order form, the shopping cart checks credit card details. I’m probably missing a few things here, but you’re going to have this back-and-forth between the user and the system.

If you watched my business process video , you know that there’s a course participant registration that happens automatically. How does that actually happen? What’s the output that enables that to happen? Behind the scenes, there’s a—I don’t know the technical term—but there’s a data ping, likely specified by a data map , that’s sending that credit card information. That would be really important, the user information from one system to the other, so we can automate that setup and get people their course registration details as quickly as possible.  

As you detail out the use case to fulfill this business process, you would see the gap. Like, “Well, wait. We see this thing happening here. We have this thing happening here. We don’t actually know what the steps are to get from point A to point B. It’s not clear to me.” We’ve had people ask that question that are new to our business. “How does that actually happen?”

They’re using their use case thinking to think it through and to find the gap.

It’s way easier when you’re actually writing the use case and getting all to the steps to where the last step is that the user receives their course registration email. You’re like, “Wait a minute. That’s not coming from the shopping cart. Where does it come from, and how does it get there?” That’s the kind of step-by-step thinking that you want to be doing in your use cases and that you want to bring to the table. It really helps you understand the technology without having to build the technology.  

I hope that is both a tutorial on how to create a use case and a lesson in why they’re so fun and important, and why I love them so much, and how they are such a powerful analytical tool for you to be using to really get clear on the requirements to bridge the gap between your business and technology stakeholders, bring everyone truly on the same page about what the software needs to do using a communication tool and an analytical tool that helps you uncover gaps and communicate with people who are both technical and non-technical.  

Download Your Use Case Template Today

use case and analysis

Again, download that use case template here .

This will give you a great starting point to writing your first or next use case, and save you so much time gettings tarted. It even has instructional text to guide you ever step of the way.

As always, we build our profession one business analyst at a time. Success starts with you.   

Thank you for being here. Thank you for watching. I’m Laura Brandenburg from Bridging the Gap, and we’ll help you start your business analyst career. Happy modeling!  

Use Cases Are One Way to Analyze the Functional Requirements

Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation .

Use Cases vs. User Stories

Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.

Sign up for weekly updates and access to the FREE Quick Start to Success workshop:

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

Quick Start to Success as a Business Analyst

By signing up, you agree to our Privacy Policy .

System Analysis and Design, Fifth Edition by

Get full access to System Analysis and Design, Fifth Edition and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.



U se cases are used to explain and document the interaction that is required between the user and the system to accomplish the user's task. Use cases are created to help the development team understand more fully the steps that are involved in accomplishing the user's goals. Once created, use cases often can be used to derive more detailed functional requirements for the new system.

  • Explain the purpose of use cases in the analysis phase of the SDLC.
  • Describe the various parts of a use case and the purpose of each part.
  • Explain the process used to create a use case.
  • Describe how use cases contribute to the functional requirements.
  • Describe how use cases inform the development of test plans.



Elements of a Use Case

Alternative Use Case Formats Use Cases and the Functional Requirements

Use Cases and Testing Building Use Cases

Applying the Concepts at Tune Source

Identifying the Major Use Cases

Elaborating on the Use Cases


Chapter 3 discussed the overall process of the analysis phase of the SDLC, resulting in the system proposal deliverable. Within the system proposal is the requirements definition, defining exactly what the new system should do. As we previously discussed, a key aspect of determining the requirements for the new system is understanding the user requirements : the things ...

Get System Analysis and Design, Fifth Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Cover of Software Architecture Patterns

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

use case and analysis

  • Creative & Design
  • See all teams

For industries

  • Manufacturing
  • Professional Services
  • Consumer Goods
  • Financial Services
  • See all industries
  • Resource Management
  • Project Management
  • Workflow Management
  • Task Management
  • See all use cases

Explore Wrike

  • Book a Demo
  • Take a Product Tour
  • ROI Calculator
  • Customer Stories
  • Start with Templates
  • Gantt Charts
  • Custom Item Types
  • Project Resource Planning
  • Project Views
  • Kanban Boards
  • Dynamic Request Forms
  • Cross-Tagging
  • See all features
  • Integrations
  • Mobile & Desktop Apps
  • Resource Hub
  • Educational Guides

Upskill and Connect

  • Training & Certifications
  • Help Center
  • Wrike's Community
  • Premium Support Packages
  • Wrike Professional Services

What Is a Use Case?

April 25, 2022 - 7 min read

Nicky Daly

A use case is a concept used in software development, product design, and other fields to describe how a system can be used to achieve specific goals or tasks. It outlines the interactions between users or actors and the system to achieve a specific outcome.

In this article, we’ll dive into the details of what use cases are, how they are used in software development, and their benefits. We’ll also explore common types of use cases and provide some tips on how to create effective use cases.

Moreover, to help you effectively manage your project's use cases, we’ll offer a pre-built requirements management template that can help you gather all the necessary information and ensure all stakeholders are aligned on the project’s goals. 

What is a use case? Use cases explained 

A use case is a description of the ways in which a user interacts with a system or product. A use case may establish the success scenarios, the failure scenarios, and any critical variations or exceptions. A use case can be written or made visual with the help of a use case model tool. 

The history of the use case

Swedish computer scientist Ivar Jacobson presented the first article on use cases in 1987, describing how the technique was used at telecommunications company Ericsson to capture system requirements. In 1992, Jacobson co-authored the book "Object-Oriented Software Engineering — A Use Case Driven Approach," which helped popularize use cases for specifying functional requirements in software development.

Mobile image promo promo

Jacobson later joined American software engineers Grady Booch and James Rumbaugh to create the Unified Modeling Language (UML), which introduced a standard way to visualize the design of a system. Since then, the technique has been adapted into use case writing "templates" to streamline the capture of high-level requirements.

What is the purpose of a use case? 

The purpose of a use case is to:

  • Manage scope
  • Establish requirements 
  • Outline the ways a user will interact with the system 
  • Visualize system architecture
  • Communicate technical requirements to business stakeholders
  • Risk management

Why do project managers need to know about use cases?

Project managers need to know about use cases because they help communicate strategy to stakeholders and bridge the gap between business justification and technical requirements.

PMI also notes that “use cases provide a structure for gathering customer requirements and setting the project scope.” But what does that mean in practical terms? 

Let’s say that you are a project manager for an education tech firm. Your company’s latest product idea is an app for students where they can receive live tuition for a monthly subscription fee. Creating a use case for this application can tell stakeholders and the project team who the customer is, how the customer will interact with the product, and what the scope gap meaning and requirements of the project will be. 

How to write a use case for a project

When presented in written form, a use case can be a helpful piece of project documentation. Use cases are a common requirements artifact , and they can smoothen communication across technical and business stakeholders. 

Depending on the intended audience and system under discussion, the use case can be as detailed or basic as needed. A use case document should establish and identify a few key components — these are: 

  • System : A system is the product, service, or software under discussion.  
  • Actors : An actor is a user or anything else that exhibits behavior when interacting with the system. The actor could be another system, a piece of hardware, or an entire organization. There are four types of actors: a system under discussion, an internal actor, a primary actor, and a secondary actor. The most commonly referred to are the latter two systems. A primary actor initiates the interaction with the system, while a secondary actor may provide a service to the system.
  • Scenario : In “Applying UML and Patterns,” Larman notes that “a scenario is a specific sequence of actions and interactions between actors and the system under discussion; it is also called a use case instance.”
  • Use case : A use case outlines the success and failure scenarios that can occur when the actor(s) interact with the system. In this section, you’d establish the main success scenario, i.e., the most desirable outcome between the actor and the system. You would also establish the alternative paths, which explain what happens in the event of failure or error.

Let’s take a look at a simple use case example: 

  • Use case for meal delivery application : Individuals can use an app to place food orders directly to restaurants. When the user places an order, they are prompted to pay through the app or pay when the food arrives. Once that is confirmed, the restaurant will receive a request through their system. The food will then be prepared, packaged, and delivered to the individual. In this case, the app must be able to receive orders, process payments, and communicate with the restaurant electronically. 
  • System : Food delivery application 
  • Primary actor : Customer ordering a meal
  • Scenario : The user browses restaurant options. Once the preferred restaurant is selected, they place an order through the application. The user pays online or verifies they will pay in person. The order is sent from the app to the restaurant’s internal system. The restaurant worker receives and processes the electronic order. This use case illustrates how both the customer and restaurant employee (the actors) interact with the food delivery application (the system) and the expected outcome of each interaction. This helps sketch a framework for what is expected in the development stage. The app must be able to process payments, for example.

What is a use case model?

A use case model is a visual representation of the interactions between an actor and a system. As PMI also notes, use case models depict processes, which helps to further express preconditions and triggers.

A use case model is commonly expressed using UML (Universal Modeling Language). In these visualizations, there are three main components: the system, the actors, and the use case.

The system is represented by a rectangle or “boundary box." Actors are shown as stick people outside of the boundary box, while the use cases are presented as text in ovals within the box. Solid and dashed lines represent the association between the actors and the system’s use cases. 

Use case model example: 

What Is a Use Case? 2

(Source: Visual Paradigm Online )

What is the difference between a use case model and a use case diagram?

A use case diagram is simply a type of use case model. A use case model diagram uses text and shapes to represent the relationship between a user and a system. 

Primarily, use case model diagrams are used to: 

  • Visualize the flow and behavior of the system
  • Illustrate the functionality of the system
  • Represent key system-user interactions 

Depending on the system, a use case model diagram can vary in complexity, showing basic associations or expanding to show multiple exceptions. 

Utilizing use cases with Wrike

Utilizing use cases with Wrike can streamline your product development process and help ensure your software meets the needs of its users. 

With Wrike’s requirements management template , you can track all of your use case requirements in one place. When it’s time to plan and execute your project, Wrike’s project scheduling template can help you create a clear, actionable plan that keeps your team on track. Try Wrike today and see how easy it is to incorporate use cases into your product development process.

Nicky Daly

Nicky is a former Content Marketing Manager of Wrike.

Related articles

Wrike Recognized by TrustRadius for Industry-Leading Usability and Customer Service

Wrike Recognized by TrustRadius for Industry-Leading Usability and Customer Service

Wrike earns two awards from TrustRadius for its best-in-class usability and customer service. Find out how to get started with the world’s leading digital work hub.

A Quick Guide to Client Communication Skills

A Quick Guide to Client Communication Skills

Client communication skills are crucial for delivering impressive work and retaining your best clients. Here’s what you need to know to communicate effectively.

Why Emotional Intelligence Matters in the Workplace (Infographic)

Why Emotional Intelligence Matters in the Workplace (Infographic)

Strong emotional intelligence in the workplace is essential for project and team success. Learn more about improving emotional intelligence as a leader.

Get weekly updates in your inbox!

Get weekly updates in your inbox!

You are now subscribed to wrike news and updates.

Let us know what marketing emails you are interested in by updating your email preferences here .

Sorry, this content is unavailable due to your privacy settings. To view this content, click the “Cookie Preferences” button and accept Advertising Cookies there.

In order to continue enjoying our site, we ask that you confirm your identity as a human. Thank you very much for your cooperation.

Breaking News



Justices rule trump has some immunity from prosecution.

use case and analysis

This article was updated on July 1 at 3:32 p.m.

In a historic decision, a divided Supreme Court on Monday ruled that former presidents can never be prosecuted for actions relating to the core powers of their office, and that there is at least a presumption that they have immunity for their official acts more broadly.

The decision left open the possibility that the charges brought against former President Donald Trump by Special Counsel Jack Smith – alleging that Trump conspired to overturn the results of the 2020 election – can still go forward to the extent that the charges are based on his private conduct, rather than his official acts.

The case now returns to the lower courts for them to determine whether the conduct at the center of the charges against Trump was official or unofficial – an inquiry that, even if it leads to the conclusion that the charges can proceed, will almost certainly further delay any trial in the case, which had originally been scheduled to begin on March 4, 2024 but is currently on hold.

Writing for the majority, Chief Justice John Roberts emphasized that the president “is not above the law.” But Justice Sonia Sotomayor, in a dissent joined by Justices Elena Kagan and Ketanji Brown Jackson, countered that if a future president “misuses official power for personal gain, the criminal law that the rest of us must abide will not provide a backstop.”

The decision was the latest chapter in a case that began last year, when Trump was indicted on four counts arising from Smith’s investigation into the Jan. 6, 2021, attacks on the U.S. Capitol. The indictment contended that Trump created “widespread mistrust … through pervasive and destabilizing lies about election fraud” and then conspired to undermine “a bedrock function of the United States federal government: the nation’s process of collecting, counting, and certifying the results of the presidential election.”

Trump asked Chutkan to throw out the charges against him, arguing that he is immune from prosecution because he was the president. Chutkan turned that request down in early December, explaining that the presidency does not “confer a lifelong ‘get-out-of-jail-free’ pass.”

Smith went to the Supreme Court later that month, asking the justices to weigh in on Trump’s immunity without waiting for the U.S. Court of Appeals for the District of Columbia Circuit to rule on Trump’s appeal. But the justices declined to do so, and it was six weeks – Feb. 6, 2024 – before the court of appeals issued its opinion rejecting Trump’s claim to immunity.

Trump then came to the Supreme Court, seeking review of the D.C. Circuit’s ruling. Two weeks later, the justices agreed to take up his case. They scheduled the argument for late April – putting the case on a faster track than it normally would have been, but a slower schedule than they had established for another case involving Trump , the challenge to Colorado’s disqualification of the former president from its ballot for his role in the Jan. 6, 2021, attacks. That case was set for argument just over one month after the court announced that it would review the case in January, and the court issued its decision for Trump just under one month after the oral argument.

In a ruling on the last day before the Supreme Court’s summer recess, and just over two months after the oral argument, a majority of the court rejected the D.C. Circuit’s reasoning. As an initial matter, Roberts explained in his 43-page ruling, presidents have absolute immunity for their official acts when those acts relate to the core powers granted to them by the Constitution – for example, the power to issue pardons, veto legislation, recognize ambassadors, and make appointments.

But when it comes to the president’s other official acts, Roberts continued, there is on one hand the concern that allowing criminal charges against a former president for his official acts would affect his decision-making while in office. “A President inclined to take one course of action based on the public interest may instead opt for another, apprehensive that criminal penalties may befall him upon his departure from office,” Roberts posited. On the other hand, Roberts noted, the public has an interest in “fair and effective” enforcement of criminal laws. Weighing those two sets of interests, Roberts concluded, a president should have immunity from criminal prosecution for his official – but not his unofficial – acts unless, at the very least, prosecutors can show that bringing such charges would not threaten the power and functioning of the executive branch.

Determining which acts are official and which are unofficial “can be difficult,” Roberts conceded. He emphasized that the immunity that the court recognizes in its ruling on Monday takes a broad view of what constitutes a president’s “official responsibilities,” “covering actions so long as they are not manifestly or palpably beyond his authority.” In conducting the official/unofficial inquiry, Roberts added, courts cannot consider the president’s motives, nor can they designate an act as unofficial simply because it allegedly violates the law.

Turning to some of the specific allegations against Trump, the majority ruled that Trump cannot be prosecuted for his alleged efforts to “leverage the Justice Department’s power and authority to convince certain States to replace their legitimate electors with Trump’s fraudulent slates of electors.”

With regard to the allegation that Trump attempted to pressure his former vice president, Mike Pence, in his role as president of the senate, to reject the states’ electoral votes or send them back to state legislatures, the court deemed Trump “presumptively immune” from prosecution on the theory that the president and vice president are acting officially when they discuss their official responsibilities. On the other hand, Roberts observed, the vice president’s role as president of the senate is not an executive branch role. The court therefore left it for the district court to decide whether prosecuting Trump for this conduct would intrude on the power and operation of the executive branch.

The court did the same for the allegations in the indictment regarding Trump’s interactions with private individuals and state officials, attempting to convince them to change electoral votes in his favor, as well as Trump’s tweets leading up to the Jan. 6 attacks and his speech on the Ellipse that day. Making this determination, Roberts wrote, will require “a close analysis of the indictment’s extensive and interrelated allegations.”

Roberts rejected the government’s contention that, even if Trump has immunity for his official acts, prosecutors can still use evidence about those official acts to make their case to a jury – for example, to prove that Trump knew that his election-fraud claims were false. “That proposal,” Roberts stressed, “threatens to eviscerate the immunity we have recognized. It would permit a prosecutor to do indirectly hat he cannot do directly — invite the jury to examine acts for which a President is immune from prosecution to nonetheless prove his liability on any charge.”

Roberts pushed back against the dissent by Sotomayor and a separate one by Justice Ketanji Brown Jackson, describing them as striking “a chilling tone of doom that is wholly disproportionate to what the Court actually does today.” He portrayed the ruling as a relatively narrow one that decides only “that immunity extends to official discussions between the President and his Attorney General, and then remand to the lower courts” for them to determine whether the other acts alleged in the indictment are entitled to immunity.

Roberts also sought to downplay the political significance of the court’s ruling. He emphasized that although most people are focused on this case because of its potential impact on the charges against Trump, the Supreme Court “cannot afford to fixate exclusively, or even primarily, on present exigencies.” “Our perspective,” he wrote, “ must be more farsighted.”

Justice Clarence Thomas agreed with the majority’s immunity ruling but wrote a separate concurring opinion in which he questioned the constitutionality of Jack Smith’s appointment as special counsel. He observed that “[n]o former President has faced criminal prosecution for his acts while in office in the more than 200 years since the founding of our country,” “despite numerous past Presidents taking actions that many would argue constitute crimes.” “If this unprecedented prosecution is to proceed,” Thomas contended, “it must be conducted by someone duly authorized to do so by the American people. The lower courts should thus answer these essential questions concerning the Special Counsel’s appointment before proceeding.”

U.S. District Judge Aileen Cannon, who is overseeing the case brought by Smith in Florida alleging that Trump illegally kept classified documents after leaving office, heard oral arguments on that question last month.

In her own separate concurrence, Justice Amy Coney Barrett agreed with the majority “that the Constitution prohibits Congress from criminalizing a President’s exercise” of his core constitutional powers and “closely related conduct.” But she would have courts approach the question of immunity for other official acts differently, by focusing first on whether the criminal law under which a former president is charged applies to his official acts and, if so, whether prosecuting the former president would interfere with his constitutional authority.

Applying that principle to the facts of this case, she suggested that at least some of the conduct that serves as the basis for the charges against Trump – such as his request that the speaker of the Arizona House of Representatives hold a special session about election fraud claims – would not be immune. “The President,” she concluded, “has no authority over state legislatures or their leadership, so it is hard to see how prosecuting him for crimes committed when dealing with the Arizona House Speaker would unconstitutionally intrude on executive power.”

Barrett also disagreed with her colleagues in the majority on whether prosecutors can use evidence of a president’s official acts. “The Constitution,” she wrote, “does not require blinding juries to the circumstances surrounding conduct for which Presidents can be held liable.” She acknowledged the majority’s concern that the use of such evidence could influence the jury, but she insisted that federal evidentiary rules and the trial courts can address those concerns on a case-by-case basis.

In her dissent, which (like Jackson’s) notably did not use the traditional “respectfully,” Sotomayor contended that Monday’s ruling “reshapes the institution of the Presidency.” “Whether described as presumptive or absolute,” she wrote, “under the majority’s rule, a President’s use of any official power for any purpose, even the most corrupt, is immune from prosecution. That is just as bad as it sounds, and it is baseless.” “With fear for our democracy,” she concluded, “I dissent.”

Nothing in the text of the Constitution or the history of the United States supports the kind of immunity that the majority found in its opinion, Sotomayor maintained. To the contrary, she noted, the drafters of the Constitution did carve out a narrow immunity for members of Congress, and some state constitutions at the time did explicitly create criminal immunity for governors – but the drafters did not include any such provision for the president.

Indeed, Sotomayor added, the drafters of the Constitution suggested that the president could face criminal prosecution, by indicating in the provision addressing impeachment that a president can be subject to prosecution even after impeachment.

Sotomayor contended that the majority’s decision might sweep more broadly than her colleagues acknowledged. First, she argued that the line that Roberts drew between official and unofficial conduct “narrows the conduct considered ‘unofficial’ almost to a nullity. It says that whenever the President acts in a way that is not manifestly or palpably beyond his authority, he is taking official action.” And the majority takes an “expansive view” of the core powers of the presidency, she continued, that “will effectively insulate all sorts of noncore conduct from criminal prosecution.” “In every use of official power,” she concluded, “the President is now a king above the law.”

In her own separate dissent, Jackson complained that Monday’s ruling “has unilaterally altered the balance of power between” the three branches of government, giving more power to the courts and the executive branch at Congress’s expense. And it “undermines the constraints of the law as a deterrent for future Presidents who might otherwise abuse their power.” She characterized the “practical consequences” of the ruling as “a five-alarm fire that threatens to consume democratic self-governance and the normal operations of our Government.”

This article was originally published at Howe on the Court . 

Posted in Featured , Merits Cases

Cases: Trump v. United States

Recommended Citation: Amy Howe, Justices rule Trump has some immunity from prosecution , SCOTUSblog (Jul. 1, 2024, 12:26 PM),

Privacy Overview


Here’s What the Court’s Chevron Ruling Could Mean in Everyday Terms

The decision is expected to prompt a rush of litigation challenging regulations across the entire federal government, from food safety to the environment.

  • Share full article

Gray columns and a white flag on the front of a the Environmental Protection Agency building.

By Coral Davenport ,  Christina Jewett ,  Alan Rappeport ,  Margot Sanger-Katz ,  Noam Scheiber and Noah Weiland

  • June 28, 2024

The Supreme Court’s decision on Friday to limit the broad regulatory authority of federal agencies could lead to the elimination or weakening of thousands of rules on the environment, health care, worker protection, food and drug safety, telecommunications, the financial sector and more.

The decision is a major victory in a decades-long campaign by conservative activists to shrink the power of the federal government, limiting the reach and authority of what those activists call “the administrative state.”

The court’s opinion could make it easier for opponents of federal regulations to challenge them in court, prompting a rush of new litigation, while also injecting uncertainty into businesses and industries.

“If Americans are worried about their drinking water, their health, their retirement account, discrimination on the job, if they fly on a plane, drive a car, if they go outside and breathe the air — all of these day-to-day activities are run through a massive universe of federal agency regulations,” said Lisa Heinzerling, an expert in administrative law at Georgetown University. “And this decision now means that more of those regulations could be struck down by the courts.”

The decision effectively ends a legal precedent known as “Chevron deference,” after a 1984 Supreme Court ruling. That decision held that when Congress passes a law that lacks specificity, courts must give wide leeway to decisions made by the federal agencies charged with implementing that law. The theory was that scientists, economists and other specialists at the agencies have more expertise than judges in determining regulations and that the executive branch is also more accountable to voters.

Since then, thousands of legal decisions have relied on the Chevron doctrine when challenges have been made to regulations stemming from laws like the 1938 Fair Labor Standards Act, the 1970 Clean Air Act , the 2010 Affordable Care Act and others.

We are having trouble retrieving the article content.

Please enable JavaScript in your browser settings.

Thank you for your patience while we verify access. If you are in Reader mode please exit and  log into  your Times account, or  subscribe  for all of The Times.

Thank you for your patience while we verify access.

Already a subscriber?  Log in .

Want all of The Times?  Subscribe .

Human Subjects Office

Medical terms in lay language.

Please use these descriptions in place of medical jargon in consent documents, recruitment materials and other study documents. Note: These terms are not the only acceptable plain language alternatives for these vocabulary words.

This glossary of terms is derived from a list copyrighted by the University of Kentucky, Office of Research Integrity (1990).

For clinical research-specific definitions, see also the Clinical Research Glossary developed by the Multi-Regional Clinical Trials (MRCT) Center of Brigham and Women’s Hospital and Harvard  and the Clinical Data Interchange Standards Consortium (CDISC) .

Alternative Lay Language for Medical Terms for use in Informed Consent Documents

A   B   C   D   E   F   G   H   I  J  K   L   M   N   O   P   Q   R   S   T   U   V   W  X  Y  Z

ABDOMEN/ABDOMINAL body cavity below diaphragm that contains stomach, intestines, liver and other organs ABSORB take up fluids, take in ACIDOSIS condition when blood contains more acid than normal ACUITY clearness, keenness, esp. of vision and airways ACUTE new, recent, sudden, urgent ADENOPATHY swollen lymph nodes (glands) ADJUVANT helpful, assisting, aiding, supportive ADJUVANT TREATMENT added treatment (usually to a standard treatment) ANTIBIOTIC drug that kills bacteria and other germs ANTIMICROBIAL drug that kills bacteria and other germs ANTIRETROVIRAL drug that works against the growth of certain viruses ADVERSE EFFECT side effect, bad reaction, unwanted response ALLERGIC REACTION rash, hives, swelling, trouble breathing AMBULATE/AMBULATION/AMBULATORY walk, able to walk ANAPHYLAXIS serious, potentially life-threatening allergic reaction ANEMIA decreased red blood cells; low red cell blood count ANESTHETIC a drug or agent used to decrease the feeling of pain, or eliminate the feeling of pain by putting you to sleep ANGINA pain resulting from not enough blood flowing to the heart ANGINA PECTORIS pain resulting from not enough blood flowing to the heart ANOREXIA disorder in which person will not eat; lack of appetite ANTECUBITAL related to the inner side of the forearm ANTIBODY protein made in the body in response to foreign substance ANTICONVULSANT drug used to prevent seizures ANTILIPEMIC a drug that lowers fat levels in the blood ANTITUSSIVE a drug used to relieve coughing ARRHYTHMIA abnormal heartbeat; any change from the normal heartbeat ASPIRATION fluid entering the lungs, such as after vomiting ASSAY lab test ASSESS to learn about, measure, evaluate, look at ASTHMA lung disease associated with tightening of air passages, making breathing difficult ASYMPTOMATIC without symptoms AXILLA armpit

BENIGN not malignant, without serious consequences BID twice a day BINDING/BOUND carried by, to make stick together, transported BIOAVAILABILITY the extent to which a drug or other substance becomes available to the body BLOOD PROFILE series of blood tests BOLUS a large amount given all at once BONE MASS the amount of calcium and other minerals in a given amount of bone BRADYARRHYTHMIAS slow, irregular heartbeats BRADYCARDIA slow heartbeat BRONCHOSPASM breathing distress caused by narrowing of the airways

CARCINOGENIC cancer-causing CARCINOMA type of cancer CARDIAC related to the heart CARDIOVERSION return to normal heartbeat by electric shock CATHETER a tube for withdrawing or giving fluids CATHETER a tube placed near the spinal cord and used for anesthesia (indwelling epidural) during surgery CENTRAL NERVOUS SYSTEM (CNS) brain and spinal cord CEREBRAL TRAUMA damage to the brain CESSATION stopping CHD coronary heart disease CHEMOTHERAPY treatment of disease, usually cancer, by chemical agents CHRONIC continuing for a long time, ongoing CLINICAL pertaining to medical care CLINICAL TRIAL an experiment involving human subjects COMA unconscious state COMPLETE RESPONSE total disappearance of disease CONGENITAL present before birth CONJUNCTIVITIS redness and irritation of the thin membrane that covers the eye CONSOLIDATION PHASE treatment phase intended to make a remission permanent (follows induction phase) CONTROLLED TRIAL research study in which the experimental treatment or procedure is compared to a standard (control) treatment or procedure COOPERATIVE GROUP association of multiple institutions to perform clinical trials CORONARY related to the blood vessels that supply the heart, or to the heart itself CT SCAN (CAT) computerized series of x-rays (computerized tomography) CULTURE test for infection, or for organisms that could cause infection CUMULATIVE added together from the beginning CUTANEOUS relating to the skin CVA stroke (cerebrovascular accident)

DERMATOLOGIC pertaining to the skin DIASTOLIC lower number in a blood pressure reading DISTAL toward the end, away from the center of the body DIURETIC "water pill" or drug that causes increase in urination DOPPLER device using sound waves to diagnose or test DOUBLE BLIND study in which neither investigators nor subjects know what drug or treatment the subject is receiving DYSFUNCTION state of improper function DYSPLASIA abnormal cells

ECHOCARDIOGRAM sound wave test of the heart EDEMA excess fluid collecting in tissue EEG electric brain wave tracing (electroencephalogram) EFFICACY effectiveness ELECTROCARDIOGRAM electrical tracing of the heartbeat (ECG or EKG) ELECTROLYTE IMBALANCE an imbalance of minerals in the blood EMESIS vomiting EMPIRIC based on experience ENDOSCOPIC EXAMINATION viewing an  internal part of the body with a lighted tube  ENTERAL by way of the intestines EPIDURAL outside the spinal cord ERADICATE get rid of (such as disease) Page 2 of 7 EVALUATED, ASSESSED examined for a medical condition EXPEDITED REVIEW rapid review of a protocol by the IRB Chair without full committee approval, permitted with certain low-risk research studies EXTERNAL outside the body EXTRAVASATE to leak outside of a planned area, such as out of a blood vessel

FDA U.S. Food and Drug Administration, the branch of federal government that approves new drugs FIBROUS having many fibers, such as scar tissue FIBRILLATION irregular beat of the heart or other muscle

GENERAL ANESTHESIA pain prevention by giving drugs to cause loss of consciousness, as during surgery GESTATIONAL pertaining to pregnancy

HEMATOCRIT amount of red blood cells in the blood HEMATOMA a bruise, a black and blue mark HEMODYNAMIC MEASURING blood flow HEMOLYSIS breakdown in red blood cells HEPARIN LOCK needle placed in the arm with blood thinner to keep the blood from clotting HEPATOMA cancer or tumor of the liver HERITABLE DISEASE can be transmitted to one’s offspring, resulting in damage to future children HISTOPATHOLOGIC pertaining to the disease status of body tissues or cells HOLTER MONITOR a portable machine for recording heart beats HYPERCALCEMIA high blood calcium level HYPERKALEMIA high blood potassium level HYPERNATREMIA high blood sodium level HYPERTENSION high blood pressure HYPOCALCEMIA low blood calcium level HYPOKALEMIA low blood potassium level HYPONATREMIA low blood sodium level HYPOTENSION low blood pressure HYPOXEMIA a decrease of oxygen in the blood HYPOXIA a decrease of oxygen reaching body tissues HYSTERECTOMY surgical removal of the uterus, ovaries (female sex glands), or both uterus and ovaries

IATROGENIC caused by a physician or by treatment IDE investigational device exemption, the license to test an unapproved new medical device IDIOPATHIC of unknown cause IMMUNITY defense against, protection from IMMUNOGLOBIN a protein that makes antibodies IMMUNOSUPPRESSIVE drug which works against the body's immune (protective) response, often used in transplantation and diseases caused by immune system malfunction IMMUNOTHERAPY giving of drugs to help the body's immune (protective) system; usually used to destroy cancer cells IMPAIRED FUNCTION abnormal function IMPLANTED placed in the body IND investigational new drug, the license to test an unapproved new drug INDUCTION PHASE beginning phase or stage of a treatment INDURATION hardening INDWELLING remaining in a given location, such as a catheter INFARCT death of tissue due to lack of blood supply INFECTIOUS DISEASE transmitted from one person to the next INFLAMMATION swelling that is generally painful, red, and warm INFUSION slow injection of a substance into the body, usually into the blood by means of a catheter INGESTION eating; taking by mouth INTERFERON drug which acts against viruses; antiviral agent INTERMITTENT occurring (regularly or irregularly) between two time points; repeatedly stopping, then starting again INTERNAL within the body INTERIOR inside of the body INTRAMUSCULAR into the muscle; within the muscle INTRAPERITONEAL into the abdominal cavity INTRATHECAL into the spinal fluid INTRAVENOUS (IV) through the vein INTRAVESICAL in the bladder INTUBATE the placement of a tube into the airway INVASIVE PROCEDURE puncturing, opening, or cutting the skin INVESTIGATIONAL NEW DRUG (IND) a new drug that has not been approved by the FDA INVESTIGATIONAL METHOD a treatment method which has not been proven to be beneficial or has not been accepted as standard care ISCHEMIA decreased oxygen in a tissue (usually because of decreased blood flow)

LAPAROTOMY surgical procedure in which an incision is made in the abdominal wall to enable a doctor to look at the organs inside LESION wound or injury; a diseased patch of skin LETHARGY sleepiness, tiredness LEUKOPENIA low white blood cell count LIPID fat LIPID CONTENT fat content in the blood LIPID PROFILE (PANEL) fat and cholesterol levels in the blood LOCAL ANESTHESIA creation of insensitivity to pain in a small, local area of the body, usually by injection of numbing drugs LOCALIZED restricted to one area, limited to one area LUMEN the cavity of an organ or tube (e.g., blood vessel) LYMPHANGIOGRAPHY an x-ray of the lymph nodes or tissues after injecting dye into lymph vessels (e.g., in feet) LYMPHOCYTE a type of white blood cell important in immunity (protection) against infection LYMPHOMA a cancer of the lymph nodes (or tissues)

MALAISE a vague feeling of bodily discomfort, feeling badly MALFUNCTION condition in which something is not functioning properly MALIGNANCY cancer or other progressively enlarging and spreading tumor, usually fatal if not successfully treated MEDULLABLASTOMA a type of brain tumor MEGALOBLASTOSIS change in red blood cells METABOLIZE process of breaking down substances in the cells to obtain energy METASTASIS spread of cancer cells from one part of the body to another METRONIDAZOLE drug used to treat infections caused by parasites (invading organisms that take up living in the body) or other causes of anaerobic infection (not requiring oxygen to survive) MI myocardial infarction, heart attack MINIMAL slight MINIMIZE reduce as much as possible Page 4 of 7 MONITOR check on; keep track of; watch carefully MOBILITY ease of movement MORBIDITY undesired result or complication MORTALITY death MOTILITY the ability to move MRI magnetic resonance imaging, diagnostic pictures of the inside of the body, created using magnetic rather than x-ray energy MUCOSA, MUCOUS MEMBRANE moist lining of digestive, respiratory, reproductive, and urinary tracts MYALGIA muscle aches MYOCARDIAL pertaining to the heart muscle MYOCARDIAL INFARCTION heart attack

NASOGASTRIC TUBE placed in the nose, reaching to the stomach NCI the National Cancer Institute NECROSIS death of tissue NEOPLASIA/NEOPLASM tumor, may be benign or malignant NEUROBLASTOMA a cancer of nerve tissue NEUROLOGICAL pertaining to the nervous system NEUTROPENIA decrease in the main part of the white blood cells NIH the National Institutes of Health NONINVASIVE not breaking, cutting, or entering the skin NOSOCOMIAL acquired in the hospital

OCCLUSION closing; blockage; obstruction ONCOLOGY the study of tumors or cancer OPHTHALMIC pertaining to the eye OPTIMAL best, most favorable or desirable ORAL ADMINISTRATION by mouth ORTHOPEDIC pertaining to the bones OSTEOPETROSIS rare bone disorder characterized by dense bone OSTEOPOROSIS softening of the bones OVARIES female sex glands

PARENTERAL given by injection PATENCY condition of being open PATHOGENESIS development of a disease or unhealthy condition PERCUTANEOUS through the skin PERIPHERAL not central PER OS (PO) by mouth PHARMACOKINETICS the study of the way the body absorbs, distributes, and gets rid of a drug PHASE I first phase of study of a new drug in humans to determine action, safety, and proper dosing PHASE II second phase of study of a new drug in humans, intended to gather information about safety and effectiveness of the drug for certain uses PHASE III large-scale studies to confirm and expand information on safety and effectiveness of new drug for certain uses, and to study common side effects PHASE IV studies done after the drug is approved by the FDA, especially to compare it to standard care or to try it for new uses PHLEBITIS irritation or inflammation of the vein PLACEBO an inactive substance; a pill/liquid that contains no medicine PLACEBO EFFECT improvement seen with giving subjects a placebo, though it contains no active drug/treatment PLATELETS small particles in the blood that help with clotting POTENTIAL possible POTENTIATE increase or multiply the effect of a drug or toxin (poison) by giving another drug or toxin at the same time (sometimes an unintentional result) POTENTIATOR an agent that helps another agent work better PRENATAL before birth PROPHYLAXIS a drug given to prevent disease or infection PER OS (PO) by mouth PRN as needed PROGNOSIS outlook, probable outcomes PRONE lying on the stomach PROSPECTIVE STUDY following patients forward in time PROSTHESIS artificial part, most often limbs, such as arms or legs PROTOCOL plan of study PROXIMAL closer to the center of the body, away from the end PULMONARY pertaining to the lungs

QD every day; daily QID four times a day

RADIATION THERAPY x-ray or cobalt treatment RANDOM by chance (like the flip of a coin) RANDOMIZATION chance selection RBC red blood cell RECOMBINANT formation of new combinations of genes RECONSTITUTION putting back together the original parts or elements RECUR happen again REFRACTORY not responding to treatment REGENERATION re-growth of a structure or of lost tissue REGIMEN pattern of giving treatment RELAPSE the return of a disease REMISSION disappearance of evidence of cancer or other disease RENAL pertaining to the kidneys REPLICABLE possible to duplicate RESECT remove or cut out surgically RETROSPECTIVE STUDY looking back over past experience

SARCOMA a type of cancer SEDATIVE a drug to calm or make less anxious SEMINOMA a type of testicular cancer (found in the male sex glands) SEQUENTIALLY in a row, in order SOMNOLENCE sleepiness SPIROMETER an instrument to measure the amount of air taken into and exhaled from the lungs STAGING an evaluation of the extent of the disease STANDARD OF CARE a treatment plan that the majority of the medical community would accept as appropriate STENOSIS narrowing of a duct, tube, or one of the blood vessels in the heart STOMATITIS mouth sores, inflammation of the mouth STRATIFY arrange in groups for analysis of results (e.g., stratify by age, sex, etc.) STUPOR stunned state in which it is difficult to get a response or the attention of the subject SUBCLAVIAN under the collarbone SUBCUTANEOUS under the skin SUPINE lying on the back SUPPORTIVE CARE general medical care aimed at symptoms, not intended to improve or cure underlying disease SYMPTOMATIC having symptoms SYNDROME a condition characterized by a set of symptoms SYSTOLIC top number in blood pressure; pressure during active contraction of the heart

TERATOGENIC capable of causing malformations in a fetus (developing baby still inside the mother’s body) TESTES/TESTICLES male sex glands THROMBOSIS clotting THROMBUS blood clot TID three times a day TITRATION a method for deciding on the strength of a drug or solution; gradually increasing the dose T-LYMPHOCYTES type of white blood cells TOPICAL on the surface TOPICAL ANESTHETIC applied to a certain area of the skin and reducing pain only in the area to which applied TOXICITY side effects or undesirable effects of a drug or treatment TRANSDERMAL through the skin TRANSIENTLY temporarily TRAUMA injury; wound TREADMILL walking machine used to test heart function

UPTAKE absorbing and taking in of a substance by living tissue

VALVULOPLASTY plastic repair of a valve, especially a heart valve VARICES enlarged veins VASOSPASM narrowing of the blood vessels VECTOR a carrier that can transmit disease-causing microorganisms (germs and viruses) VENIPUNCTURE needle stick, blood draw, entering the skin with a needle VERTICAL TRANSMISSION spread of disease

WBC white blood cell

Watch CBS News

Why the Supreme Court's decision overruling Chevron and limiting federal agencies is so significant

By Melissa Quinn

June 28, 2024 / 4:31 PM EDT / CBS News

Washington — In a blockbuster decision Friday, the Supreme Court overruled a 40-year-old decision that directed federal courts to defer to agencies' interpretation of unclear laws enacted by Congress.

The landmark ruling from the court, which divided 6-3 along ideological lines, curtails the regulatory power of federal agencies and is expected to restrict the government's ability to impose regulations on areas like the environment, health care and the workplace. 

The decision marks a major victory for the conservative legal movement, which has long called for dismantling the framework that arose out of the 1984 ruling in a case known as Chevron v. National Resources Defense Council.

The justices did just that with their ruling in a pair of cases involving a 2020 federal regulation that required owners of vessels in the Atlantic herring fishery to pay for monitors while they're at sea.

Here is why the decision in those two cases is so significant:

What is Chevron deference?

Members of the Supreme Court sit for a group photo on Friday, Oct 7, 2022, in Washington, D.C.

The concept of Chevron deference was borne out of the 1984 decision , which involved a challenge to a regulation enacted by the Environmental Protection Agency under the Clean Air Act that defined "stationary sources" of air pollution.

In that case from four decades ago, the Supreme Court used a two-step approach to uphold the EPA's definition. The first step was to decide whether Congress had directly spoken to the question at hand. If Congress' intent was clear, that marked the end of the analysis. But if not, and the statute was ambiguous as to the issue, the second step said courts should defer to the agency's interpretation of the statute if it is reasonable.

That two-step test was referred to as Chevron deference. In practice, it has given broad leeway to federal agencies and government regulators to interpret laws when there is some dispute over what the text of the statute means. Lower courts have applied Chevron in thousands of cases, and the Supreme Court itself has upheld an agency's reasonable interpretation of an ambiguous statute at least 70 times. But the high court has not applied Chevron doctrine since 2016.

What did the Supreme Court do?

The Supreme Court issued its ruling in two cases, Loper Bright Enterprises v. Raimondo and Relentless v. Department of Commerce, on Friday that explicitly overruled Chevron. Justice Ketanji Brown Jackson did not participate in the first case.

In its decision, the court held that a federal law known as the Administrative Procedure Act, or the APA, requires courts to exercise their own independent judgment when deciding whether an agency acted within its authority under the law. Courts, the majority found, should not defer to an agency's interpretation of a law just because it is unclear.

Writing for the majority, Roberts said Chevron was a "judicial invention that required judges to disregard their statutory duties." 

When a court considers whether an agency has acted within its authority, the chief justice wrote, the judgment of the executive branch may help inform its analysis. And when a law assigns authority to an agency within constitutional limits, courts have to respect that delegation, the Supreme Court found. 

But "courts need not and under the APA may not defer to an agency interpretation of the law simply because a statute is ambiguous," the majority concluded.

Acknowledging that lower courts have long applied Chevron, Roberts said jettisoning the doctrine does not call into question those earlier decisions. 

What will the ruling affect and why does it matter?

Supporters of Chevron deference have been sounding the alarm that a reversal of the 1984 ruling would hinder the ability of federal agencies to impose regulations that fill gaps in the laws passed by Congress. The Biden administration called Chevron a "bedrock principle of administrative law" that gave weight to the expertise of federal agencies and warned its reversal would create an "upheaval."

Already, legal scholars who disagree with the Supreme Court's decision to overturn Chevron have warned it concentrates power in the courts, leaving judges to make calls about policy that had previously been decided by experts who have deep experience in the subject area.

As Justice Elena Kagan put it in her dissenting opinion, "In one fell swoop, the majority today gives itself exclusive power over every open issue — no matter how expertise-driven or policy-laden — involving the meaning of regulatory law. As if it did not have enough on its plate, the majority turns itself into the country's administrative czar."

Joined by Justices Sonia Sotomayor and Jackson, Kagan said that by doing away with Chevron, courts will be at the center of the administrative process as to an array of subjects since there are always gaps in the law. 

Among those, Kagan wrote: "What actions can be taken to address climate change or other environmental challenges? What will the nation's health-care system look like in the coming decades? Or the financial or transportation systems? What rules are going to constrain the development of A.I.?"

What comes next?

Roberts wrote for the court that earlier decisions that relied on the Chevron framework will not be impacted by its reversal, but Kagan and the other two dissenters still said the ruling will be "disruptive" since it raises new doubts about agency actions that interpret statutes.

She warned that longstanding agency interpretations that had never challenged under Chevron may now be at the center of legal battles.

Some legal scholars are already bracing for a flood of litigation against agencies like the FDA and are warning that getting rid of Chevron deference will impact how government departments administer federal programs that serve broad swaths of the population.

Melissa Quinn is a politics reporter for She has written for outlets including the Washington Examiner, Daily Signal and Alexandria Times. Melissa covers U.S. politics, with a focus on the Supreme Court and federal courts.

More from CBS News

81-year-old Michigan woman rescued after being lost in woods for over 20 hours

Missing kayaker's body recovered from Lake Michigan

Helicopter crashes into Southeast Michigan farmer's field

Federal officials encourage Wayne County residents to review newly released flood maps


  1. [Use Case] What?, Why? & How?

    use case and analysis

  2. Use Case Diagram for Business Analysis

    use case and analysis

  3. Use Case Diagram Tutorial (Guide with Examples)

    use case and analysis

  4. PPT

    use case and analysis

  5. PPT

    use case and analysis

  6. UML Use Case Diagram Examples

    use case and analysis


  1. CH4 Use Case Analysis

  2. Session 3

  3. What are Use Cases

  4. First Open Call use case

  5. SQA Online

  6. 2.1. Use Case Analizinin Temelleri


  1. A Comprehensive Guide to Use Case Modeling

    An actor can be a person, another system, or a time event. A use case is a set of scenarios that describe how the system and the actor collaborate to achieve a common goal1. A scenario is a sequence of steps that describe what happens in a specific situation1. Actors in Use Case Modeling: Actors are represented by stick figures in a Use Case ...

  2. Use-case analysis

    A use case analysis is the primary form for gathering usage requirements for a new software program or task to be completed. The primary goals of a use case analysis are: designing a system from the user's perspective, communicating system behavior in the user's terms, and specifying all externally visible behaviors. ...

  3. Use Case Diagram Tutorial (Guide with Examples)

    Requirement analysis: Use case diagrams aid in understanding and documenting the functional requirements of a system by identifying actors and their interactions.; System design: Use case diagrams provide a high-level overview of system functionality, helping to define scope and design system components.; Communication with stakeholders: Use case diagrams facilitate discussions and ensure a ...

  4. What is a use case? How to write one, examples, + template

    A use case explains how users interact with a product or system. It outlines the flow of user inputs, establishing successful and failed paths to meeting goals. This allows product teams to better understand what a system does, how it performs, and why errors occur. You can write one out or diagram a use case model for visual thinkers.

  5. What is a use case? Definition, template, and how to write one

    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 leverage use case modeling tools — such as Miro, LucidChart, and SmartDraw, for some examples — to write or visually represent ...

  6. Use Case 101: Comprehensive Manual [With Steps to Write One ...

    Step 1: Come up with the title and description. Any use case study must have an engaging title. Keep it concise, specific, and indicative of the use case's purpose. For instance, the title Optimizing Online Checkout: A Use Case for E-Commerce Conversion Enhancement immediately conveys the focus and scope.

  7. Use Case Diagrams

    A Use Case Diagram is a vital tool in system design, it provides a visual representation of how users interact with a system. ... UML is linked with object-oriented design and analysis. UML makes use. 7 min read. State Machine Diagrams | Unified Modeling Language (UML) A State Machine Diagram is used to represent the condition of the system or ...

  8. What is the Use Case Diagram? Definition, Uses, Examples, and UML Use

    Use case diagrams serve several important purposes in the development and understanding of a system: Requirements Analysis: Use case diagrams are instrumental in capturing functional requirements by identifying the interactions between actors (users) and the system. They provide a high-level view of the system's functionality and help ...

  9. A Comprehensive Guide to Use Case Diagrams: Tips and Free Templates

    A Use Case Diagram is a graphical modeling tool in UML (Unified Modeling Language) used to depict the interactions between a system and its external entities. As a crucial tool for requirement analysis and system design, a Use Case Diagram helps team members understand the system's functional requirements and interaction processes, facilitating effective system design and development.

  10. Mastering the Art of Developing Use Case Diagrams and Scenarios

    Conclusion. Mastering the development of Use Case Diagrams and Scenarios is crucial for effective system analysis and software development. These tools not only provide a clear visual representation of system interactions but also help in anticipating and addressing various scenarios that users may encounter. As organizations continue to evolve ...

  11. Use Case Diagrams Online, Examples, and Tools

    A use case diagram is a dynamic or behavior diagram in UML. Use case diagrams model the functionality of a system using actors and use cases. Use cases are a set of actions, services, and functions that the system needs to perform. In this context, a "system" is something being developed or operated, such as a web site.

  12. What is Use Case Diagram?

    A UML use case diagram is the primary form of system/software requirements for a new software program underdeveloped. Use cases specify the expected behavior (what), and not the exact method of making it happen (how). Use cases once specified can be denoted both textual and visual representation (i.e. use case diagram).

  13. What is a Use Case?

    A use case is a methodology used in system analysis to identify, clarify and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. The method creates a document that describes all the steps taken by a user to ...

  14. UML Use Case Diagram Tutorial

    A use case diagram doesn't go into a lot of detail—for example, don't expect it to model the order in which steps are performed. Instead, a proper use case diagram depicts a high-level overview of the relationship between use cases, actors, and systems. Experts recommend that use case diagrams be used to supplement a more descriptive textual ...

  15. Use Cases and Scenarios

    Use cases and scenarios are powerful tools used in business analysis to define the functional requirements of a system or software. A use case describes how a user interacts with a system to achieve specific goals, while a scenario is an instance or sequence of events that illustrates how the system behaves in response to those user interactions.

  16. 10 Use Case Diagram Examples (and How to Create Them)

    Each action becomes a use case. Step 3: Create a goal for every use case. Identify what is required from the system to achieve these goals. Step 4: Structure the use cases. Include in the description for each use case the basic course of events that will happen when a user performs a certain action.

  17. Use Case

    uml. Use cases are a technique for organizing and eliciting requirements. They were originally popularized by Ivar Jacobson in the late 80's and early 90's. People commonly ask questions about use cases, most of which can be answered by Alistair Cockburn's book, which is by far the best book on use cases. You should read this book before using ...

  18. How to Write a Use Case: Template + Tutorial

    Break out Alternate and Exception Flows in a Use Case. Then, alternate flows and exception flows. These are the variant paths. Sometimes—Let's just see an example. For "Watch Video," you might have "Pause.". You can pause the video. You can end the video (please don't do that!). You can do different things.

  19. Use Cases: The Business Analyst's Best Friend

    I like use cases. There, I said it, and I'm not sorry. Use cases have fallen out of fashion in recent years, being largely replaced by user stories on agile projects. ... Use case analysis is a ...


    USE CASE ANALYSIS. U se cases are used to explain and document the interaction that is required between the user and the system to accomplish the user's task. Use cases are created to help the development team understand more fully the steps that are involved in accomplishing the user's goals. Once created, use cases often can be used to derive ...

  21. What Is a Use Case & How To Write One

    A use case is a concept used in software development, product design, and other fields to describe how a system can be used to achieve specific goals or tasks. It outlines the interactions between users or actors and the system to achieve a specific outcome. In this article, we'll dive into the details of what use cases are, how they are used ...

  22. Use Case Analysis: Tutorial & Examples

    The use case analysis attempts to convey information on the system requirements and usage, the role of the user, the system actions in response to the user, and what the user will receive from the ...

  23. Use case

    Use case analysis usually starts by drawing use case diagrams. For agile development, a requirement model of many UML diagrams depicting use cases plus some textual descriptions, notes, or use case briefs would be very lightweight and just enough for small or easy project use. As good complements to use case texts, the visual diagram ...

  24. Analysis: The Supreme Court just gave presidents a superpower. Here's

    With its immunity ruling on Monday, the Supreme Court granted former President Donald Trump's wish of all but guaranteeing that his criminal trial for trying to overturn the 2020 presidential ...

  25. Justices rule Trump has some immunity from prosecution

    OPINION ANALYSIS Justices rule Trump has some immunity from prosecution. By Amy Howe on Jul 1, 2024 at 12:26 pm. ... The case now returns to the lower courts for them to determine whether the conduct at the center of the charges against Trump was official or unofficial - an inquiry that, even if it leads to the conclusion that the charges can ...

  26. What the Chevron Ruling Means for the Federal Government

    Kristi Hamrick, a strategist for Students for Life of America, an anti-abortion organization, said in a statement that such a case was likely to get a better reception "when the F.D.A. is no ...

  27. Medical Terms in Lay Language

    Please use these descriptions in place of medical jargon in consent documents, recruitment materials and other study documents. Note: These terms are not the only acceptable plain language alternatives for these vocabulary words.This glossary of terms is derived from a list copyrighted by the

  28. Supreme Court strikes serious blow against the administrative state

    In a potentially groundbreaking decision, the Supreme Court on Thursday ruled that defendants accused of fraud by the Securities and Exchange Commission have the right to a jury trial.. Why it matters: The decision in SEC v.Jarkesy deals a serious blow to the administrative state, part of a yearslong project by the financial sector and conservatives to weaken federal power.

  29. Why the Supreme Court's decision overruling Chevron and limiting

    Lower courts have applied Chevron in thousands of cases, and the Supreme Court itself has upheld an agency's reasonable interpretation of an ambiguous statute at least 70 times. But the high court ...