business process model vs use case

What Comes Before The Use Case Model? | Business Use Cases Can Help

This article puts use cases into context by exploring where they sit within a project. Various methods for validating them within the wider context are also discussed.

It also discusses what other techniques can or should be used in conjunction with them (and what comes before the use case model). Such as

Business case vs use case;
Business use cases vs use case;
Business process vs use case.

What comes before use cases .

Use cases are rarely the starting point for any project when it is first being conceived. Initially, the business sponsor is thinking about business benefits, costs savings or creating competitive advantage. They will be starting to formulate a business case whether formally or informally.

This should always be the case whether it is done on a very informal basis in a smaller organisation or as part of a formal process which will be the case in larger organisations.

The need for a business case is required by all businesses even those in the not for profit sector although their desire to generate increased profit, for example, is not the same central, overriding goal as it is the private sector.

Anyhow, there could be a whole heap of preliminary work that goes on before the word use case is mentioned. It should involve defining strategy and achieving business goals in support of that which will be internally driven.

Alternatively, it may be driven externally by, for example, regulatory requirements where there is usually a timetable for compliance dictated by a body outside the business.

I do not intend to cover any of this in detail but just give a flavour of where use cases may sit and how they are just part of an ongoing process that starts some time before and may or may not involve the business analyst.

The more experienced business analyst, who is hooked into the corporate strategy, may well be participating or even driving this preliminary work.

Often, however, the business analyst (in the IT department) is only called in when the project has a name and some objectives.

At this stage there are some useful models that can bear fruit downstream before diving into the level of detail required by use cases.

Context Diagram

Ultimately, it will be a box that defines the boundary or the project scope. Business activities within the box are in scope and activities outside the box are out of scope.

Below is an example of a context diagram.

Business Process Model

Producing a model of the business process or processes that are relevant will help towards this end.

If the business is undergoing a change, it is useful to see how the business operates today and how it will operate in the future which, in essence, are the ‘As Is’ (i.e. today) business processes and the ‘To Be’ (i.e. the future) business processes.

This is but a small part of the practice of business process reengineering which is a significant subject in its own right.

Business Use Cases

Business processes within an organisation can be modelled by business use cases. A business use case could come before the use cases sometimes referred to system use cases.

From a UML perspective, the processes of a business are defined as a number of different business use cases, each of which represents a specific workflow in the business.

A business use case defines what should happen in the business when it is performed; it describes the performance of a sequence of actions that produces a valuable result to a particular business actor. A business process either generates value for the business or mitigates costs to the business.

By establishing a set of business use cases in a business-use case model it can provide the basis for the use case model and subsequently use cases.

Business Use Case Model

Business use cases maybe combined into a business use case model. The business use case model is a model of the business intended functions. It is used as an essential input to identify business roles and deliverables in the business organisation.

Use Case Model

At last, we are approaching the use case model. Those business processes and the context diagram will provide an excellent point for first identifying our candidate use cases .

This is our first draft list of the ‘goals of observable value’ that will form the functional scope of our system.

In fact, it is often found that the business processes are composed of a series of steps and certain steps will fall within the scope of the project and will, therefore, need an actor to deliver them and a use case to describe the detail of how they are delivered.

This is not an exhaustive list of documents and models but gives a flavour of typical models and documents that precede use cases.

So, in summary:

There are many stages before a use case model becomes necessary;
There needs to be a business case to justify the project;
Context diagrams and business processes prove very useful (even necessary!) inputs to our candidate use cases.

Useful Links

You may find the following links useful for more information regarding context diagrams and business processes:

Related Books

Alex Papworth

Alex Papworth is a business analyst who has been working in IT for over twenty years. Business Analyst Mentor provides free articles and ebooks and recommends business analysis training courses.

Uncovering the Difference Between Business Cases and Use Cases

Updated: January 25, 2024

Essential Skills for Business Analysts

Business decisions backed with objective supporting information and business analysis are essential to success in any organization. The foundation of many decision-making processes revolves around creating and analyzing use cases and business cases in connection with, for example, selecting products (goods and/or services), moving forward with projects and initiatives, evaluating business process improvements, evaluating application software functionality, and numerous other business-related decisions.

Business cases and use cases, while related, each offers unique insights when it comes to analysis and decision making. Lack of clarity and understanding of these two distinct concepts and the roles that each play in analysis and decision-making leads to sub-optimal decision making – and in return, results in inefficient utilization of resources from an economic perspective as well as failed customer expectations.

In this blog post, I’ll uncover the crucial differences between Business Cases and Use Cases so business analysts and decision-makers can benefit from equipping themselves with essential knowledge for making informed decisions that lead to successful outcomes.

Definition of Business Case and Use Case

A Business case focuses on the potential financial and operational benefits of a product, process, project or initiative. A business case is an analysis of the benefits, costs and potential risks associated with a proposed action based on research by business analysts. By analyzing costs, benefits, risks, etc., an organization’s business case helps to inform a decision maker’s decision.

Important Note: The purpose of a business case is not to “sell” a decision or convince a decision maker of a position, it’s to enable a decision maker to make an informed objective decision. The role of a business analyst is to identify and present the facts – the pros/cons, benefits, costs, resource requirements, risks, and risk mitigation, etc. – not to present something in its best or worst light. Decision makers rely upon business analysis to research and present an objective business case. Decision makers can then evaluate the case based on the decision maker’s decision criteria also and evaluate the case across other potential opportunities.

A Use Case, on the other hand, is concerned with how users interact with and use a product or service to meet their needs to create value for the organization. It is focused on understanding user behavior, mapping out user flows, and testing product features to ensure they are effectively and efficiently supporting user requirements. By understanding what users need from a product, use cases can help surface potential issues that may arise during development and implementation.

How a Business Case and Use Case Differ

Business cases and use cases are two different facets in the development and selection of products. A business case typically outlines the potential value (often expressed in terms of financial returns) of a product, while a use case focuses on the practical applications of the product. Business cases often involve an analysis of market trends, customer demand, and competitor offerings to calculate potential returns, whereas use cases examine how the product can be used in the work environment to solve a problem or fulfill a need. Both business cases and use cases are essential components of decision making as they provide important insights into the viability of a new idea or concept. Business cases, for example, help determine whether a proposed project is financially feasible and worth pursuing, while use cases provide information about how customers will interact with the resulting product. By combining both types of analysis, organizations can provide products that meet customer needs while still being profitable for the organization.

The two concepts are distinct but related. Business cases analyze the financial viability of a product, project, etc., before moving forward into design, development and deployment. Use cases examine its usability from a customer perspective. Both provide valuable insight - but only when used together can they ensure that outcomes align with organizational goals and objectives.

Unidentified Requirements and Break-Fix Analysis

Business cases are often developed based on the defined use case scenarios of a product. This is particularly acute in application software development. High-level superficial business analysis in connection with a business systems requirement (e.g., Entering a Customer Order) results in incomplete discovery of the full range of business and user needs in connection with the requirement resulting in an incomplete use-case.

The resulting business case for that requirement is then based on the limited (not the full) set of requirements specified in the use case. In other words, the cost to develop and implement the full set of requirements is not included in the business case. However, when the functionality goes into production, the users discover that there is “missing” functionality – functionality that was not discovered in analysis and therefore not included in the use case and therefore not budgeted for as part of the business case.

The key is to ensure thorough identification, analysis and specification of functionality as part of the use case so that the full cost of designing, developing and implementing the functionality can be captured in the business case. I call this break-fix analysis – challenging the users to identify additional recurring scenarios that need to be supported. Thorough analysis informs and enables decision makers to make an objective assessment of the full cost of the functionality vs. the value of the functionality to the organization. The decision maker can choose to move forward or perhaps scale back the functionality. This in turn sets user expectations prior to implementation. The users may not like that some of the functionality was scaled-back, but at least it’s not a surprise and not a result of superficial analysis.

Business cases and use cases are distinct concepts. They are closely related but not interchangeable. A business case provides financial and operational insight for decision making. Use cases provide insight into how customers interact with the product and the value that they and their organization expect to gain from the interaction. By combining both types of analysis, organizations can create products that satisfy customer (internal and external) and stakeholder requirements in the most efficient and cost-effective manner.

Let's start a conversation regarding your business analysis goals and objectives and how our training courses can assist your journey.

Visit our Knowledge Hub for additional posts, whitepapers, videos, webinars, and frameworks.

Check out our business analysis training courses and our consulting services .

Visit my YouTube Channel

Connect with me on LinkedIn

Don't forget to share this post!

Recent blogs, the quantum dynamics of the current state of a business process, a fatal rookie mistake: understanding a process vs improving a process, yes indeed, there are stupid questions (in business analysis), bpmn vs. business analysis, cost optimization initiatives: 10 best practices, cost optimization vs. cost cutting: the distinction is crucial, cost optimization: three essential strategies, business system requirements: custom build vs. vendor product, top business analysis barriers: limited people resources, asking the right business questions changes everything, subscribe to our blog, some of our clients.

GSA and DOD Schedules

CONTACT INFO

800-719-4627
[email protected]

Business process modeling gives organizations a simple way to understand and optimize workflows by creating data-driven visual representations of key business processes.

Most enterprises have a pretty good idea of the various business processes powering their daily operations. However, when they need to ensure that those processes consistently drive optimal outcomes, “a pretty good idea” isn’t enough.

If an organization wants research and development (R&D) investments to produce sufficient returns, IT issues resolved with minimal downtime or a highly accurate lead qualification workflow, it needs to understand these processes on an objective and comprehensive level. Even the business users directly involved in these processes may lack total transparency into exactly what happens at every step of the way.

Business analysts can gain end-to-end views of the business process lifecycle through business process modeling , a business process management (BPM) technique that creates data-driven visualizations of workflows. These process models help organizations document workflows, surface key metrics, pinpoint potential problems and intelligently automate processes.

What is business process modeling?

A business process model is a graphical representation of a business process or workflow and its related sub-processes. Process modeling generates comprehensive, quantitative activity diagrams and flowcharts containing critical insights into the functioning of a given process, including the following:

Events and activities that occur within a workflow
Who owns or initiates those events and activities
Decision points and the different paths workflows can take based on their outcomes
Devices involved in the process
Timelines of the overall process and each step in the process
Success and failure rates of the process

Key aspects of business process modeling

Process models are not made manually. Rather, they are produced by data-mining algorithms that use the data contained within event logs to construct models of the workflows as they exist.
Because process models are based on quantitative data, they offer genuinely objective views of workflows as they exist in practice, including key data, metrics or events that may have otherwise gone unnoticed. For example, by creating a model of its new account creation process, a software company might discover that a significant number of customers are abandoning the sign-up process because it takes too long. A model could even help the company pinpoint the exact stage at which these drop-offs occur.
Arrows represent sequence flows
Diamonds represent decision points or gateways
Ovals represent beginnings and endpoints of processes
Rectangles represent specific activities within a workflow
Swimlanes are used to identify who owns which components of a process
Business process models shouldn’t be confused with process maps , another common type of business process diagram. Process maps are based on employee reports, are created manually and provide higher-level views of workflows. Process models are data-driven deep dives that present more objective views of workflows.

Learn more by reading “Process Mining vs. Process Modeling vs. Process Mapping: What’s the Difference?”

How business process models are made

To fully understand business process modeling techniques, one must first understand the relevant business process modeling tools — event logs and process mining .

Most enterprise IT systems maintain event logs . These event logs are digital records that automatically track state changes and activities (i.e., “events”) within the system. Anything that happens within a system can be an event. The following are some common event examples:

A user logs in
A user updates a record
A user submits a form
Information is transferred between systems

Event logs track both the occurrence of events and information surrounding these events, like the device performing an activity and how long the activity takes. Event logs act as the inputs during the production of process models.

Process mining is the application of a data-mining algorithm to all of this event log data. The algorithm identifies trends in the data and uses the results of its analysis to generate a visual representation of the process flow within the system. This visual representation is the process model . Depending on the process targeted for modeling, process-mining algorithms can be applied to a single system, multiple systems or entire technological ecosystems and departments.

Business process modeling use cases

Process models offer unprecedented levels of transparency into company workflows, making them a key business process management tool. While process models can be leveraged in any scenario that requires analyzing business processes, these are some of the most common use cases:

Gaining 360-degree insight into processes

A single process model can contain a wealth of workflow data, allowing team members to analyze a workflow from multiple perspectives. Business analysts often use business process modeling to zero in on the following workflow components in particular:

Control flow: “Control flow” refers to the order in which steps and commands are executed within a process. A process model depicts a flowchart of a given process so that a team can clearly see what steps are taken and when. This perspective also helps the team identify any dependencies between steps.
Organization: A process model can capture who is involved in a process — including people, teams, systems and devices — and how they interact with each other. This perspective illuminates the connections between people and systems that form the organizational social network. In this way, a process model offers insight into how various components of a business function together.
Time: A process model can record how long a process takes, overall, and how long each step takes, allowing the team to identify delays, slowdowns and bottlenecks within the workflow.
Case: A process model can offer a general view of how a given workflow typically plays out, or it can reflect a particular case – or instance – of a workflow. Teams often use this case perspective to analyze anomalous process outcomes. For example, if a specific instance of a workflow results in lower-than-average outcome quality, teams can isolate exactly what went wrong.

Optimizing and standardizing processes

Process models accurately reflect existing workflow inefficiencies, making it easier to identify opportunities for process optimization. Once workflows have been optimized, businesses can use process modeling to standardize workflows across the entire enterprise. The model acts as a template for how processes should play out, ensuring that every team and employee approaches the same process in the same way. This leads to more predictable workflows and outcomes overall.

Assessing new processes

Process models can take the guesswork out of implementing and evaluating new business processes. By creating a model of a new process, business users can get a real-time look at how that workflow is performing, allowing them to make adjustments as necessary to achieve process optimization.

Analyzing resource usage

Process models can help companies track whether money and resource investments produce suitable returns. For example, by creating a model of the standard sales process, an organization can see how sales representatives are utilizing the tools and systems at their disposal. It may turn out that a certain tool is used much less frequently than anticipated, in which case, the organization can choose to disinvest from the tool and spend that money on a solution the sales team actually uses.

Communicating processes

Process models transform complex processes into concrete images, making it easier to disseminate and discuss processes throughout the organization. For example, if one department has a particularly efficient process for troubleshooting technical problems, the business can create a model of this process to guide implementation on an organization-wide scale.

The benefits of business process modeling

Business process modeling arms an enterprise with objective business intelligence that supports more informed decisions for resource allocation, process improvement and overall business strategy. With a clear view of processes, enterprise teams can ensure that workflows always drive the desired results. As a result, operating costs are lower, revenue is higher and business outcomes are stronger.

Specifically, business process modeling allows companies to do the following:

Access and utilize quantitative process data: Without a process model, teams are limited to discussing and analyzing workflows in qualitative and subjective terms. As a result, teams may not accurately understand their workflows; they may make business decisions based on misunderstandings, assumptions and/or incomplete knowledge. With process modeling, teams have access to quantitative workflow data, including success rates and error rates, allowing for a more rigorous analysis of business processes.
Streamline and accelerate process automation: Before a process can be automated, an organization needs a clear understanding of how that process plays out in reality, including the business logic underpinning each decision point. A process model illuminates both the way a workflow unfolds and the relationships between events, actors, tools and systems within and between processes. This viewpoint helps a team document the process itself and the business rules that guide its execution. This information makes it easier to effectively automate workflows the first time.
Keep operation costs down: Process models provide organizations with an easy way to identify opportunities to optimize existing processes. This makes it easier for the company to ensure that processes consistently produce the desired outcomes. As a result, business processes require less investment to maintain and generate positive outcomes at a lower cost.

Business process modeling and IBM

Process modeling forms a cornerstone of any automation effort or business process management initiative. Without comprehensive views of existing processes and their undergirding business logic, enterprises cannot effectively optimize and automate workflows at scale.

Take the next step:

IBM Blueworks Live is a cloud-based business process modeling software designed to help organizations discover business processes and document them in a collaborative fashion across multiple stakeholder groups. Teams can work together through an intuitive and accessible web interface to document and analyze processes. No download required.

More from Automation

5 sla metrics you should be monitoring.

7 min read - In business and beyond, communication is king. Successful service level agreements (SLAs) operate on this principle, laying the foundation for successful provider-customer relationships. A service level agreement (SLA) is a key component of technology vendor contracts that describes the terms of service between a service provider and a customer. SLAs describe the level of performance to be expected, how performance will be measured and repercussions if levels are not met. SLAs make sure that all stakeholders understand the service agreement…

Scale enterprise gen AI for code generation with IBM Granite code models, available as NVIDIA NIM inference microservices

3 min read - Many enterprises today are moving from generative AI (gen AI) experimentation to production, deployment and scaling. Code generation and modernization are now among the top enterprise use cases that offer a clear path to value creation, cost reduction and return on investment (ROI). IBM® Granite™ is a family of enterprise-grade models developed by IBM Research® with rigorous data governance and regulatory compliance. Granite currently supports multilingual language and code modalities. And as of the NVIDIA AI Summit in Taiwan this…

Maximizing SaaS application analytics value with AI

5 min read - Software as a service (SaaS) applications have become a boon for enterprises looking to maximize network agility while minimizing costs. They offer app developers on-demand scalability and faster time-to-benefit for new features and software updates. SaaS takes advantage of cloud computing infrastructure and economies of scale to provide clients a more streamlined approach to adopting, using and paying for software. However, SaaS architectures can easily overwhelm DevOps teams with data aggregation, sorting and analysis tasks. Given the volume of SaaS…

IBM Newsletters

All Resources
Learning Hub

Business Process Modeling Use Cases and Definition

Mar 28, 2019 by Bunny Tharpe

What is business process modeling (BPM)? A visual representation of what your business does and how it does it. Why is having this picture important?

According to Gartner , BPM links business strategy to IT systems development to ensure business value. It also combines process/ workflow, functional, organizational and data/resource views with underlying metrics such as costs, cycle times and responsibilities to provide a foundation for analyzing value chains, activity-based costs, bottlenecks, critical paths and inefficiencies.

Every organization—particularly those operating in industries where quality, regulatory, health, safety or environmental issues are a concern—must have a complete understanding of its processes. Equally important, employees must fully comprehend and be accountable for appropriately carrying out the processes for which they are responsible.

BPM allows organizations to benefit from an easily digestible visualization of its systems and the associated information. It makes it easier to be agile and responsive to changes in markets and consumer demands,

This is because the visualization process galvanizes an organization’s ability to identify areas of improvement, potential innovation and necessary reorganization.

But a theoretical understanding of business process modeling will only get you so far. The following use cases demonstrate the benefits of business process modeling in real life.

Business process modeling (BPM) is a practice that helps organizations understand how their strategy relates to their IT systems and system development.

Business Process Modeling Use Cases

Compliance:

Regulations like the E.U.’s General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) are requiring businesses across industries to think about their compliance efforts. Business process modeling helps organizations prove what they are doing to meet compliance requirements and understand how changes to their processes impact compliance efforts (and vice versa).

The visualization process can aid in an organization’s ability to understand the security risks associated with a particular process. It also means that should a breach occur, the organization’s greater understanding of its processes and related systems means they can respond with greater agility, mitigate the damage and quickly inform affected parties as required specifically by GDPR.

In the case of an audit, BPM can be used to demonstrate that the organization is cognizant of compliance standards and is doing what is required.

This also extends to industry-specific other compliance mandates such as those in healthcare, pharmaceutical and the financial services industries.

The Regulatory Rationale for Integrating Data Management & Data Governance

The Democratization of Information:

Increasing an organizations ability to retain knowledge is another cross-industry use case for business process modeling. This use case benefits organizations in two key areas:

1. Democratization of information.

By documenting processes, organizations can ensure that knowledge and information is de-siloed and that the organization as a whole can benefit from it. In this case, a key best practice to consider is the introduction of role/user-based access . This way an organization can ensure only the necessary parties can access such information and ensure they are in keeping with compliance standards.

2. Knowledge retention.

By documenting processes and democratizing information, process-specific knowledge can be retained, even when key employees leave. This is particularly important in the case of an aging workforce, where an organization could suffer a “brain drain” as large numbers of employees retire during a short span of time.

Digital Transformation:

Once in a while, a technological revolution turns the nature of business on its head. The most recent and arguably most significant of which – although at this point it’s hard to argue – is the rise of data-driven businesses.

In a relatively short amount of time, the leaders in data-driven businesses were launched and stormed their way to the forefront of their respective industries – think Amazon, Netflix and Uber.

The result? Data is now considered more valuable than oil and industries across the board are seeing digital transformation en masse.

There’s a clear connection between business process modeling and digital transformation initiatives. With it, an organization can explore models to understand information assets within a business context, from internal operations to full customer experiences.

This practice identifies and drives digital transformation opportunities to increase revenue while limiting risks and avoiding regulatory and compliance gaffes.

Organizations that leverage BPM in their digital transformation efforts can use their greater

understanding of their current processes to make more informed decisions about future implementations.

And the use cases for business process modeling don’t stop there.

A better understanding of your organizations processes can also ease software deployments and make mergers and acquisitions (M&A) far easier to handle. Large organizations grow through M&A activity, and the combining of business processes, software applications and infrastructure when two organizations become one is very complex.

Business process modeling offers visibility into existing processes and helps design new processes that will deliver results in a post-merger environment.

The latest guide from the erwin Experts expands on these use cases and details how best to use business process modeling to tame your organization’s complexity and maximize its potential and profits.

Understand business process modeling.

Understand the key uses for business process modeling and the real-terms business outcomes for your organization.

What is a Business Use Case?

Learn how to accurately describe your customers’ interactions with your brand through business use case modeling.

Like many of us, you probably know how to make a sandwich, start a load of laundry, or write a check. As simple as these tasks may be, you could probably instruct someone else to do them, right? But what if they didn’t know what bread, a laundry machine, or a pen was? That’s when the task gets a little tricky.

For small- to medium-sized businesses, some processes may feel easy but can quickly get complicated as soon as varying factors and alternative process flows enter the equation. That’s why business use case writing is essential for project planning and product development.

What is a use case?

A use case is a written, detailed description of how an end user (i.e., customer) uses a system or product. The purpose of writing a use case is so you can specifically understand the step-by-step interactions between your customer and your system or products.

To put it really simply, writing a use case is about the journey, not the destination. It’s the process of mapping out how someone gets from point A to point B. While the goal is for the person to reach point B, writing a use case is more about understanding the technical steps it takes to arrive at point B.

From a business perspective, the person is your customer, and point B is the customer’s goal. Writing a business use case is about knowing what steps need to happen in order for your customer to reach their goal—which could be making a purchase or clicking a tab on your website to reach a desired page. Once a use case is written, it’s up to your engineers and software developers to design and code each of these pathways correctly.

Many organizations write use cases, but there are two types of teams that heavily rely on use cases: software engineering and product development.

Systems and software engineering

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

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

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

Product development

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

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

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

Use case vs. user story vs. process flow

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

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

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

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

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

Why you need a use case model for business processes

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

Breaks down large projects

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

Takes on customers' perspective

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

Prepares you for alternative outcomes and obstacles

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

Anatomy of a use case

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

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

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

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

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

Normal and alternative courses

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

Success scenarios and failure scenarios

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

How to write a business use case

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

Define your customer

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

Determine your customers’ goals

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

Map out your business use case model

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

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

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

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

Identify relationships between use cases

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

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

Write out user requirements specification

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

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

Improve business operations with efficient use cases

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

Dive deeper into the data

Subscribe to get more marketing insights straight to your inbox..

By signing up, you are agreeing that we can use your email address to market to you. You can unsubscribe from marketing emails at any time by using the link in our emails. For more information, please review our privacy statement .

From Business Process Models to Use Case Models: A Systematic Approach

Conference paper
Cite this conference paper

Estrela Ferreira Cruz 9 , 10 ,
Ricardo J. Machado 10 &
Maribel Yasmina Santos 10

Part of the book series: Lecture Notes in Business Information Processing ((LNBIP,volume 174))

Included in the following conference series:

Enterprise Engineering Working Conference

563 Accesses

15 Citations

One of the most difficult, and crucial, activities in software development is the identification of system functional requirements. A popular way to capture and describe those requirements is through UML use case models. A business process model identifies the activities, resources and data involved in the creation of a product or service, having lots of useful information for developing a supporting software system. During system analysis, most of this information must be incorporated into use case descriptions. This paper proposes an approach to support the construction of use case models based on business process models. The proposed approach obtains a complete use case model, including the identification of actors, use cases and the corresponding descriptions, which are created from a set of predefined natural language sentences mapped from BPMN model elements.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Available as PDF
Read on any device
Instant download
Own it forever
Compact, lightweight edition
Dispatched in 3 to 5 business days
Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Unable to display preview. Download preview PDF.

van der Aalst, W.M.P.: Business process management demystified: A tutorial on models, systems and standards for workflow management. In: Desel, J., Reisig, W., Rozenberg, G. (eds.) ACPN 2003. LNCS, vol. 3098, pp. 1–65. Springer, Heidelberg (2004)

Chapter Google Scholar

Ko, R.K.L.: A computer scientist’s introductory guide to business process management (bpm). Crossroads 15, 11–18 (2009)

Article Google Scholar

OMG, Business process model and notation (BPMN), version 2.0. Tech. rep., Object Management Group (2011)

Google Scholar

Jalote, P.: A concise Introduction to Software Engineering. Springer (2008)

Mili, H., Jaoude, G.B., Lefebvre, É., Tremblay, G., Petrenko, A.: Business process modeling languages: Sorting through the alphabet soup. In: OOF 22 NO. IST-FP6-508794 (PROTOCURE II) (September 2003)

Shishkov, B., Xie, Z., Liu, K., Dietz, J.L.: Using norm analysis to derive use cases from business processes. In: Proc. 5th Workshop on Organiz. Semiotics (2002)

Hull, E., Jackson, K., Dick, J.: Requirements Engineering. Springer (2011)

Dietz, J.L.G.: Deriving use cases from business process models. In: Song, I.-Y., Liddle, S.W., Ling, T.-W., Scheuermann, P. (eds.) ER 2003. LNCS, vol. 2813, pp. 131–143. Springer, Heidelberg (2003)

Bittner, K., Spence, I.: Applying use cases: a practical guide. P. Ed. inc. (2003)

Roussev, B.: Generating OCL specifications and class diagrams from use cases: a newtonian approach. In: Proceedings of the 36th Annual Hawaii International Conference on System Sciences, p. 10 (January 2003)

Fantechi, A., Gnesi, S., Lami, G., Maccari, A.: Applications of linguistic techniques for use case analysis. Req. Eng. 8(3), 161–170 (2003)

Cockburn, A.: Writing Effective Use Cases. Addison Wesley (2001)

Meyer, A.: Data in business process modeling. In: Proceedings of the 5th PhD Retreat of the HPI Research School on Service-oriented Systems Engineering (2010)

Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. Addison Wesley (1998)

OMG, Unified modeling language (OMG UML), version 2.5. Tech. Rep., Object Management Group (2012)

Giaglis, G.M.: A taxonomy of business process modeling and information systems modeling techniques. International Journal of Flexible Manufacturing Systems 13, 209–228 (2001)

Dijkman, R.M., Joosten, S.M.: Deriving use case diagrams from business process models. Tech. rep., CTIT Tech. Rep., Enschede, The Netherlands (2002)

Dijkman, R.M., Joosten, S.M.: An algorithm to derive use cases from business processes. In: 6th Int. Conf. on Software Engineering and Applications (2002)

Rodríguez, A., Fernández-Medina, E., Piattini, M.: Towards obtaining analysis-level class and use case diagrams from business process models. In: Song, I.-Y., et al. (eds.) ER 2008 Workshops. LNCS, vol. 5232, pp. 103–112. Springer, Heidelberg (2008)

Rodríguez, A., Fernández-Medina, E., Piattini, M.: Towards CIM to PIM transformation: From secure business processes defined in BPMN to use-cases. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) BPM 2007. LNCS, vol. 4714, pp. 408–415. Springer, Heidelberg (2007)

Bittner, K., Spence, I.: Use Case Modeling. Pearson Education Inc. (2003)

Rolland, C., Achour, C.B.: Guiding the construction of textual use case specifications. Data & Knowledge Engineering 25, 125–160 (1998)

Cox, K.: Heuristics for use case descriptions. Thesis (PhD) (November 2002)

Phalp, K., Vincent, J., Cox, K.: Improving the quality of use case descriptions: empirical assessment of writing guidelines. Software Quality Journal 15(4), 383–399 (2007)

Allweyer, T.: BPMN 2.0 - Introduction to the standard for business process Modeling. Books on Demand GmbH, Norderstedt (2010)

OMG, BPMN 2.0 by example. Tech. Rep., Object Management Group (2010)

Magnani, M., Montesi, D.: BPDMN: A conservative extension of BPMN with enhanced data representation capabilities. In: CoRR (2009)

Santos, M.Y., Machado, R.J.: On the derivation of class diagrams from use cases and logical software architectures. In: 2010 Fifth ICSEA (2010)

Download references

Author information

Authors and affiliations.

Instituto Politécnico de Viana do Castelo, Portugal

Estrela Ferreira Cruz

Centro ALGORITMI, Escola de Engenharia, Universidade do Minho, Guimarães, Portugal

Estrela Ferreira Cruz, Ricardo J. Machado & Maribel Yasmina Santos

You can also search for this author in PubMed Google Scholar

Editor information

Editors and affiliations.

Madeira Interactive Technologies Institute, University of Madeira &amp, Caminho da Penteada, 9020-105, Funchal, Portugal

David Aveiro

INESC and University of Lisbon, Portugal

José Tribolet

University of Madeira, Funchal, Portugal

Duarte Gouveia

Rights and permissions

Reprints and permissions

Copyright information

About this paper

Cite this paper.

Cruz, E.F., Machado, R.J., Santos, M.Y. (2014). From Business Process Models to Use Case Models: A Systematic Approach. In: Aveiro, D., Tribolet, J., Gouveia, D. (eds) Advances in Enterprise Engineering VIII. EEWC 2014. Lecture Notes in Business Information Processing, vol 174. Springer, Cham. https://doi.org/10.1007/978-3-319-06505-2_12

Download citation

DOI : https://doi.org/10.1007/978-3-319-06505-2_12

Publisher Name : Springer, Cham

Print ISBN : 978-3-319-06504-5

Online ISBN : 978-3-319-06505-2

eBook Packages : Computer Science Computer Science (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

Publish with us

Policies and ethics

Find a journal
Track your research

Home » UML » A Comprehensive Guide to Use Case Modeling

A Comprehensive Guide to Use Case Modeling

Posted on September 12, 2023
/ Under UML , Use Case Analysis

What is Use Case Modeling?

This is a technique used in software development and systems engineering to describe the functional requirements of a system. It focuses on understanding and documenting how a system is supposed to work from the perspective of the end users. In essence, it helps answer the question: “What should the system do to meet the needs and goals of its users?”

Key Concepts of Use Case Modeling

Functional Requirements : Functional requirements are the features, actions, and behaviors a system must have to fulfill its intended purpose. Use case modeling is primarily concerned with defining and capturing these requirements in a structured manner.

End User’s Perspective : Use case modeling starts by looking at the system from the viewpoint of the people or entities (referred to as “actors”) who will interact with the system. It’s essential to understand how these actors will use the system to achieve their objectives or perform their tasks.

Interactions : Use case modeling emphasizes capturing the interactions between these end users (actors) and the system. It’s not just about what the system does in isolation; it’s about how it responds to user actions or requests.

The Basics of Use Cases:

A use case is a description of how a system interacts with one or more external entities, called actors, to achieve a specific goal.
A use case can be written in textual or diagrammatic form, depending on the level of detail and complexity required.
A use case should capture the essential and relevant aspects of the interaction, such as the preconditions, postconditions, main flow, alternative flows, and exceptions.

What is a Use Case Diagram?

A use case diagram is a graphical representation used in use case modeling to visualize and communicate these interactions and relationships. In a use case diagram, you’ll typically see actors represented as stick figures, and the use cases (specific functionalities or features) as ovals or rectangles. Lines and arrows connect the actors to the use cases, showing how they interact.

Actors : These are the entities or users outside the system who interact with it. They can be people, other systems, or even external hardware devices. Each actor has specific roles or responsibilities within the system.
Use Cases : Use cases represent specific functionalities or processes that the system can perform to meet the needs of the actors. Each use case typically has a name and a description, which helps in understanding what it accomplishes.
Relationships : The lines and arrows connecting actors and use cases in the diagram depict how the actors interact with the system through these use cases. Different types of relationships, such as associations, extend relationships, and include relationships, can be used to specify the nature of these interactions.

How to Perform Use Case Modeling?

To understand a use case, you need to identify the actors and the use cases involved in the system. An actor is an external entity that has a role in the interaction with the system. 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 diagram. Actors can have generalization relationships, which indicate that one actor inherits the characteristics and behaviors of another actor. For example, a Student actor can be a generalization of an Undergraduate Student actor and a Graduate Student actor.
Actors can also have association relationships, which indicate that an actor is involved in a use case. For example, an Instructor actor can be associated with a Grade Assignment use case.

Relationships Between Actors and Use Cases:

Use Case Diagram - Website _ Structuring use cases with extend and ...

An include relationship is a dependency between two use cases, where one use case (the base) incorporates the behavior of another use case (the inclusion) as part of its normal execution.
An include relationship is represented by a dashed arrow with the stereotype «include» from the base to the inclusion.
An include relationship can be used to reuse common functionality, simplify complex use cases, or abstract low-level details
An extend relationship is a dependency between two use cases, where one use case (the extension) adds some optional or exceptional behavior to another use case (the base) under certain conditions.
An extend relationship is represented by a dashed arrow with the stereotype «extend» from the extension to the base.
An extend relationship can have an extension point, which is a location in the base use case where the extension can be inserted.
An extension point can be labeled with a name and a condition

Creating Effective Use Cases:

A system boundary is a box that encloses the use cases and shows the scope of the system.
A system boundary helps to distinguish what is inside the system (the use cases) and what is outside the system (the actors).
A system boundary should be clearly labeled with the name of the system and its version1.
A use case goal is a statement that summarizes what the use case accomplishes for the actor.
A use case goal should be specific, measurable, achievable, relevant, and testable.
A use case scenario is a sequence of steps that describes how the actor and the system interact to achieve the goal.
A use case scenario should be complete, consistent, realistic, and traceable.
A use case description is a textual document that provides more details about the use case, such as the preconditions, postconditions, main flow, alternative flows, and exceptions.
A use case description should be clear and concise, using simple and precise language, avoiding jargon and ambiguity, and following a consistent format.
A use case description should also be coherent and comprehensive, covering all possible scenarios, outcomes, and variations, and addressing all relevant requirements.
A use case template is a standardized format that helps to organize and present the use case information in a consistent and structured way.
A use case template can include various sections, such as the use case name, ID, goal, actors, priority, assumptions, preconditions, postconditions, main flow, alternative flows, exceptions, etc.
A use case documentation is a collection of use cases that describes the functionality of the system from different perspectives.
A use case documentation can be used for various purposes, such as communication, validation, verification, testing, maintenance, etc.

Use Case Modeling Best Practices:

Identify the key stakeholders and their goals, and involve them in the use case development process
Use a top-down approach to identify and prioritize the most important use cases
Use a naming convention that is consistent, meaningful, and descriptive for the use cases and actors
Use diagrams and textual descriptions to complement each other and provide different levels of detail
Use relationships such as extend, include, and generalization to show dependencies and commonalities among use cases
Review and validate the use cases with the stakeholders and ensure that they are aligned with the system requirements

Use Case Modeling using Use Case Template

Problem description: university library system.

The University Library System is facing a range of operational challenges that impact its efficiency and the quality of service it provides to students, faculty, and staff. These challenges include:

Manual Borrowing and Return Processes : The library relies on paper-based processes for book borrowing, return, and tracking of due dates. This manual approach is prone to errors, leading to discrepancies in record-keeping and occasional disputes between library staff and users.
Inventory Management : The current system for managing the library’s extensive collection of books and materials is outdated. The lack of an efficient inventory management system makes it difficult to locate specific items, leading to frustration among library patrons and unnecessary delays.
Late Fee Tracking : Tracking and collecting late fees for overdue books are challenging tasks. The library staff lacks an automated system to monitor due dates and assess fines accurately. This results in a loss of revenue and inconvenience for users.
User Account Management : User accounts, including library card issuance and management, rely on manual processes. This leads to delays in providing access to library resources for new students and difficulties in updating user information for existing members.
Limited Accessibility : The current library system lacks online access for users to search for books, place holds, or renew checked-out items remotely. This limitation hinders the convenience and accessibility that modern students and faculty expect.
Inefficient Resource Allocation : The library staff often face challenges in optimizing the allocation of resources, such as books, journals, and study spaces. The lack of real-time data and analytics makes it difficult to make informed decisions about resource distribution.
Communication Gaps : There is a communication gap between library staff and users. Users are often unaware of library policies, new arrivals, or changes in operating hours, leading to misunderstandings and frustration.
Security Concerns : The library system lacks adequate security measures to protect user data and prevent theft or unauthorized access to library resources.

These challenges collectively contribute to a suboptimal library experience for both library staff and users. Addressing these issues and modernizing the University Library System is essential to provide efficient services, enhance user satisfaction, and improve the overall academic experience within the university community.

Here’s a list of candidate use cases for the University Library System based on the problem description provided:

Create User Account
Update User Information
Delete User Account
Issue Library Cards
Add New Books to Inventory
Update Book Information
Remove Books from Inventory
Search for Books
Check Book Availability
Reserve Books
Renew Borrowed Books
Process Book Returns
Catalog and Categorize Books
Manage Book Copies
Track Book Location
Inventory Reconciliation
Calculate Late Fees
Notify Users of Overdue Books
Accept Late Fee Payments
Search for Books Online
Place Holds on Books
Request Book Delivery
Renew Books Online
Reserve Study Spaces
Allocate Study Materials (e.g., Reserve Books)
Manage Study Space Reservations
Notify Users of Library Policies
Announce New Arrivals
Provide Operating Hours Information
User Authentication and Authorization
Data Security and Privacy
Generate Usage Reports
Analyze Borrowing Trends
Predict Demand for Specific Materials
Request Materials from Other Libraries
Manage Interlibrary Loan Requests
Staff Authentication and Authorization
Training and Onboarding
Staff Scheduling
Provide Services for Users with Special Needs (e.g., Braille Materials)
Assistive Technology Support
Reserve Audio/Visual Equipment
Check Out Equipment
Suggest Books and Resources Based on User Preferences
Organize and Promote Library Workshops and Events

These candidate use cases cover a wide range of functionalities that address the issues identified in the problem description. They serve as a foundation for further analysis, design, and development of the University Library System to enhance its efficiency and user satisfaction. The specific use cases to prioritize and implement will depend on the system’s requirements and stakeholders’ needs.

Use Case Template:

Here’s the use case template and example for borrowing a book from a university library in tabular format:

	Borrow a Book
	UC001
	Student
	Librarian, Book Inventory System
	– The student has a valid library card.
	– The book is available in the library’s inventory.
	– The book is marked as checked out in the system.
	– The student has the book in their possession.
	1. The student wants to borrow a
	book from the university library.
	2.
	– The student presents their library card to
	the librarian.
	– The librarian scans the library card to
	verify its validity.
	– The student provides the title or ISBN of the
	book they wish to borrow.
	– The librarian searches the library catalog
	for the book.
	– The librarian confirms the book’s availability.
	– The librarian checks out the book to the
	student.
	– The student takes the book and leaves the
	library.
	3.
	– The system validates the library card.
	– The system updates the book’s status to
	“checked out.”
	– The system records the due date for the book
	loan.
	– The system generates a receipt for the
	transaction.
	4.
	– If the student’s library card is invalid, the
	librarian informs the student, and the use
	case terminates.
	– If the requested book is not available, the
	librarian informs the student, and the use
	case terminates.
	– If the student has overdue books, a notification
	is sent to the student.
	– If the student wants to renew the book, they can
	request a renewal through the library website.
	– The system should have a secure database of
	library cardholders.
	– Due dates and late fees should be calculated and
	enforced by the system.

Example Use Case: Borrowing a Book from University Library

These tables above presents the use case template and example in a structured and organized way, making it easier to read and understand the key elements of the use case.

Granularity of Use Cases

Use Case Granularity Definition : Use case granularity refers to the degree of detail and organization within use case specifications. It essentially describes how finely you break down the functionality of a system when documenting use cases. In simpler terms, it’s about how much or how little you decompose a use case into smaller parts or steps.

Importance of Use Case Granularity :

Communication Enhancement : Use case granularity plays a crucial role in improving communication between different stakeholders involved in a software project, such as business analysts, developers, testers, and end-users. When use cases are well-defined and appropriately granulated, everyone can better understand the system’s functionality and requirements.
Project Planning : The level of granularity in use cases impacts project planning. Smaller, more finely grained use cases can make it easier to estimate the time and effort required for development tasks. This aids project managers in creating more accurate project schedules and resource allocation.
Clarity and Precision : Achieving the right level of granularity ensures that use cases are clear and precise. If use cases are too high-level and abstract, they might lack the necessary detail for effective development. Conversely, overly detailed use cases can become unwieldy and difficult to manage.

Example : Let’s illustrate use case granularity with an example related to a “User Registration” functionality in an e-commerce application:

High Granularity : A single use case titled “User Registration” covers the entire registration process from start to finish. It includes every step, such as entering personal information, creating a password, confirming the password, and submitting the registration form.
Medium Granularity : Use cases are divided into smaller, more focused parts. For instance, “Enter Personal Information,” “Create Password,” and “Submit Registration” could be separate use cases. Each of these focuses on a specific aspect of user registration.
Low Granularity : The lowest level of granularity might involve breaking down actions within a single step. For example, “Enter Personal Information” could further decompose into “Enter First Name,” “Enter Last Name,” “Enter Email Address,” and so on.

The appropriate level of granularity depends on project requirements and the specific needs of stakeholders. Finding the right balance is essential to ensure that use cases are understandable, manageable, and effective in conveying system functionality to all involved parties.

In his book ‘Writing Effective Use Cases,’ Alastair Cockburn provides a simple analogy to help us visualize various levels of goal attainment. He suggests thinking about these levels using the analogy of the sea

References:

What is Use Case Diagram? (visual-paradigm.com)
What is Use Case Specification?

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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

When using bpmn to specify a process model. And using UML to specify a use case diagram. Don't they both describe processes? What's the difference between the two?

I'm reading a course which states:

A process model makes the processes in which the system is used readily understandable, but does not hold enough detail to develop a system A use case diagram denotes the interaction between a system and its users and the hierarchical relation between functionalities of the system

The difference seems apparent in the descriptions. One refers specifically to users and hierarchical relations, the other does not. – Robert Harvey Commented Jan 9, 2017 at 19:53
Have you looked at a BPMN process model and a UML use case diagram side by side? – Thomas Owens ♦ Commented Jan 9, 2017 at 19:54
Process model , Use Case diagram – Robert Harvey Commented Jan 9, 2017 at 19:57
1 @ThomasOwens yes to me it looks like in bpmn you can write out a complete process from start to finish. While in uml use case diagram it just looks like you are summing up use cases/processes (without going into them further) – Vincent Commented Jan 9, 2017 at 19:57
That seems like a reasonable summary to me. – Robert Harvey Commented Jan 9, 2017 at 19:57

2 Answers 2

BPMN is a profile which extends the UML language for a certain domain. Like with natural language you have a different wording to express things. And sometimes the same phonemes even have different semantics. So you need a bit of care when using both languages the same time.

BPMN is different to use cases as it focuses heavily on functionality. It has lots of new words that can describe how things interact. Use cases in contrast primarily aim to describe the added value, a system delivers to an actor. So that's something very, very basic. Use cases also have means to express how process steps are executed (using Activities and Actions). You find the same in BPMN and for the very same purpose. But, where Use Cases end, BPMN will start. So it's a good idea to gather the added value with use cases and then use BPMN in the following phases to describe how scenarios in use cases can be mapped to business processes (means order of actions in activities).

It is noteworthy that UML is not about diagramming, since this is mistaken by many people. There are a couple of different diagrams defined in the UML 2.5 spec for certain sub-domains. So you can expect a set of elements to appear in specific diagrams. But that's not mandatory. You can mix any elements if it helps communication the model (which is what holds the semantic). The diagrams are just meant to help people understand the model. So UseCases as per spec are (p. 637)

a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors. A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

And you will find the previous elements most likely in Use Case diagrams. However, you are free to mock them up where needed. So mixing BMPN (or elements from other profiles) is absolutely possible.

From the annex (p. 683):

NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.

Business processes are typically method agnostic. I.e. they do not, or atleast, should not specify the method(system) used to execute a process step. The same may, and should, be said of a Use Case, however, in my experience Use Cases are not typically generalised to "system" and instead explicity state the system in use.

From a design perspective, I would

Establish future state business process
Determine activities in process which must be enabled by software
Determine what actors will interact with software, and what goals they seek to achieve (in relation to the parent business process activity)
Model the Use Case Diagram

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Software Engineering Stack Exchange. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged uml bpm bpmn or ask your own question .

Featured on Meta
Upcoming sign-up experiments related to tags

Hot Network Questions

How do I emphasize a sentence without making it seem like the character is shouting?
Photo on a CV for a researcher application in Japan?
Are USB-C through hole shell stakes connected to GND or are they just there for fastening purposes only?
Ubuntu Terminal with alternating colours for each line
I'm sorry to say... I'm allergic to retrocomputing. Any advice on sanitizing new acquisitions?
Problem with superscripts on fractions
Can you make a logo very similar to an existing trademark?
Plagiarism in paragraph and image, or not?
"Better break out the weapons" before they leave the ship and explore the planet -- what kind?
P values non-significant but Monte Carlo confidence interval does not contain zero for indirect effects
Why is array access not an infix operator?
what is this cable called on a 2003 chevy cavalier
Do reflective warning triangles blow away in wind storms?
What happens when you target a dead creature with Scrying?
Three Wind Quartets (Gambaro) -- notes lengths don't add up (3.75 beats in common time)
How to explain Hazard Ratio in layperson's terms
Quote identification: Alles, was man lernen kann, lohnt sich nicht, gelernt zu werden
What type of aircraft is this?
Modify command for sum so that substack unnecessary
How does the June 2024 Ukraine peace summit hope to achieve peace, if Russia is not invited?
Squished ```\equiv'''
About Friedrichs historical contribution to QFT cited in Reed and Simon
Why isn't "meanwhile" advisable in this sentence? Doesn't it mean "at the same time"?
Difference in field of view between JWST and Euclid

Process Modeling in '24: Top 5 Use Cases & Case Studies

Process management allows companies to improve their processes so that they can enhance their process efficiency and customer satisfaction while decreasing cost. Yet, business analysts often do not know every activity and steps involved in processes despite interviewing with employees who directly involved in the processes. Business process modeling which is a data-driven method used under business process management can help overcome this challenge. Process modeling enables analysts to discover, visualize, analyze, and improve business processes while estimating the success of a modification to a business strategy.

This article explains process modeling and its top five business use cases.

What is business process modeling?

Process modeling is the practice of visualizing business processes and workflows. By including every individual step, process models provide an end-to-end overview of the tasks and activities in business processes. Process modeling reveals insights about:

Events and activities in a workflow
The people involved in these activities and events
Decision points together with the paths and outcomes
Systems and devices used in the process
Timeline
Success and failure rates

The graphical representation of the processes facilitates business leaders and analysts to inspect and improve process efficiency accordingly.

The advantages process modeling offers to include:

1. Increase process transparency

Process modeling helps understand how processes function with all steps and identify the factors that bring loops, repetitive works or errors, and the elements that bring efficiency and success.

HSA Bank 1 benefited from process modeling to understand and analyze their processes. The bank detected several tasks to simplify and clarify during the modelling, which improved their case resolution by 75%.

2. Ensure process standardization and optimization

Process modeling helps organizations understand internal procedures, rules and standards to align other processes that do not follow the required structure. Business leaders can optimize and standardize these processes based on their insights.

Cofco International 1 , one of China’s largest food and agriculture companies, applied process modeling to visualize and understand their compliance with the country-based laws and grain standards across different countries. The company traced and updated its processes with process modelling to ensure compliance and optimization.

3. Facilitate employee collaboration

Since process modeling allows businesses to visualize and understand actual processes, business leaders develop more accurate business strategies and communicate with employees based on the process graphs. As a result, process modeling streamlines the coordination of systems, people and information in the organization.

Westpac New Zealand Ltd. leveraged a process management solution to model and document their processes. The bank had a task document repository, into which staff members had to email the documents for storage. Therefore, they stored the documented processes in three months and created more than 2000 reusable artefacts. Over 130 employees use these documents and collaborate through them in new projects.

4. Discover process automation opportunities

Process modeling facilitates process automation as it enables business leaders and analysts to view and discover points and tasks that can benefit from automation.

The multinational printer and copier manufacturer Kyocera 1 captured their pricing approval processes with process modeling. By better understanding their processes, they detected several processes that can benefit from automation. That reduced the approval time by 85%. As employees allocate only 20 minutes per approval, they focus on other tasks, which improves overall efficiency.

5. Allocating process resources

Process modeling indicates the involvement of people in certain tasks or the usage of tools, devices and systems within a workflow. Therefore, businesses can leverage the modeling to determine if their resource and monetary investments generate expected returns.

One example would be that the manufacturers can understand their machinery usage in their production processes. Process modeling can show which machinery is utilized less and is utilized more frequently. Based on the insight, manufacturers can decide to re-allocate the work across the tools or disinvest in the machinery that is not helpful for their business to save money.

Next to Read

18 best process modeling tools and techniques to know in '24, process mining vs process modeling in '24: 4 best practices, 55 process improvement case studies & project results [2024].

Your email address will not be published. All fields are required.

Related research

Process Visualization in '24: 8 Use Cases & 13 Best Techniques

Process Knowledge in '24: 3 Steps to Manage it Better

Demo Videos
Interactive Product Tours
Request Demo

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:

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

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.

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 .

Privacy statement

BA Techniques

Challenge yourself by keeping up with practical business analysis techniques you can apply on the job.

Use Case Diagram - The Basics

USE CASE DIAGRAM - Includes Free Template

A use case diagram provides a high-level description of what your system should be able to do and who/what will interact with it. It’s a technique for specifying functional requirements.

Because use cases are easier to draw (when compared with other UML models), I'll just provide a guideline of the rules to follow and some examples below:

An actor can be a person, company, gadget, software or external entity that interacts with your system. For example, a customer, a restaurant, or database can be referred to as actors. They are usually modelled as being external to the system boundary.
A use case is the action that is performed within the system. It is usually represented as a combination of a verb and a noun, e.g. “deliver product”, “prepare invoice”, etc.
The <<uses>> and <<includes>> text when added to a relationship and drawn from A to B means that doing A involves doing B at least once.
You may choose to insert a boundary across the use case diagram to indicate the system functionalities that fall within that boundary.

A common confusion with use case diagramming is the difference between <<extends>> and <<uses>>. I like to define "extends" as an optional functionality . Think of a use case called “pay for item”. This can be achieved by “pay by credit card”, “pay cash on delivery” or “pay by PayPal”.

According to BABOK V2, "extends" allows the analyst to demonstrate additional behaviour of the base use case. The base use case is completely functional on its own and can do without the extending use case . An extension is functionally identical to an alternate flow, but is captured in a separate use case for convenience.

I'll now use an e-commerce site as an example. Placing an order requires the customer to first select an item. The base use case "place order" thus uses the "select item" use case. In a similar vein, placing an order on the website in this example, requires creating an account first.

The distinction between <<includes>> and <<uses>> should also be understood. The include relationship implies that the base use case includes the functionality of another use case (inclusion use case) while the uses relationship implies that the base use case cannot be complete without the use case it requires.

Use cases can be supported by textual descriptions known as use case descriptions to provide a greater level of detail on system functionality. Use cases focus on the "what" and not the "how"; they also do not indicate or suggest the order in which the system functionality is performed. Click here for an extensive review of techniques for identifying use cases.

Download the use case diagram template here (It's in Visio XML format and can be opened with Microsoft Visio).

An example is shown below:

Sample Use Case Diagram for an e-commerce site

**Check out Laura Brandenburg's training course on Use Cases and Wireframes. **

Business Analyst Learnings

This business analyst blog contains practical insights into business analysis, software testing and business process management. I will be sharing business analyst tips, CBAP Certification tips, lessons learnt and insights into all the things I've learnt during my BA career.

USEFUL BA PRODUCTS

Requirements Discovery List How to Start Your BA Career BA Template Toolkit BA Email Toolkit

Subscribe to Blog by Email

We respect your privacy.

Business Process Improvement
Requirements Elicitation
Software Testing
Stakeholder Management
CBAP Certification
Critical Thinking in Business Analysis
Missing requirements
Soft Systems Methodology
Free Business Analyst Training Online
Requirements Elicitation Technique
Use Case Diagram
Root Cause Analysis
How to design questionnaires
Role and Permissions Matrix
State transition diagram
Pareto analysis and decision-making
Problem tracking technique
Document Analysis

Business Analyst Glossary | Privacy Policy & Disclosures | Advertisements | Submitting A Post | BAL Services

Australian Business Number (ABN): 27 735 714 328

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.


	Actor	Actor 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 Case	A use case represents a function or an action within the system. It’s drawn as an oval and named with the function.
	System	The 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.
	Package	The 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.

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.

Business Case vs. Use Case

What's the difference.

A business case and a use case are both important tools used in project management and software development. A business case outlines the justification for a project, including the potential benefits, costs, and risks involved. It helps stakeholders understand the purpose and value of the project. On the other hand, a use case describes how a system will be used by its users to achieve specific goals. It outlines the interactions between the system and its users, helping to define the functional requirements of the project. While a business case focuses on the overall strategic objectives of a project, a use case delves into the specific details of how the system will be used in practice. Both documents are essential for ensuring the success of a project.

Attribute	Business Case	Use Case
Purpose	Justification for a proposed project or undertaking	Describes a specific interaction between a system and its users
Focus	Overall strategic goals and benefits	Specific functionality and user interactions
Scope	Broader, organization-wide impact	Specific scenario or situation
Stakeholders	Executives, investors, decision-makers	End users, developers, testers
Format	Document or presentation	Diagram or narrative

Further Detail

Introduction.

When it comes to software development and project management, two important documents play a crucial role in defining the scope and objectives of a project - the Business Case and the Use Case. While both documents are essential for the success of a project, they serve different purposes and have distinct attributes that set them apart.

A Business Case is a document that outlines the justification for a project, including the expected benefits, costs, risks, and potential return on investment. It provides a high-level overview of the project's objectives and how it aligns with the organization's strategic goals. On the other hand, a Use Case is a detailed description of how users interact with a system to achieve a specific goal. It outlines the steps a user takes to accomplish a task and the system's response to each action.

The primary purpose of a Business Case is to justify the need for a project and secure funding and resources from stakeholders. It helps decision-makers understand the potential benefits of the project and make informed choices about whether to proceed with it. On the other hand, the main purpose of a Use Case is to define the functional requirements of a system from the end user's perspective. It helps developers understand how users will interact with the system and design it accordingly.

A Business Case typically covers the strategic, financial, and organizational aspects of a project. It includes information about the project's objectives, scope, timeline, budget, risks, and expected outcomes. It also outlines the stakeholders involved in the project and their roles and responsibilities. In contrast, a Use Case focuses on the functional requirements of a system. It describes specific scenarios or user stories that illustrate how the system will be used in real-world situations.

Stakeholders

Stakeholders play a crucial role in both the Business Case and Use Case. In the case of a Business Case, stakeholders include executives, sponsors, investors, and other decision-makers who have a vested interest in the project's success. They rely on the Business Case to understand the project's strategic value and make funding decisions. On the other hand, stakeholders in a Use Case are typically end users, business analysts, developers, and testers who collaborate to define the system's requirements and ensure it meets user needs.

Documentation

Business Cases are usually presented in a formal document that follows a specific template or format. They include sections such as executive summary, project description, market analysis, financial projections, risk assessment, and recommendations. Business Cases are often reviewed and approved by a project steering committee or governance board before a project is initiated. In contrast, Use Cases are typically documented using diagrams, flowcharts, and narrative descriptions. They focus on specific user interactions and system responses, detailing the steps required to achieve a particular goal.

Flexibility

Business Cases are generally less flexible than Use Cases. Once a Business Case is approved, it sets the foundation for the project's scope, objectives, and budget. Any changes to the project's scope or budget require a formal review and approval process. On the other hand, Use Cases are more flexible and can be updated or modified throughout the development process. As user needs evolve or new requirements emerge, Use Cases can be revised to reflect these changes and ensure the system meets user expectations.

In conclusion, while both Business Cases and Use Cases are essential documents in project management and software development, they serve different purposes and have distinct attributes. A Business Case justifies the need for a project and secures funding, while a Use Case defines how users interact with a system to achieve specific goals. Understanding the differences between these two documents is crucial for project success and ensuring that the project meets stakeholder expectations.

Comparisons may contain inaccurate information about people, places, or facts. Please report any issues.

The Community

Modern analyst blog, community blog.

Member Profiles

Networking Opportunities

Community spotlight, business analysis glossary, articles listing, business analyst humor, self assessment.

Training Courses
Organizations
Resume Writing Tips
Interview Questions

Let Us Help Your Business

Advertise with us, rss feeds & syndication, privacy policy.

Business Analyst Community & Resources | Modern Analyst

Use Cases and Business Rules: Can They Work Together?

(This article assumes knowledge of the Decision Model. If you are not already familiar with the theory of the Decision Model, you can download a brief primer from www.TheDecisionModel.com . You can order the book here including a Kindle version)

Portions of this article are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC. This article consists, in part, of abstracts from the book; directly quoted passages, diagrams, and tables are cited, and are copyright © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

This article discusses various approaches for dealing with business rules and use cases. We begin with three important questions.

Question #1: Why Separate Business Rules? The primary benefit to separating them is to manage them separately. If we separate them properly, we can:

Make changes in one with minimal impact on the other. This is desirable because business rules often change more frequently than do use cases.

Share business rules across many use cases.

Define, analyze, and test business rules prior to, or in parallel with, development of use cases.

Iterate between use case development and business rule capture.

Involve different business people in use case development versus business rule capture, as appropriate.

Question #2: How to Separate Business Rules?

To separate business rules from use cases, they must be different. The good news is that business rules and use cases are fundamentally different considerations. Use cases are primarily about actor interactions. Business rules are about reasoning and logic.

The second way is to pull them out of the use case altogether. We accomplish this by providing pointers to them in a business rule repository.

Both approaches separate them from the major emphasis of the use case, actor interactions. Therefore, both approaches simplify the use case because the use case reduces essentially to the flow of actor interactions, not distracted by business rule logic. Approaches 1-4 in this article accomplish such separation. Each approach does so better than the one before it.

However, separating business rules is not the same as promoting them to a new dimension in their own right. This idea is worth contemplating.

Question #3: How to Promote Business Rules to a New Dimension? To promote business rules to a new dimension, they must not only be different from other dimensions, they must have their own existence, independent of how and where executed, and whether automated or not. The combination of their own existence and independence means we should be able to cast them in their own model that is recognizably different (in structure and behavior) from all other kinds of models. If not, we can only separate them, not promote them higher.

Approach 5 in this article delivers business rules as a new dimension.

The approaches below do not address ways to express business rules nor do they recommend specific use case templates. Instead, a simple example, informal business rule expressions and a basic use case template will suffice.

Buried Business Rules

Once upon a time, use cases had no notion of business rules. Use case templates contained places for pre-conditions, post-conditions, basic and alternate flows, but nothing for business rules. So, the business rules, if anywhere, were buried in the use case flow. See Figure 1.

Figure 1: Use Case without a Place for Business Rule Statements (so business rules are buried)

Approach 1: Dangling Business Rules Approach 1 is an improvement because it contains a place for business rule statements usually at the bottom of a use case template. They are no longer lost, but are dangling and unconnected. See Figure 2

Figure 2: Use Case with Business Rule Statements at the Bottom (so business rules are dangling)

Nevertheless, there are three advantages to Approach 1:

It separates business rules by giving them their own section in the use case template.

It simplifies use case flow to include only actor interactions, devoid of business rule logic.

It accelerates use case development because we can add business rules later as we discover them.

However, Approach 1 has three disadvantages:

It leaves unclear which business rules execute in which steps.

It forces business rule changes in the use case. That is, to change a business rule, we must do so in every use case referencing it.

Despite separated within the use case, business rules do not emerge as anything outside the use case.

Approach 2: Positioned Business Rules Approach 2 offers a use case template in which business rule statements connect to use case steps. Therefore, the business rules are positioned within the use case flow. See Figure 3.

Figure 3: Use case with Business Rule Statements within Use Case Steps (so business rules are positioned where needed)

Approach 2 has the same advantages as Approach 1, with one additional advantage:

It makes clear which business rules are executed in which steps.

However, Approach 2 still has two disadvantages:

It still forces business rule changes in the use case. Here, to change a business rule, we must change it in every use case step referencing it.

Business rules still do not emerge as anything outside the use case.

Approach 3: Anchored Business Rules Approach 3 uses a use case template that associates a use case step with a business rule identifier. The identifier points to the business rule statement in a business rule repository. Therefore, the use case template anchors the business rules to the use case steps, but the business rules themselves are elsewhere. See Figure 4.

Figure 4: Use Case with Business Rule Identifiers within Use Case Steps (so business rules are anchored to a business rule repository)

Approach 3 has three advantages:

It establishes business rules as a deliverable outside the use case, encouraging business rule sharing.

The business rule repository can include metadata about them, such as effective and expiration dates, version, and stewards.

It removes business rule changes from use cases. To change a business rule, we change it in the business rule repository without changes to use cases.

However, Approach 3 has one disadvantage:

It forces us to make changes in the use case when we need to change membership of groups of business rules. That’s because Approach 4 deals only with individual business rules, not with groups.

Approach 4: Grouped Business Rules Approach 4 associates a use case step with a collection of business rules, grouped in a meaningful way. We can create collections of business rules in many ways. However, the most popular collection of business rules (and somewhat disciplined) is a decision table. Let’s use a decision table as an example for Approach 4.

	1	2	3	4	5
1. Candidate Initial Interview Rating	= 5	<3		<3	<=3
2. Candidate Compensation Expectation		aligned	aligned	aligned
3. Candidate Personality Rating	Excellent	good	good	excellent
4. Candidate Cognitive Rating	Excellent	excellent	excellent	average

1. Candidate Ranking	1	2	3	4	5
2. Candidate Culture Fit	Yes	Yes	Yes	No	no
3. Make Job Offer to Candidate	Yes	Yes	Maybe	No	no

Figure 5: Typical Decision Table

The decision table Figure 5 is a collection of five business rules, numbered 1 through 5. They evaluate some or all of its four conditions to arrive at its three actions. In Approach 4, an entire decision table has an identifier which is associated with relevant use case steps as seen in Figure 6.

Figure 6: Use Case with Decision Table Identifier within Use Case Steps (business rules are grouped)

Approach 4 has four advantages:

It removes changes in individual and collections of business rules from the use case. That is, we make these changes only in the decision table (or other grouping) in a business rule repository, with no corresponding changes in use cases.

It is a format easily understood by business audiences.

Its format is easy to analyze and validate a collection of business rules.

It establishes the decision table (or other grouping) as a separate deliverable outside the use case.

Today Approach 4 is the most common practice due to its advantages. However, there are two disadvantages.

While the decision table in Figure 5 is simple, many are more complex. If their logic includes Ors among conditions, ELSE’s or OTHERWISE among conclusions, the decision table resembles program code, difficult for business people to validate or analyze.

A more subtle disadvantage is the execution of several decision tables within a use case step. Should the use case list them? Should it separate them into more than one step even if their execution happens on behalf of one actor interaction? Does the use case include or point to a process flow among them? How much of this is design and not appropriate for a use case?

Approach 5: Modeled Business Rules Let’s consider a similar goal and its solution from the past.

Almost 50 years ago, there was a desire to separate data from process. This separation started by identifying individual data elements, grouping them into logical collections, storing them in data dictionaries, and connecting them to processes. However, this failed to achieve anticipated benefits. Specifically, separation alone did not deliver on the promise!

“Success came with the introduction of a model for data that was different from existing models….that model for data changed forever the way the world thinks about, manages and leverages data stored in databases.” One reason for the endurance of the Relational Model is that it is based only on the inherent nature of data itself, and nothing more.

Approach 5 takes that leap again. It goes beyond lists and groupings of business rules and delivers a model that is uniquely different from others. “It is a model that addresses an important unsolved problem: how to effectively manage business logic and rules, not as lists or annotations attached to or buried in other models, but in a model of their own.” The Decision Model is neither a language nor a grammar; it is a new, disciplined model.

Therefore, Approach 5 associates a use case step with a business decision – something bigger in importance than individual or collections of business rules, but driven by them. See Figure 7.

Figure 7: Use Case with Decisions within Use Case Steps (so business rules are modeled)

The business decision is the anchor point for a structural model comprised only of business rules and called a Decision Model. The Decision Model for Decision #16 is in Figure 8 and contains two Rule Families connected with an inferential relationship.

Figure 8: Decision Model with One Populated Rule Family.

The advantages of Approach 5 are significant because they come from managing a model, not lists or groups. Advantages are:

Represents business rule logic in its most atomic form and with inherent connections

Enables sharing of entire Decision Models

Supports a step-by-step iterative development of business rules in a model (at various levels of detail for different purposes)

Removes all business rule changes from use cases (and other models) because all changes in an entire Decision Model happen in one place without corresponding changes elsewhere.

Solidifies the natural boundary between procedural use case steps and declarative business rules

Enables visual impact analysis across entire Decision Models

Delivers a representation understandable by business and I/T and amenable to automation

Serves as the foundation for building Decision Model views (customizations of whole models for specific geographical, political, or business requirements)

Has proven in practice to be faster to develop and implement than any of the other options.

Use cases and business rules definitely work together. Because they represent fundamentally different considerations, you can choose the optimum way to separate them.

But, if you believe that business rules have their own existence, independent of how and where executed, and whether automated or not, then you must cast them in their own model. Otherwise, you miss the opportunity to promote them to a higher, more visible, more valuable and agile business asset. It is easier than you might think.

Authors: Barbara von Halle and Larry Goldberg of Knowledge Partners International, LLC (KPI)

1 Rule Families are similar to decision tables but with more rigor. This Decision Model is incomplete. It is missing at least three Rule Families, maybe more, as indicated by the positions of fact types above the dotted lines.

When Use Cases Aren’t Enough: Event Analysis

Article/Paper Categories

Upcoming live webinars.

ACE THE INTERVIEW

Roles and Titles

Business Analyst
Business Process Analyst
IT Business Analyst
Requirements Engineer
Business Systems Analyst
Systems Analyst
Data Analyst

Career Resources

Interview Tips
Salary Information
Directory of Links

Community Resources

Project Members

Advertising Opportunities | Contact Us | Privacy Policy

Process Flowchart VS Use Case Diagram

When would we use the use case diagram to plan out and when would you use flowcharts?

Flowchart vs use case.

Flowcharts are often used for documentation purposes because many different people use that documentation and flowcharts are easier to follow than pseudo code for non programmers.

Download Flowchart Software and View Examples

Advantages:

Easy to draw and analyze.

Easy to understand.

High-level, end-to-end visualizations.

Widely used for various purposes.

Use case diagram is a sub class of behavioral diagrams which shows how a system interacts with the external entities. So, it is relatively sparse about the details of how the system behaves internally and how the external environment is configured. Indeed, use case diagram shows what we want the system to do rather than describe how it can be accomplished. One of the major benefits of this diagram is communication. Once a process flow is sketched out, the individual steps in a process flow usually are good candidates for further elaboration of details with Use Cases.

More detailed stuff.

Represent complex things.

Who Use Flowchart

Process flowchart is commonly used by the product manager, designer, or people who need to talk about how the business works.

Who Use Use Case

The use case diagram is extensively used by the product manager and development engineer.

Flowcharts and use case diagram often have the same level of expressiveness, but differ in linearization. Flowcharts are a higher abstraction level , used before writing use case or for documentation.

Typically, Use Cases are related to the interactions between people and systems. A process flowchart will usually be a graphical representation of how a business object like an order will flow through various business rules and system states. For a really complicated problem, you would use flowcharts first, then use case diagram.

A good flowchart tool will save you lots of time. Edraw Max can draw both flowcharts and use case diagrams. You needn't concern about the drawing skill, but only understand the whole process flowchart .

Create a complex flowchart

How to create a process flowchart

Six Major Flowchart Elements

How to create a BPMN diagram

Flowchart software

Process Flow Diagram Software

Process and Instrumentation Drawing Software

Understand flowchart

Flowchart examples

Get Started! You Will Love This Easy-To-Use Diagram Software

EdrawMax is an advanced all-in-one diagramming tool for creating professional flowcharts, org charts, mind maps, network diagrams, UML diagrams, floor plans, electrical diagrams, science illustrations, and more. Just try it, you will love it!

Stack Overflow Public questions & answers
Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
Talent Build your employer brand
Advertising Reach developers & technologists worldwide
Labs The future of collective knowledge sharing
About the company

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

What is the difference between Use case and Use case model? [closed]

I'm delivering a project to a client and he is asking for Use case and use case model What is the difference between them ?

I've nominated for reopening - this question concerns understanding particular terms with clear definitions - does not seem "too broad". – BartoszKP Commented Jul 2, 2017 at 21:21
@BartoszKP, I'm voting against re-opening. In its current form, it looks like the user did not trouble using a search engine and/or reading any of the abundant online documentation regarding the two compared terms. – tao Commented Jul 3, 2017 at 1:50

A Use case is a description of a single interaction between the user and the system. A Use case model is a description of a whole functionality described with many use cases.

For example, if a system needs to manage some invoice related business process, then a use case model for such a process would consist of a use case describing steps required to add an invoice to the system, another use case describing what the user should do to sign it, and another use case presenting an invoice export scenario - etc..

My System Has 2 parts - Mobile App - Admin panel So the mobile user will have use case and admin will have one The use case model will gather all ?? – Mobicoder Commented Oct 9, 2013 at 15:33
Simply speaking, if we are talking about one functionality then yes, if there are really only single use cases for each user type. – BartoszKP Commented Oct 9, 2013 at 15:43

Not the answer you're looking for? Browse other questions tagged use-case or ask your own question .

Featured on Meta
Upcoming sign-up experiments related to tags
Policy: Generative AI (e.g., ChatGPT) is banned
The [tax] tag is being burninated
The return of Staging Ground to Stack Overflow
The 2024 Developer Survey Is Live

Hot Network Questions

Using commented dashes to divide up code chunks
About Friedrichs historical contribution to QFT cited in Reed and Simon
Why isn't "meanwhile" advisable in this sentence? Doesn't it mean "at the same time"?
Is it known that the the sequence 7n+1 would diverge starting with 7?
How does the June 2024 Ukraine peace summit hope to achieve peace, if Russia is not invited?
Examples of systems with infinite dimensional Hilbert space, whose energy is bounded from above
what is this cable called on a 2003 chevy cavalier
Is Russell's Paradox a semantic paradox or a syntactic paradox?
P values non-significant but Monte Carlo confidence interval does not contain zero for indirect effects
What insect has infested this apple tree
What does "far right tilt" actually mean in the context of the EU in 2024?
Does speeding turn an accident into manslaughter?
Why are we abbreviating Player's Handbook to PHB?
Difference in field of view between JWST and Euclid
Why is finding a mathematical basis for the fine-structure constant meaningful?
Modify command for sum so that substack unnecessary
Are there statements so self-evident that writing a proof for them is meaningless? Is this an example of one?
Gradient stops for metallic cylinder effect
Quote identification: Alles, was man lernen kann, lohnt sich nicht, gelernt zu werden
Having friends who are talented is great, but it can also be ___ at times
Instrumentation amp output not matching voltage drop in LT Spice
9-16-25 2D Matrix
How to explain Hazard Ratio in layperson's terms
a not-so optimized, not-so simple brainfuck source-to-source compiler to assembly (fasm) written in python that automatically compile using fasm

Business intelligence management

business intelligence (BI)

Craig Stedman, Industry Editor

What is business intelligence?

Business intelligence (BI) is a technology-driven process for analyzing data and delivering actionable information that helps executives, managers and workers make informed business decisions. As part of the BI process, organizations collect data from internal IT systems and external sources, prepare it for analysis, run queries against the data and create data visualizations, BI dashboards and reports to make the analytics results available to business users for operational decision-making and strategic planning .

The ultimate goal of BI initiatives is to drive better business decisions that enable organizations to increase revenue, improve operational efficiency and gain competitive advantages over business rivals. To achieve that goal, BI incorporates a combination of analytics, data management and reporting tools, plus various methodologies for managing and analyzing data.

How does the business intelligence process work?

A business intelligence architecture includes more than just BI software. Business intelligence data is typically stored in a data warehouse built for an entire organization or in smaller data marts that hold subsets of business information for individual departments and business units, often with ties to an enterprise data warehouse. In addition, data lakes based on Hadoop clusters or other big data systems are increasingly used as repositories or landing pads for BI and analytics data, especially for log files, sensor data, text and other types of unstructured or semistructured data.

BI data can include historical information and real-time data gathered from source systems as it's generated, enabling BI tools to support both strategic and tactical decision-making processes . Before it's used in BI applications, raw data from different source systems generally must be integrated, consolidated and cleansed using data integration and data quality management tools to ensure that BI teams and business users are analyzing accurate and consistent information.

This article is part of

Ultimate guide to business intelligence in the enterprise

Which also includes:
5 valuable business intelligence use cases for organizations
What are the key BI team roles and responsibilities?
20 top BI tools and how to choose the right one

Download this entire guide for FREE now!

From there, the steps in the BI process include the following:

data preparation , in which data sets are organized and modeled for analysis;
analytical querying of the prepared data;
distribution of key performance indicators (KPIs) and other findings to business users; and
use of the information to help influence and drive business decisions.

Initially, BI tools were primarily used by BI and IT professionals who ran queries and produced dashboards and reports for business users. Increasingly, however, business analysts, executives and workers are using business intelligence platforms themselves, thanks to the development of self-service BI and data discovery tools. Self-service business intelligence environments enable business users to query BI data, create data visualizations and design dashboards on their own.

BI programs often incorporate forms of advanced analytics, such as data mining, predictive analytics , text mining, statistical analysis and big data analytics . A common example is predictive modeling that enables what-if analysis of different business scenarios. In most cases, though, advanced analytics projects are conducted by separate teams of data scientists , statisticians, predictive modelers and other skilled analytics professionals, while BI teams oversee more straightforward querying and analysis of business data.

How the business intelligence process works

Why business intelligence is important

Overall, the role of business intelligence is to improve an organization's business operations through the use of relevant data. Companies that effectively employ BI tools and techniques can translate their collected data into valuable insights about their business processes and strategies. Such insights can then be used to make better business decisions that increase productivity and revenue, leading to accelerated business growth and higher profits.

Without BI, organizations can't readily take advantage of data-driven decision-making. Instead, executives and workers are primarily left to base important business decisions on other factors, such as accumulated knowledge, previous experiences, intuition and gut feelings. While those methods can result in good decisions, they're also fraught with the potential for errors and missteps because of the lack of data underpinning them.

Benefits of business intelligence

A successful BI program produces a variety of business benefits in an organization. For example, BI enables C-suite executives and department managers to monitor business performance on an ongoing basis so they can act quickly when issues or opportunities arise. Analyzing customer data helps make marketing, sales and customer service efforts more effective. Supply chain, manufacturing and distribution bottlenecks can be detected before they cause financial harm. HR managers are better able to monitor employee productivity, labor costs and other workforce data.

Overall, the key benefits that businesses can get from BI applications include the ability to:

speed up and improve decision-making;
optimize internal business processes;
increase operational efficiency and productivity;
spot business problems that need to be addressed;
identify emerging business and market trends;
develop stronger business strategies;
drive higher sales and new revenues; and
gain a competitive edge over rival companies.

BI initiatives also provide narrower business benefits -- among them, making it easier for project managers to track the status of business projects and for organizations to gather competitive intelligence on their rivals. In addition, BI, data management and IT teams themselves benefit from business intelligence, using it to analyze various aspects of technology and analytics operations.

Types of business intelligence tools and applications

Business intelligence combines a broad set of data analysis applications designed to meet different information needs. Most are supported by both self-service BI software and traditional BI platforms. The list of BI technologies that are available to organizations includes the following:

Ad hoc analysis . Also known as ad hoc querying, this is one of the foundational elements of modern BI applications and a key feature of self-service BI tools. It's the process of writing and running queries to analyze specific business issues. While ad hoc queries are typically created on the fly, they often end up being run regularly, with the analytics results incorporated into dashboards and reports.

Online analytical processing (OLAP). One of the early BI technologies, OLAP tools enable users to analyze data along multiple dimensions, which is particularly suited to complex queries and calculations. In the past, the data had to be extracted from a data warehouse and stored in multidimensional OLAP cubes, but it's increasingly possible to run OLAP analyses directly against columnar databases.

Mobile BI . Mobile business intelligence makes BI applications and dashboards available on smartphones and tablets. Often used more to view data than to analyze it, mobile BI tools typically are designed with an emphasis on ease of use. For example, mobile dashboards may only display two or three data visualizations and KPIs so they can easily be viewed on a device's screen.

Real-time BI . In real-time BI applications, data is analyzed as it's created, collected and processed to give users an up-to-date view of business operations, customer behavior, financial markets and other areas of interest. The real-time analytics process often involves streaming data and supports decision analytics uses, such as credit scoring, stock trading and targeted promotional offers.

Operational intelligence (OI). Also called operational BI, this is a form of real-time analytics that delivers information to managers and frontline workers in business operations. OI applications are designed to aid in operational decision-making and enable faster action on issues -- for example, helping call center agents to resolve problems for customers and logistics managers to ease distribution bottlenecks.

Software-as-a-service BI . SaaS BI tools use cloud computing systems hosted by vendors to deliver data analysis capabilities to users in the form of a service that's typically priced on a subscription basis. Also known as cloud BI, the SaaS option increasingly offers multi-cloud support, which enables organizations to deploy BI applications on different cloud platforms to meet user needs and avoid vendor lock-in.

Open source BI (OSBI). Business intelligence software that is open source typically includes two versions: a community edition that can be used free of charge and a subscription-based commercial release with technical support by the vendor. BI teams can also access the source code for development uses. In addition, some vendors of proprietary BI tools offer free editions, primarily for individual users.

Embedded BI . Embedded business intelligence tools put BI and data visualization functionality directly into business applications. That enables business users to analyze data within the applications they use to do their job. Embedded analytics features are most commonly incorporated by application software vendors, but corporate software developers can also include them in homegrown applications.

Collaborative BI . This is more of a process than a specific technology. It involves the combination of BI applications and collaboration tools to enable different users to work together on data analysis and share information with one another. For example, users can annotate BI data and analytics results with comments, questions and highlighting via the use of online chat and discussion tools.

Location intelligence (LI). This is a specialized form of BI that enables users to analyze location and geospatial data, with map-based data visualization functionality incorporated. Location intelligence offers insights on geographic elements in business data and operations. Potential uses include site selection for retail stores and corporate facilities, location-based marketing and logistics management.

Business intelligence vendors and market

Self-service BI and data visualization tools have become the standard for modern BI software. Tableau, Qlik and Spotfire, which is now part of Tibco Software, took the lead in developing self-service technology early and became prominent competitors in the BI market by 2010. Most vendors of traditional BI query and reporting tools have followed in their path since then. Now, virtually every major BI tool incorporates self-service features, such as visual data discovery and ad hoc querying.

In addition, modern BI platforms typically include:

data visualization software for designing charts and other infographics to show data in an easy-to-grasp way;
tools for building BI dashboards, reports and performance scorecards that display visualized data on KPIs and other business metrics;
data storytelling features for combining visualizations and text in presentations for business users; and
usage monitoring, performance optimization, security controls and other functions for managing BI deployments.

BI tools are available from dozens of vendors overall. Major IT vendors that offer BI software include IBM, Microsoft, Oracle, SAP, SAS and Salesforce, which bought Tableau in 2019 and also sells its own tools developed before the acquisition. Google is also in the BI market through its Looker unit, acquired in 2020. Other notable BI vendors include Alteryx, Domo, GoodData, Infor Birst, Information Builders, Logi Analytics, MicroStrategy, Pyramid Analytics, Sisense, ThoughtSpot and Yellowfin.

While full-featured BI platforms are the most widely used business intelligence technology, the BI market also includes other product categories. Some vendors offer tools specifically for embedded BI uses; examples include GoodData and Logi Analytics. Companies like Looker, Sisense and ThoughtSpot target complex and curated data analysis applications. Various dashboard and data visualization specialists focus on those parts of the BI process; other vendors specialize in data storytelling tools.

What are some examples of business intelligence use cases?

In general terms, enterprise BI use cases include:

monitoring business performance or other types of metrics;
supporting decision-making and strategic planning;
evaluating and improving business processes;
giving operational workers useful information about customers, equipment, supply chains and other elements of business operations; and
detecting trends, patterns and relationships in data.

Specific use cases and BI applications vary from industry to industry. For example, financial services firms and insurers use BI for risk analysis during the loan and policy approval processes and to identify additional products to offer to existing customers based on their current portfolios. BI helps retailers with marketing campaign management, promotional planning and inventory management, while manufacturers rely on BI for both historical and real-time analysis of plant operations and to help them manage production planning, procurement and distribution.

Airlines and hotel chains are big users of BI for things such as tracking flight capacity and room occupancy rates, setting and adjusting prices, and scheduling workers. In healthcare organizations, BI and analytics aid in the diagnosis of diseases and other medical conditions and in efforts to improve patient care and outcomes. Universities and school systems tap BI to monitor overall student performance metrics and identify individuals who might need assistance, among other applications.

Business intelligence for big data

BI platforms are increasingly being used as front-end interfaces for big data systems that contain a combination of structured, unstructured and semistructured data. Modern BI software typically offers flexible connectivity options, enabling it to connect to a range of data sources. This, along with the relatively simple user interface ( UI ) in most BI tools, makes it a good fit for big data architectures.

Users of BI tools can access Hadoop and Spark systems, NoSQL databases and other big data platforms, in addition to conventional data warehouses, and get a unified view of the diverse data stored in them. That enables a broad number of potential users to get involved in analyzing sets of big data, instead of highly skilled data scientists being the only ones with visibility into the data.

Alternatively, big data systems serve as staging areas for raw data that later is filtered and refined and then loaded into a data warehouse for analysis by BI users.

Business intelligence trends

In addition to BI managers, business intelligence teams generally include a mix of BI architects, BI developers, BI analysts and BI specialists who work closely with data architects, data engineers and other data management professionals. Business analysts and other end users are also often included in the BI development process to represent the business side and make sure its needs are met.

To help with that, a growing number of organizations are replacing traditional waterfall development with Agile BI and data warehousing approaches that use Agile software development techniques to break up BI projects into small chunks and deliver new functionality on an incremental and iterative basis. Doing so enables companies to put BI features into use more quickly and to refine or modify development plans as business needs change or new requirements emerge.

Other notable trends in the BI market include the following:

The proliferation of augmented analytics technologies . BI tools increasingly offer natural language querying capabilities as an alternative to writing queries in SQL or another programming language, plus AI and machine learning algorithms that help users find, understand and prepare data and create charts and other infographics.
Low-code and no-code development. Many BI vendors are also adding graphical tools that enable BI applications to be developed with little or no coding.
Increased use of the cloud. BI systems initially were slow to move to the cloud, partly because data warehouses were primarily deployed in on-premises data centers. But cloud deployments of both data warehouses and BI tools are growing; in early 2020, consulting firm Gartner said most new BI spending is now for cloud-based projects.
Efforts to improve data literacy . With self-service BI broadening the use of business intelligence tools in organizations, it's critical to ensure that new users can understand and work with data. That's prompting BI teams to include data literacy skills in user training programs. BI vendors have also launched initiatives, such as the Qlik-led Data Literacy Project.

Business intelligence vs. data analytics and business analytics

Sporadic use of the term business intelligence dates back to at least the 1860s, but consultant Howard Dresner is credited with first proposing it in 1989 as an umbrella phrase for applying data analysis techniques to support business decision-making processes. What came to be known as BI tools evolved from earlier, often mainframe-based analytics technologies, such as decision support systems and executive information systems that were primarily used by business executives.

Business intelligence is sometimes used interchangeably with business analytics . In other cases, business analytics is used either more narrowly to refer to advanced analytics or more broadly to include both that and BI. Meanwhile, data analytics is primarily an umbrella term that encompasses all forms of BI and analytics applications. That includes the main types of data analysis: descriptive analytics, which is typically what BI provides; predictive analytics, which models future behavior and outcomes; and prescriptive analytics, which recommends business actions.

Get the most of your data, reap the benefits of BI tools

Top 8 business intelligence challenges and how to handle them

7 key steps to deploy a modern business intelligence strategy

Continue Reading About business intelligence (BI)

What does a business intelligence analyst do?
8 self-service BI best practices for larger organizations
8 tips and best practices for good BI dashboard design

Related Terms

Dig deeper on business intelligence management.

self-service business intelligence (self-service BI)

business intelligence architecture

Augmented analytics, decision intelligence power modern BI

Traditional BI vs. self-service BI shouldn't be a choice

Deploying databases on different cloud platforms offers various benefits. Here's a set of 10 best practices for building a ...

The vendor's latest new features aim to help customers improve model accuracy by securely developing compound systems that ...

Any effective data quality process needs data profiling. Evaluate key criteria to select which of the top 10 data profiling tools...

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

AWS users face a choice when deploying Kubernetes: run it themselves on EC2 or let Amazon do the heavy lifting with EKS. See ...

Implementing an ECM system is not all about technology; it's also about the people. A proper rollout requires feedback from key ...

Incorporating consulting services and flexible accommodations for different LLMs, developer-focused Contentstack offers its own ...

As SharePoint 2019 approaches its end of life, users can expect reduced support. Migration to newer platforms like SharePoint ...

With its Cerner acquisition, Oracle sets its sights on creating a national, anonymized patient database -- a road filled with ...

Oracle plans to acquire Cerner in a deal valued at about $30B. The second-largest EHR vendor in the U.S. could inject new life ...

The Supreme Court ruled 6-2 that Java APIs used in Android phones are not subject to American copyright law, ending a ...

SAP talked a lot about artificial intelligence (AI) and generative AI at its annual Sapphire customer event in Orlando last week....

SAP showcases new Business AI applications and continues to make the case for S/4HANA Cloud as the future of SaaS-based ERP ...

SAP acquires the digital adoption platform vendor in a bid to expand its portfolio of applications that helps customers moving ...

Announcements

Microsoft Copilot Studio: Building copilots with agent capabilities

By Omar Aftab

Copilot category
Copilot Studio

At Microsoft Build 2024 , we’re excited to announce a host of new powerful capabilities in Microsoft Copilot Studio —t he single conversational AI tool you can use to create your very own custom copilots or extend Microsoft C opilot experiences with your own enterprise data and scenarios. The first of these are c opilots that can now act as independent agents— ones that can be triggered by events— not just conversation— and can automa te and orchestrate complex, long-running business processes with more autonomy and less human intervention.

For instance, consider the potential of a copilot that can react when an email arrives, look up the sender’s details, see their previous communications, and use generative AI to trigger the appropriate chain of actions in their response. From understanding the intent of the email, to look ing up the sender’s details and account , see ing their previous communications, checking inventory, responding to the sender asking for their preferences, and then taking the appropriate actions to close a ticket — orchestrating and shepherding an entire process over days.

IT help desk . IT support is complex, involving tickets, order numbers, approvals, and stock levels . O pening and closing a ticket can be a long-running task that spans days. A copilot can now handle this process, interfacing with IT service management applications, resolving IT tickets with context and memory, creating purchase orders for device refresh, and reaching out and getting managers approvals — all independently .
Employee onboarding . Onboarding new employees is often expensive and slow. Now, imagine you’re a new hire. A copilot greets you, reasons over HR data, and answers your questions. It introduces you to your buddy, provides training and deadlines, assists with forms, and sets up your first week of meetings. Throughout all of this, the copilot is in touch, guiding you through the weeks -long onboarding and account set up processes.
Personal concierge for sales and service . Balancing exceptional customer experience while meeting ambitious revenue goals can be challenging. When a copilot serves guests, i t can use the memory of previous conversations with guests to remember their preferences, make reservations, handle complaints, and answer questions related to the products and services on offer. The copilot learns from its interactions and proposes new ways of handling customer scenarios. By doing so, copilots can increase upsell and attachment rates, driving revenue for the resort while simultaneously enhancing guest experience, satisfaction rates, and repeat business.

Let’s dig deeper into a few of the underlying capabilities that make all this possible:

Asynchronous orchestration of complex tasks . The first is the ability to use generative AI- powered planning and reasoning to manage complex, multi step, long-running tasks. For example, reacting to a new order means determining the need to verify inventory, trigger ing the right payment processes, pinging a supervisor for approval if the amount is above a certain threshold, and replying with a confirmation. Many of these events can take hours—or even days— to complete, but the copilot will run through them , maintaining the necessary state and context to do so.
Memory and context . One of the frustrating things about support has traditionally been having to repeat information: who you are, what your policy number is, what your address is. There is no continuity of conversation. Copilots will now learn from previous conversations from the users and utilize this knowledge to continually personalize interactions . A copilot may not need to ask you for your laptop model or your address when you call again for the same issue. Conversations will thus become long-running, contextual, and deeply personalized.
Monitor, learn, and improve . Copilots can now learn and adapt, offering monitoring and teaching capabilities to make their interactions better. Each copilot records a comprehensive history of its activities, providing transparency into its performance, including user interactions, actions taken, and feedback received, and you can see what decisions it made — and correct and teach them — with just a few clicks.

Delegation with confidence and guardrails . When developing copilots with agent capabilities, establishing clear boundaries is paramount. Copilots operate strictly within the confines of the maker-defined instructions, knowledge, and actions. The data sources linked to the copilot adhere to stringent security measures and controls, managed through the unified admin center of Copilot Studio. This includes data loss prevention, robust authentication protocols, and more.

The se advanced new capabilities in Copilot Studio are currently accessible to customers participating in an Early Access Preview where organizations such as Centro de la Familia are excited to explore agent capabilities that support teachers and case workers, allowing them to spend less time on administrative tasks and more time working with children, ultimately leading to better child outcomes . Based on feedback from program participants, we will continue to iterate and refine these capabilities for broader access in a preview planned for later this year .

Additional innovations with Copilot Studio

There’s a lot more to share at Microsoft Build with Copilot Studio, and we’ll touch on just a few of our new capabilities here. To learn more — just sign up and try it out for yourself here .

Screenshot of the homepage of Microsoft Copilot Studio

Here are a few examples of how Copilot connectors can transform copilot experiences for specific personas or functions:

Legal and Compliance . Navigate complex legal landscapes with a Copilot extension that queries specific legal datasets, ensuring controlled and compliant responses without overwhelming users with extraneous information.
HR Helper . Assist employees with accessing essential resources for benefits and PTO policies, and even book time off directly through Copilot.
Incident Report Coordinator . Workers can locate the right documentation, report incidents, and track them efficiently, all within the context of the chat.

Starting in June 2024, developers can access the public preview for Copilot connectors and stay informed on updates here .

Conversational analytics (private preview) : One of the most common asks from customers has been the need for deeper insight into what their copilot is doing, how generative AI is responding, when it was unable to give the right answers and why — and recommendations on what to do to improve it.

Screenshot of the conversational analytics experience in Microsoft Copilot Studio

Enhanced security and controls (public preview ) : Administrators can now configure advanced settings beyond the default security measures and controls. With Microsoft Purview , Copilot Studio administrators gain access to more detailed governance tools, including audit logs, inventory capabilities, and sensitivity labels. They will be able to review comprehensive audit logs that cover tenant-wide usage, inventory (with API support), and tenant hygiene (such as data loss prevention violations and inactive copilots), enabling them to effectively monitor business impact. Both creators and end-users will be able to view sensitivity labels when responses are generated using AI-powered answers based on SharePoint documents.

With all the amazing innovations, numerous organizations are using Copilot Studio to build transformative generative AI-powered solutions. Check out this story from Nsure on how they are using Copilot Studio:

Get started today with Copilot Studio

This is just a glimpse of all the exciting innovation around copilots and Copilot Studio — we have a host of exciting new capabilities to share in our sessions at Build. So, join us in watching the sessions below, and try out Copilot Studio yourself and build and share your very own copilot in minutes.

Watch the sessions at Microsoft Build:

“ Microsoft Build opening keynote ”
“ Next generation AI for developers with the Microsoft Cloud ”
“ Shaping next-gen development: the future of Copilot in Power Platform ”

Deeper dives:

Breakout: “ What’s new with Microsoft Copilot Studio ”
Breakout with demos: “ Build your own copilot with Microsoft Copilot Studio ”
Breakout with demos: “ Build Microsoft Copilot extensions with Copilot Studio ”
Demo (live only): “ Build your own Copilot extension with Microsoft Copilot Studio ”

Learn new skills, connect in real time, and grow your career in the Salesblazer Community.

What Is B2B Sales? Strategies & Best Practices

Three B2B salespeople sitting at a table talking and smiling

Learn the principles of business-to-business (B2B) sales strategy, and start boosting your revenue.

Kevin Thiele

Share article.

About $3 trillion — that’s Forrester’s estimate for B2B sales by 2027, almost double what it was in 2021. And B2B salespeople are a big reason why it’s growing.

But before you start dreaming of the commission that comes with big-ticket business sales, there’s a lot you need to know about connecting with buyers and influencing their decision to purchase products or services for their companies.

If you want to be successful in B2B sales, you need to understand the difference between B2B and B2C sales strategies. You must also understand the B2B sales process and how companies think about these big decisions.

What you’ll learn:

What is b2b sales, b2b sales vs. b2c sales: what’s the difference.

What is the B2B sales process?
How do you measure performance in B2B sales?

B2B sales best practices

Examples of b2b sales.

B2B sales tools

Drive pipe faster with a single source of truth

Discover how Sales Cloud uses data and AI to help you manage your pipeline, build relationships, and close deals fast.

In B2B (business-to-business) sales, one business sells goods or services to another. Because businesses typically require chains of approval, closing a B2B sales deal usually involves detailed touchpoints, presentations, product demos, and negotiations with decision-makers, leading to a long sales cycle.

Common traits of B2B sales

High-cost and/or recurring contract pricing. B2B sales transactions can run into the millions of dollars. Businesses also tend to invest in products/services for longer periods, owing to the cost/time investment involved in changing to a different solution.
Multiple stakeholders. Decision makers will have different agendas, requirements, and needs for the transaction. They stretch from mid-level managers all the way up to the C-suite.
Longer close time. Given the above, B2B sales are more involved and take longer to close.

B2B sales is when a business sells a product or service to another business. B2C sales is when a business sells a product or service directly to a consumer. Because the buyer in these situations has different intent, needs, and requirements, the sales process and deal timeframe are also different:

B2B sales focuses on long-term relationships. These sales are often complex, with large deal sizes and multiple stakeholders to navigate. B2B buyers need to understand the potential return on investment (ROI) and how a product or service will ultimately benefit their business before they move forward with a purchase. For example, a B2B deal might involve purchasing and onboarding new AI software for hundreds of employees. This likely costs thousands of dollars and touches multiple teams, so they’re are many stakeholders who need to review and approve the deal.
B2C sales target short-term transactions. These are typically simpler and lower-cost products or services, so individual customers can make quicker decisions. Because of this, the path to purchase is also shorter. For example, you might impulse-buy a sweatshirt from an Instagram ad or a candy bar while you wait in line at the grocery store.

What is the B2B sales process and who leads it?

Companies that sell B2B have dedicated sales teams that reach out to prospects — sales associates, account executives, and sales representatives. These salespeople find and follow up with prospects and work through the complex and layered B2B sales process:

Because B2B sales requires so many stakeholders to get involved, however, every company will have a different process. That said, there are some core elements that every salesperson will likely experience. Let’s look at what these are in more detail.

Lead generation or prospecting . Sales and marketing teams identify potential customers, either via ads that attract interested prospects or via outreach based on research (more on that below).
Lead qualification . Sales teams assess the product fit of potential customers.
Needs assessment. Sales teams uncover the detailed needs of potential customers they’ve qualified.
Proposal and quote . Sales teams present a tailored solution to the potential client.
Negotiation. Sales teams work out the terms of the deal.
Close . Sales teams finalize and process the details of the sale.

As a sales rep, it’s important to use technology to your advantage to streamline the process. AI sales tools are great for organizing information, like keeping track of leads and where you are in a deal’s process.

Get articles selected just for you, in your inbox

What are the essential b2b sales activities during the sales process.

B2B sales activities are designed to identify and attract prospective customers and then engage and close deals with customers in need of your products or services. Sales activities can vary based on your industry and what your organization offers, but some are essential to every sales process . Here are a few examples:

Customer research is the first step in B2B sales. Start by creating an ideal buyer profile for your product and explore their motivations for purchasing by talking to customers of similar businesses, and by reviewing online reports and information. This profile should also include characteristics such as demographics, psychographics (prospect behaviors), and communication preferences. All of this will inform whom you look for in your prospecting
Outreach is how you stay in contact with prospective clients. You can reach out in many ways: phone calls, texts, emails, in-person conferences and events, and online networking platforms like LinkedIn. Your approach will vary based on the client and their needs.
Customer relationship management helps you build long-term relationships with your customers that lead to loyalty and retention. Because B2B sales can take a long time to close, managing and nurturing these relationships is a key skill for you to develop. That’s why you should set up a cadence of communication to make sure prospects’ needs are being met.
Sales reporting is an overview of key sales metrics . Some of these metrics focus on prospect behavior, like email open and click-through rates, while some focus on your behavior, like how many calls you schedule per week and how many deals you close. Over time, you can use the data you collect to inform and refine your approach to B2B sales.

What are the most important B2B sales metrics?

Tracking sales metrics is essential because they give you an unbiased look at how reps perform individually and as a team. It also gives you a sense of how close you are to hitting your targets, and if you need to adjust strategy to increase sales.

Here are some key metrics to keep in mind for B2B sales:

New leads in pipeline: The number of new leads added to each rep’s pipeline during a single quarter.

Conversion rate: The number of new leads added to each rep’s pipeline during a single quarter.

Annual contract value (ACV): This is the average sales amount of a customer contract over the course of a year.

Customer lifetime value (CLV): The value of all purchases, including upsells, cross-sells, and renewals, that a customer makes over the course of their relationship with your company.

Read our article on sales key performance indicators (KPIs) for a more in-depth look at what you can (and should) be tracking.

How do you use metrics and data to improve your B2B sales process?

The depth of data available about market trends, customer behavior, and the effectiveness of various sales tactics can be helpful in tweaking your sales process approach. Here’s a look at how you can use data to improve your performance:

Targeting the right prospects. Data about your prospects, especially from your sales tools , can help you target the best leads for the products and services you sell.
Personalizing messages and sales pitches. With more data about your target customers, you can better personalize and customize the pitches you send. Personalization will help you connect more with your prospects and increase your likelihood of success.
Lead prioritization. With up-to-date sales data, you can create lead-scoring rubrics to identify which leads are most likely to convert. From there, you can prioritize leads and, ideally, increase win rates.
Forecasting sales for company planning. Sales data can help you predict outcomes and make highly accurate forecasts about future sales and revenue. This is key to planning budgets, pay, and targets for the company.

How do you measure B2B sales performance?

Knowing the right B2B sales metrics to track is all well and good, but how do you track it? Via a comprehensive sales dashboard. A dashboard lets you see all the most relevant information about past, current, and pending sales so that you can make better decisions that drive better win rates. It also aggregates completed sales data so that you can measure sales performance over periods of time, such as year-over-year or over a specific quarter. All of this can be used to inform sales strategies , hiring decisions, and tactics.

3 Ways Generative AI Will Help Marketers Connect With Customers

Illustrating of Einstein character surrounded by 3 Trailhead badges for AI skills

Learn AI Skills on Trailhead

You can get better at B2B sales through study, practice, and reflection. Here are some B2B sales quick tips to keep in mind:

Understand your prospect’s pain points and goals . Focus on getting to know your future customer and empathizing with their challenges. Then, make a strong case that shows how your goods or services will give them a meaningful return on their investment. One way to do this is by talking with them directly, but you can also subscribe to their content — social media, email newsletters, blogs — to get an idea of their business priorities, who their audience is, and how to speak their language when offering your solution.
Build relationships with the top decision-makers. Rather than spend valuable time making connections with people who can’t actually make any purchase decisions, whenever possible, go straight to the top. Research a company’s real decision-makers and reach out to them directly. Don’t waste time with middle managers who don’t have the authority to make choices or close deals.
Sell solutions and results, not products. To reach people and make a lasting impact, it’s important to sell them not on your product, but on how your product will change their lives for the better. The proof is in the results, so show prospects — through data, success stories, and first-hand knowledge — how your product can solve their problems and increase their bottom line.
Focus on simplicity . Businesses want to know how your product or service will make their lives easier, not more complicated. Make sure to emphasize how easy it is to integrate your software into their existing processes, for example. And, make sure they know you’ll provide training and ongoing support. The simpler your solution is, the sooner they can start using it and see results.
Respect your prospect’s time . Yes, you want to make a sale, but you must be cognizant and respectful of your prospect’s busy schedules. Never show up unannounced at their offices or call out of the blue and expect them to have the time (or desire) to talk to you. Make it a rule to set and keep appointments — both phone calls and face-to-face meetings — but also be flexible enough to accommodate your prospect’s schedule when necessary.

B2B sales can happen differently based on the type of company and industry involved. Here are four examples of B2B sales you are likely to see:

Manufacturing

Manufacturing B2B sales involves a company that either sells supplies or raw materials to another company that manufactures their own product, or produces a simple product that other companies buy and use in more complex products.

Example: A lumber company sells wood to a cabinet manufacturing company, which then creates kitchen cabinets to sell to its own customers.

Retail B2B sales involves businesses that sell retail products like clothing or electronics to other businesses. These businesses then repackage the products to sell to consumers.

Example: A clothing manufacturer sells sweaters to a boutique, which then resells the sweaters to its customers.

Government agencies of all kinds — from local to federal — need to buy products and services to support their own programs and services. These transactions are called business-to-government (B2G) sales.

Example: A global aerospace company builds helicopters, missile defense systems, fighter jets, and surveillance aircraft, among many other products, for the U.S. Department of Defense (DoD).

Software-as-a-Service (SaaS)

SaaS companies provide technology solutions to businesses to improve their operations, customer service/experience, and other business needs. SaaS B2B sales involve companies purchasing solutions or products for business purposes.

Example: A nonprofit education organization might buy a CRM tool to keep track of the employees in the school districts it serves.

B2B Sales Tools

Without sales tools, it’s impossible not to get bogged down in manual B2B activities and complex processes. But the right tools can help you sell faster, smarter, and more efficiently. Here’s a look at a few essential sales tools and how they can support you:

Customer relationship management (CRM) tools , like Sales Cloud , put all your communication data into one place, so it’s easier to keep track of where you are in the sales process.
Sales analytics can help you predict business outcomes with confidence by tracking B2B sales performance in real time and forecasting future results. By integrating with your CRM, analytics can track any activities associated with a sale. You can then use insights from your analytics to understand the health of your pipeline and close deals faster.
Sales AI can integrate with your CRM to automate the sales process, identify areas for improvement, and build strong relationships with prospective clients — all without manual input.

Grow your B2B sales knowledge and skills

The key to selling B2B products and services is to think of the process holistically and work to improve your approach over time. Because B2B selling is complex, there are many opportunities to improve, from understanding your company’s products and services to testing new sales tools to improve your processes. In the end, though, it’s all about building trust with decision-makers, so don’t forget to build strong relationships.

Learn 3 ways to sell faster with Salesforce CPQ

See how Salesforce CPQ helps sellers close faster, and companies launch new revenue models in days, not months.

Just For You

Social selling: people setting up a digital storefront

What Is Social Selling, and How Does It Work?

Personal Selling: A salesperson speaking to a potential customer holding a tablet.

Personal Selling: How To Build Better Customer Relationships and Close More Deals

Explore related content by topic

Sales Strategy
Salesblazer
Sales Fundamentals

Kevin is the Chief Revenue Officer of Sales Code. He helps sales leaders build high performance teams through his coaching and training programs. Kevin began his sales career at Yellow Pages and, moving into the technology sector, had the privilege of heading UK sales teams for top security vendors ... Read More including Blue Coat, SonicWall and Symantec. He is also a Gallup-Certified Strengths Coach and host of the popular Sales Code Leadership Podcast.

Get the latest articles in your inbox.

Sales Strategy Guide: 6 Steps to More Efficient Selling

Sales coaching: Two salespeople looking at a tablet

Sales Coaching: 10 Straightforward Tips That Work

Salesperson calculating price elasticity

The Ultimate Guide to Price Elasticity of Demand

Sales people sitting at a table and smiling while asking SPIN selling questions. Background is blue with quote icon.

What Is SPIN Selling? A Way to Build Trust With Your Customers

Salespeople sharing their unique value proposition.

What Is a Unique Selling Proposition (USP) and How Do You Craft One That Works?

Salesperson presenting a QBR to customers.

What Is a QBR? (And How to Plan One Your Customers Will Appreciate)

Sales engineer: two sales team members looking at a computer.

What Is a Sales Engineer, and What Do They Do?

A salesperson views charts on his laptop and paper to calculate sales turnover.

What Is Sales Turnover and How Does it Help With Smarter Inventory Management?

New to Salesforce?

What is Salesforce?
Best CRM software
Explore all products
What is cloud computing
Customer success
Product pricing

About Salesforce

Salesforce.org
Sustainability

IMAGES

Guideline: Business Use-Case Model
How to Find Use Cases from Business Process (BPMN)?
analysis
Use case of business process modeling examples
How to Find Use Cases from Business Process (BPMN)?
Guideline: Business Use-Case Model

VIDEO

Business Process Model with Innovator for Business Analyst
Stats Café: Vital Statistics Business Process Model: a new process-centric approach to improve CRVS
Understanding the PROCESS VIEW wit ARIS
6 Business Process Model and Notation BPMN
Процессное управление простыми словами или понятно про бизнес-процесс
How to write a Use Case Description with a template?

COMMENTS

What Comes Before The Use Case Model?
Business Process Model. Producing a model of the business process or processes that are relevant will help towards this end. If the business is undergoing a change, it is useful to see how the business operates today and how it will operate in the future which, in essence, are the 'As Is' (i.e. today) business processes and the 'To Be' (i.e. the future) business processes.
Use cases or business process maps, what technique to use?
These techniques are mainly used to create solution design and they are business process maps, use cases, user stories, wireframes and business rules. Sometimes even business analysts are confused how they should create solution design and what techniques they should use. Mainly this confusion is about two popular techniques - use cases and ...
Uncovering the Difference Between Business Cases and Use Cases
A business case typically outlines the potential value (often expressed in terms of financial returns) of a product, while a use case focuses on the practical applications of the product. Business cases often involve an analysis of market trends, customer demand, and competitor offerings to calculate potential returns, whereas use cases examine ...
What Is Business Process Modeling?
A business process model is a graphical representation of a business process or workflow and its related sub-processes. Process modeling generates comprehensive, quantitative activity diagrams and flowcharts containing critical insights into the functioning of a given process, including the following: Events and activities that occur within a ...
Business Process Modeling Use Cases and Definition
Business process modeling offers visibility into existing processes and helps design new processes that will deliver results in a post-merger environment. The latest guide from the erwin Experts expands on these use cases and details how best to use business process modeling to tame your organization's complexity and maximize its potential ...
How to Find Use Cases from Business Process (BPMN)?
The transition relationship enables you to trace the business process model from use case model (and vice versa). Let's try. Place the mouse pointer over the Place Order use case. Click on the Model Transitor resource at bottom right corner of shape. Select Transit From > Distilled Water Ordering Process.Place Order from the popup menu.
What is a Business Use Case?
A use case is a written, detailed description of how an end user (i.e., customer) uses a system or product. The purpose of writing a use case is so you can specifically understand the step-by-step interactions between your customer and your system or products. To put it really simply, writing a use case is about the journey, not the destination ...
Why Model Business Processes?
A use case provides an individual narrative, where a process model will collect all relevant narratives in one model. UML vs. BPMN. The two most widely used notations are Unified Modeling Language (UML) and Business Process Model Notation (BPMN). With the introduction of BPMN, UML is being used more for systems modeling and BPMN has surpassed ...
From Business Process Models to Use Case Models: A ...
A use case model is a set of use case diagrams and the corresponding use case. descriptions [9]. The use case diagrams enable to perceive the need of describing. the system behavior in response to ...
From Business Process Models to Use Case Models: A ...
A business process model identifies the activities, resources and data involved in the creation of a product or service, having lots of useful information for developing a supporting software system. During system analysis, most of this information must be incorporated into use case descriptions. This paper proposes an approach to support the ...
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 ...
uml
Use cases in contrast primarily aim to describe the added value, a system delivers to an actor. So that's something very, very basic. Use cases also have means to express how process steps are executed (using Activities and Actions). You find the same in BPMN and for the very same purpose. But, where Use Cases end, BPMN will start.
Business Process Modeling Techniques with Examples
Business process modeling is mainly used to map a workflow so you can understand, analyse and make positive changes to that workflow or process. Usage of diagram helps you to visualize this process and make better decisions. Use the below table to quickly navigate to different techniques.
Process Modeling in '23: Top 5 Use Cases & Case Studies
Process modeling is the practice of visualizing business processes and workflows. By including every individual step, process models provide an end-to-end overview of the tasks and activities in business processes. Process modeling reveals insights about: Events and activities in a workflow. The people involved in these activities and events.
Understanding Use Case Diagrams vs. Process Flow Diagrams: A Business
3. Interaction vs. Flow. Use Case Diagrams: These diagrams emphasise the interactions between actors and the system. They answer questions about what functionality the system provides and how ...
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).
Use Case Diagram
A use case is the action that is performed within the system. It is usually represented as a combination of a verb and a noun, e.g. "deliver product", "prepare invoice", etc. The <<uses>> and <<includes>> text when added to a relationship and drawn from A to B means that doing A involves doing B at least once.
Use Case Diagram Tutorial (Guide with Examples)
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 ...
Business Case vs. Use Case
Business Cases are generally less flexible than Use Cases. Once a Business Case is approved, it sets the foundation for the project's scope, objectives, and budget. Any changes to the project's scope or budget require a formal review and approval process. On the other hand, Use Cases are more flexible and can be updated or modified throughout ...
Top business process modeling techniques with examples
Select a process in greatest need of improvement, map all the steps in the process flow using business process management methods, and diagram and document the entire process visually using the selected modeling technique. Business process modeling can then spot potential delays, redundancies and opportunities for much-needed improvement in the ...
Use Cases and Business Rules: Can They Work Together?
Be that as it may, we are finding that in doing business process models, use cases, and business rules that the notion of a Decision Model (managed by business analysts or actual business people) is valuable because the same Decision Models are shared across use cases and across many business process models and systems.
System use case Vs. Business use case
Business Use Cases form part of the user requirements specification, and define the scope of User Acceptance Testing; System Use Cases should focus on the part of the process to be implemented by the system in question: normally be written at a level of detail equivalent to a detailed functional specification. - Felix Aballi.
Top 7 Business Process Modeling Tools and Software
3. Kissflow. Kissflow offers individual business management tools, including case management, process management, project management, and collaboration. This platform also includes a comprehensive BPM solution - an excellent choice for larger organizations looking for a robust system to run many intricate processes. 4.
Process Flowchart VS Use Case Diagram
A process flowchart will usually be a graphical representation of how a business object like an order will flow through various business rules and system states. For a really complicated problem, you would use flowcharts first, then use case diagram. A good flowchart tool will save you lots of time. Edraw Max can draw both flowcharts and use ...
What is the difference between Use case and Use case model?
2. A Use case is a description of a single interaction between the user and the system. A Use case model is a description of a whole functionality described with many use cases. For example, if a system needs to manage some invoice related business process, then a use case model for such a process would consist of a use case describing steps ...
Advanced Analytics: Definition, Benefits, and Use Cases
Advanced analytics is an umbrella term referring to a range of data analysis techniques used primarily for predictive purposes, such as machine learning, predictive modeling, neural networks, and AI. Businesses employ advanced analytics primarily to forecast future outcomes and to guide their decision-making, not just to gain business insights.
What is Business Intelligence (BI)?
Business intelligence (BI) is a technology-driven process for analyzing data and presenting actionable information to help executives, managers and other corporate end users make informed business decisions.
Microsoft Copilot Studio: Building copilots with agent capabilities
With these new capabilities, here are some examples of the kinds of copilots our customers can build: IT help desk. IT support is complex, involving tickets, order numbers, approvals, and stock levels. O pening and closing a ticket can be a long-running task that spans days. A copilot can now handle this process, interfacing with IT service management applications, resolving IT tickets with ...
What Is B2B Sales? Strategies & Best Practices
B2B sales is when a business sells a product or service to another business. B2C sales is when a business sells a product or service directly to a consumer. Because the buyer in these situations has different intent, needs, and requirements, the sales process and deal timeframe are also different: B2B sales focuses on long-term relationships.
Claude vs. ChatGPT vs. Gemini: Picking the Right Model
Understanding AI Model Comparison With Use Cases. Finally, there are three more components you may want to consider based on your specific use case: ability to fine-tune, safety, and cloud providers. If you need to fine-tune a model and really understand what it is doing, ChatGPT-4 or Llama 2 will be your best bets.

What Comes Before The Use Case Model? | Business Use Cases Can Help

Table of Contents

Context Diagram

Business Process Model

Business Use Cases

Business Use Case Model

Use Case Model

Useful Links

Related Books

Recent Posts

Uncovering the Difference Between Business Cases and Use Cases

Essential Skills for Business Analysts

Don't forget to share this post!

GSA and DOD Schedules

CONTACT INFO

Business process modeling gives organizations a simple way to understand and optimize workflows by creating data-driven visual representations of key business processes.

What is business process modeling?

Key aspects of business process modeling

How business process models are made

Business process modeling use cases

Gaining 360-degree insight into processes

Optimizing and standardizing processes

Assessing new processes

Analyzing resource usage

Communicating processes

The benefits of business process modeling

Business process modeling and IBM

More from Automation

Scale enterprise gen AI for code generation with IBM Granite code models, available as NVIDIA NIM inference microservices

Maximizing SaaS application analytics value with AI

IBM Newsletters

Business Process Modeling Use Cases and Definition

Business Process Modeling Use Cases

The Regulatory Rationale for Integrating Data Management & Data Governance

Understand business process modeling.

What is a Business Use Case?

What is a use case?

Systems and software engineering

Product development

Use case vs. user story vs. process flow

Why you need a use case model for business processes

Breaks down large projects

Takes on customers' perspective

Prepares you for alternative outcomes and obstacles

Anatomy of a use case

Normal and alternative courses

Success scenarios and failure scenarios

How to write a business use case

Define your customer

Determine your customers’ goals

Map out your business use case model

Identify relationships between use cases

Write out user requirements specification

Improve business operations with efficient use cases

Dive deeper into the data

Related Topics

From Business Process Models to Use Case Models: A Systematic Approach

Access this chapter

Author information

Editor information

Rights and permissions

Copyright information

About this paper

Download citation

Share this paper

A Comprehensive Guide to Use Case Modeling

What is Use Case Modeling?

Key Concepts of Use Case Modeling

The Basics of Use Cases:

How to Perform Use Case Modeling?

Relationships Between Actors and Use Cases:

Creating Effective Use Cases:

Use Case Modeling Best Practices:

Use Case Modeling using Use Case Template

Granularity of Use Cases

References:

Leave a Comment Cancel reply

Stack Exchange Network

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

2 Answers 2