write business use case

• Contact Information

Blog: 7 Steps to Writing Business Use Cases

by IAG Webmaster | Nov 9, 2010 | Business Analysis , RDM | 0 comments

For Each Use Case:

1) Identify the Actors

Actor: Someone or something that interacts with, or uses, the system to achieve a desired goal

An actor may be: A user of the system. Describe the user by their role An individual who is not an user (customer, client, etc) The System under Discussion (SuD). Describe it as “the system” Another system (external entity)

2) Identify the Goal

Goal: The aim, or purpose – Goals summarize system functionality in terms of use from a business perspective

Identify the Goal: From the high-level scenario By brainstorming By asking “What does this Actor want to do?”

3) Define the Pre-Conditions

Pre-Condition: Something that must happen before the Use Case can start; something that must be in place before the Use Case can start

Identify Pre-Conditions by asking: “What must be in place for the Use Case to begin?” “How do you know you need to do this?”

4) Define the Post-Conditions

Post-Conditions: The result, or successful outcome of the Use Case

Identify the Post-Conditions by asking: “What is the successful result of this process or Use Case?”

5) Describe the Main Flow

Main Flow: Also known as Primary Scenario A single thread of events The simplest sequence – everything goes right Ideally, no branching – make a note of relevant variations Starts with pre-conditions and ends with post conditions

Describe the Main Flow by asking: “What must happen to achieve the goal / outcome?” “What does the actor need to do next?” “What might happen next?” “What do you need to do to get from the trigger to the outcome?”

6) Describe the Exceptions

Exceptions: Created to describe the failure situations Things that may go wrong in the Use Case

Discover exceptions by asking: “What could go wrong?”

7) Describe the Alternate Flows

Alternate Flows: Created to describe the variations to the Main Flow Results in successful outcome Also referred to as scenarios Listen for “sometimes”, “maybe”, and “it depends”

Discover alternate flows by asking: “What might affect this Use Case?”

Click here for more Business Analysis Resources

Submit a Comment Cancel reply

You must be logged in to post a comment.

Blog Posts by Category

• EXPLORE Coupons Tech Help Pro Random Article About Us Quizzes Request a New Article Community Dashboard This Or That Game Popular Categories Arts and Entertainment Artwork Books Movies Computers and Electronics Computers Phone Skills Technology Hacks Health Men's Health Mental Health Women's Health Relationships Dating Love Relationship Issues Hobbies and Crafts Crafts Drawing Games Education & Communication Communication Skills Personal Development Studying Personal Care and Style Fashion Hair Care Personal Hygiene Youth Personal Care School Stuff Dating All Categories Arts and Entertainment Finance and Business Home and Garden Relationship Quizzes Cars & Other Vehicles Food and Entertaining Personal Care and Style Sports and Fitness Computers and Electronics Health Pets and Animals Travel Education & Communication Hobbies and Crafts Philosophy and Religion Work World Family Life Holidays and Traditions Relationships Youth
• EDIT Edit this Article
• PRO Courses Guides New Tech Help Pro Expert Videos About wikiHow Pro Upgrade Sign In
• Browse Articles
• Learn Something New
• This Or That Game New
• Train Your Brain
• Explore More
• Support wikiHow
• About wikiHow
• H&M Coupons
• Hotwire Promo Codes
• StubHub Discount Codes
• Ashley Furniture Coupons
• Blue Nile Promo Codes
• NordVPN Coupons
• Samsung Promo Codes
• Chewy Promo Codes
• Ulta Coupons
• Vistaprint Promo Codes
• Shutterfly Promo Codes
• DoorDash Promo Codes
• Office Depot Coupons
• adidas Promo Codes
• Home Depot Coupons
• DSW Coupons
• Bed Bath and Beyond Coupons
• Lowe's Coupons
• Surfshark Coupons
• Nordstrom Coupons
• Walmart Promo Codes
• Dick's Sporting Goods Coupons
• Fanatics Coupons
• Edible Arrangements Coupons
• eBay Coupons
• Log in / Sign up
• Finance and Business
• Running a Business

How to Write a Use Case

Last Updated: March 24, 2023

This article was co-authored by Michael R. Lewis . Michael R. Lewis is a retired corporate executive, entrepreneur, and investment advisor in Texas. He has over 40 years of experience in business and finance, including as a Vice President for Blue Cross Blue Shield of Texas. He has a BBA in Industrial Management from the University of Texas at Austin. This article has been viewed 170,415 times.

Write a use case to explore and highlight the value of your business, industry or computer system. Use cases can be valuable tools for understanding a specific system's ability to meet the needs of end users. When designing software or a system, enhance your development efforts by thinking through practical scenarios about product usefulness. Use cases can also be effective for product marketing purposes. Here are some steps to guide you through the writing process.

Defining the Purpose and Scope

• For example, you could write use cases about logging into a system, managing an account or creating a new order.

• For example, if you were writing a use case about how an ATM functions, the stakeholders would include the bankers and the ATM owners. They are not present when the user uses the ATM to withdraw cash. However, they must be satisfied that systems are in place to verify the amount of money in the user’s account before dispensing cash and to create a log of transactions in the event of a dispute.

• For example, if you were writing a use case implementing software to create purchase orders, topics that would be In would include producing reports about requests, merging requests to a purchase order, monitoring deliveries, and new and existing system software. Topics that would be Out would include creating invoices and non-software parts of the system.

Writing the Steps of a Use Case

• Users are all of the people who will engage in the activities described in the use case. For example, if you are writing a use case for logging into a software system, the users would be anyone who must log in.
• Preconditions are those elements that must be in place prior to the start of the use case. For example, users with permission to use the system have been identified and entered into the system ahead of time, so the system will recognize their usernames and passwords when entered.
• The basic flow is the procedure the users use to achieve the primary goal of the system and how the system responds to their actions. For example, the user inputs a username and a password, and the system allows the user in.
• Alternate flows explain less common actions. For example, the user is on a different computer and must answer a security question.
• Exception flows detail what happens when the user cannot achieve the goal. For example, the user inputs an invalid user name or password.
• Post conditions are those elements that must be present when the use case is completed. For example, the user can proceed to use the software.

• Alternate flows and exception flows are written to describe the actions when there are obstacles to the goal.
• If the user is denied access because the system didn’t recognize her computer, she may be prompted to verify her identity by answering a security question.
• If the user inputs an invalid username or password, she may be prompted to answer a security question and enter an e-mail address to receive new log in information.

Writing Valuable Use Cases

• Get the level of detail right. For example, if writing a use case about implementing technology, don't exclude details about how the software responds to users.
• Alternatively, adding too much detail about how the software functions reads more like system design implementation than a use case.

Expert Q&A

You might also like.

• ↑ https://www.techtarget.com/searchsoftwarequality/definition/use-case
• ↑ http://www.bridging-the-gap.com/what-is-a-use-case/
• ↑ https://www.usability.gov/how-to-and-tools/methods/use-cases.html

About This Article

If you need to write a use case, write a brief introduction describing the primary goals of implementing a new technology or business process. Define the preconditions that must be in place prior to the start of the use case, then detail the basic flow, or the procedure used to implement the process. Include any alternate flows, or less common scenarios that may arise, as well as exception flows, or what happens when the user can’t achieve their goal. Conclude with the post conditions, or the elements that must be present when the use case is completed. For tips from our financial reviewer on describing the users and stakeholders in your use case, read on! Did this summary help you? Yes No

• Send fan mail to authors

Reader Success Stories

Fung Suan Lim

Dec 21, 2017

Did this article help you?

Aug 25, 2016

Featured Articles

Trending Articles

Watch Articles

• Terms of Use
• Privacy Policy
• Do Not Sell or Share My Info
• Not Selling Info

wikiHow Tech Help Pro:

Level up your tech skills and stay ahead of the curve

How to Write a Use Case

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

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

In this tutorial, you’ll learn exactly how to apply use cases in your analytical work.

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

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

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

Why Write a Use Case

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

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

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

What is a Use Case?  

What is a use case? How does it solve these problems for us as analysts, as technical people, as business users? It’s a textual description that captures the user system interaction.  This is really important. It’s the interaction between the user and a software system.

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

Example Use Cases

Some example use cases include:

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

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

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

Use Case Template: What’s Included  

You want to start with a name , and just like with a business process, you want that name to be verb-noun. So, “Purchase Course,” “Subscribe to Free Training,” not just “The Free Training Use Case.” You want to know: what is the action that user is taking that’s going to be described in the use case?   

Next is a brief description , and one of the things I really like to include in my brief description is a sentence that really gets clear about the scope. “This use case starts when…” and “This use case ends when…” because what happens when you start to write all those steps is you find all these variations. Then, all of a sudden, your use case is all over the place, and you’re like, “Laura, this isn’t a sequence of steps. It’s a web.” It’s usually because you’re going off track, or exploring alternates in too much detail, or really are just not staying within the scope of the steps that need to happen for the specific goal of that use case. “Starts when,” “Ends when.” Big tip.  

The actors : who are the users, or the roles, or the types of actors that might use the system? It’s not job title; it’s actor. Multiple people can fill that role with the system. It’s what the system can identify about you. Are you a purchaser? Are you an administrator? Are you a reporter? Something like that.  

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

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

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

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

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

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

Then, alternate flows and exception flows . These are the variant paths. Sometimes—Let’s just see an example. For “Watch Video,” you might have “Pause.” You can pause the video. You can end the video (please don’t do that!). You can do different things. You can “Like” the video. You might have—Sometimes it might not fit within the scope of that use case but all the different things you can do. An exception flow might be: what happens if your Internet connection cuts out and the stream ends? How does that get presented to the user? Things that go wrong and keep people from, stopping reaching the end goal or the end of the use case.  

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

Use Cases Do Not Require Technical Knowledge  

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

Really, you’ve got to think of the use case as a tool that allows you to communicate about what the technology needs to do without actually knowing how it’s built because you’re not doing all those “Pong, pong, pong, pongs.” You’re not seeing all of the different pieces of the tech that happen behind the scenes. You’re saying, “As a user, what is my observable functionality? What do I see the system doing for me?” We should be able to be very clear about that as a business analyst. That’s part of the clarity we bring to the table.   

Use Cases Help You Ask Smart Questions

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

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

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

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

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

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

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

Download Your Use Case Template Today

Again, download that use case template here .

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

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

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

Use Cases vs. User Stories

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

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

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

(No formal experience required.)

Quick Start to Success as a Business Analyst

By signing up, you agree to our Privacy Policy .

• Contact Sales
• Get started

What Is a Use Case?

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

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

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

What is a use case? Use cases explained 

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

The history of the use case

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

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

What is the purpose of a use case? 

The purpose of a use case is to:

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

Why do project managers need to know about use cases?

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

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

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

How to write a use case for a project

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

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

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

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

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

What is a use case model?

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

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

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

Use case model example: 

(Source: Visual Paradigm Online )

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

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

Primarily, use case model diagrams are used to: 

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

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

Utilizing use cases with Wrike

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

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

Recommended Articles

Wrike recognized by trustradius for industry-leading usability and customer service.

Wrike earns two awards from TrustRadius for its best-in-class usability and customer...

A Quick Guide to Client Communication Skills

Client communication skills are crucial for delivering impressive work and retaining your...

Why Emotional Intelligence Matters in the Workplace (Infographic)

Strong emotional intelligence in the workplace is essential for project and team success....

Leading сompanies сhoose Wrike

• Project Templates
• Apps & Integrations
• CA Notice at Collection
• Project Management
• Product Development
• Professional Services
• For Project Managers
• For Marketers
• For Productivity
• For Collaboration
• Project Management Guide
• Types of project management software

For customers

• Help Center
• Interactive Training
• User Conference
• Wrike Status
• Wrike Support

For partners

• Wrike Partner Program

How Wrike helps you

• Salesforce project management
• Gantt charts
• Collaboration tools for students
• Task management
• Google project management tools
• Professional Services Guide
• Kanban Guide
• Agile Guide
• Remote Work Guide
• Return To Work Guide
• Marketing Guide
• Scrum Guide
• Product Management Guide
• Digital Marketing Guide
• Go-to-Market Guide
• Collaborative Work Management Guide

Latest in Wrike Blog

• How to Turn 404s From a Bad Experience to a Good One for Prospective Clients
• Wrike vs. Hive: Compare Hive Alternatives
• Pioneering AI In Work Management
• 5 Steps to Creating the Ultimate Risk Mitigation and Response Strategy
• Mastering Lead Source Evaluation for Better Marketing Results
• Unlocking Knowledge Potential: Tackling Common Issues in Knowledge Management Systems
• Overcoming Spreadsheet Shortcomings: How To Streamline Your Business Expense Tracking

Download our mobile app for your Android or iOS device

Subscribe to Wrike news and updates

Stay informed with the latest news and updates by subscribing to our marketing emails.

You are now subscribed to Wrike news and updates

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

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

• Contact sales

Start free trial

How to Write a Business Case (Template Included)

Table of Contents

What is a business case, how to write a business case, business case template, watch our business case training video, key elements of a business case, how projectmanager helps with your business case.

A business case is a project management document that explains how the benefits of a project overweigh its costs and why it should be executed. Business cases are prepared during the project initiation phase and their purpose is to include all the project’s objectives, costs and benefits to convince stakeholders of its value.

A business case is an important project document to prove to your client, customer or stakeholder that the project you’re pitching is a sound investment. Below, we illustrate the steps to writing one that will sway them.

The need for a business case is that it collects the financial appraisal, proposal, strategy and marketing plan in one document and offers a full look at how the project will benefit the organization. Once your business case is approved by the project stakeholders, you can begin the project planning phase.

Projects fail without having a solid business case to rest on, as this document is necessary to start the project and it’s the base for the project charter and project plan. But if a project business case is not anchored to reality, and doesn’t address a need that aligns with the larger business objectives of the organization, then it is irrelevant.

Get your free

Use this free Business Case Template for Word to manage your projects better.

The research you’ll need to create a strong business case is the why, what, how and who of your project. This must be clearly communicated. The elements of your business case will address the why but in greater detail. Think of the business case as a document that is created during the project initiation phase but will be used as a reference throughout the project life cycle.

Whether you’re starting a new project or mid-way through one, take time to write up a business case to justify the project expenditure by identifying the business benefits your project will deliver and that your stakeholders are most interested in reaping from the work. The following four steps will show you how to write a business case.

Step 1: Identify the Business Problem

Projects aren’t created for projects’ sake. They have a goal. Usually, they’re initiated to solve a specific business problem or create a business opportunity.

You should “Lead with the need.” Your first job is to figure out what that problem or opportunity is, describe it, find out where it comes from and then address the time frame needed to deal with it.

This can be a simple statement but is best articulated with some research into the economic climate and the competitive landscape to justify the timing of the project.

Step 2: Identify the Alternative Solutions

How do you know whether the project you’re undertaking is the best possible solution to the problem defined above? Naturally, choosing the right solution is hard, and the path to success is not paved with unfounded assumptions.

One way to narrow down the focus to make the right solution clear is to follow these six steps (after the relevant research, of course):

• Note the alternative solutions.
• For each solution, quantify its benefits.
• Also, forecast the costs involved in each solution.
• Then figure out its feasibility .
• Discern the risks and issues associated with each solution.
• Finally, document all this in your business case.

Step 3: Recommend a Preferred Solution

You’ll next need to rank the solutions, but before doing that it’s best to set up criteria, maybe have a scoring mechanism to help you prioritize the solutions to best choose the right one.

Some methodologies you can apply include:

• Depending on the solution’s cost and benefit, give it a score of 1-10.
• Base your score on what’s important to you.
• Add more complexity to your ranking to cover all bases.

Regardless of your approach, once you’ve added up your numbers, the best solution to your problem will become evident. Again, you’ll want to have this process also documented in your business case.

Step 4: Describe the Implementation Approach

So, you’ve identified your business problem or opportunity and how to reach it, now you have to convince your stakeholders that you’re right and have the best way to implement a process to achieve your goals. That’s why documentation is so important; it offers a practical path to solve the core problem you identified.

Now, it’s not just an exercise to appease senior leadership. Who knows what you might uncover in the research you put into exploring the underlying problem and determining alternative solutions? You might save the organization millions with an alternate solution than the one initially proposed. When you put in the work on a strong business case, you’re able to get your sponsors or organizational leadership on board with you and have a clear vision as to how to ensure the delivery of the business benefits they expect.

Our business case template for Word is the perfect tool to start writing a business case. It has 9 key business case areas you can customize as needed. Download the template for free and follow the steps below to create a great business case for all your projects.

One of the key steps to starting a business case is to have a business case checklist. The following is a detailed outline to follow when developing your business case. You can choose which of these elements are the most relevant to your project stakeholders and add them to our business case template. Then once your business case is approved, start managing your projects with a robust project management software such as ProjectManager.

1. Executive Summary

The executive summary is a short version of each section of your business case. It’s used to give stakeholders a quick overview of your project.

2. Project Definition

This section is meant to provide general information about your projects, such as the business objectives that will be achieved and the project plan outline.

3. Vision, Goals and Objectives

First, you have to figure out what you’re trying to do and what is the problem you want to solve. You’ll need to define your project vision, goals and objectives. This will help you shape your project scope and identify project deliverables.

4. Project Scope

The project scope determines all the tasks and deliverables that will be executed in your project to reach your business objectives.

5. Background Information

Here you can provide a context for your project, explaining the problem that it’s meant to solve, and how it aligns with your organization’s vision and strategic plan.

6. Success Criteria and Stakeholder Requirements

Depending on what kind of project you’re working on, the quality requirements will differ, but they are critical to the project’s success. Collect all of them, figure out what determines if you’ve successfully met them and report on the results.

7. Project Plan

It’s time to create the project plan. Figure out the tasks you’ll have to take to get the project done. You can use a work breakdown structure template  to make sure you are through. Once you have all the tasks collected, estimate how long it will take to complete each one.

Project management software makes creating a project plan significantly easier. ProjectManager can upload your work breakdown structure template and all your tasks are populated in our tool. You can organize them according to your production cycle with our kanban board view, or use our Gantt chart view to create a project schedule.

8. Project Budget

Your budget is an estimate of everything in your project plan and what it will cost to complete the project over the scheduled time allotted.

9. Project Schedule

Make a timeline for the project by estimating how long it will take to get each task completed. For a more impactful project schedule, use a tool to make a Gantt chart , and print it out. This will provide that extra flourish of data visualization and skill that Excel sheets lack.

10. Project Governance

Project governance refers to all the project management rules and procedures that apply to your project. For example, it defines the roles and responsibilities of the project team members and the framework for decision-making.

11. Communication Plan

Have milestones for check-ins and status updates, as well as determine how stakeholders will stay aware of the progress over the project life cycle.

12. Progress Reports

Have a plan in place to monitor and track your progress during the project to compare planned to actual progress. There are task tracking tools that can help you monitor progress and performance.

Again, using a project management tool improves your ability to see what’s happening in your project. ProjectManager has tracking tools like dashboards and status reports that give you a high-level view and more detail, respectively. Unlike light-weight apps that make you set up a dashboard, ours is embedded in the tool. Better still, our cloud-based software gives you real-time data for more insightful decision-making. Also, get reports on more than just status updates, but timesheets, workload, portfolio status and much more, all with just one click. Then filter the reports and share them with stakeholders to keep them updated.

13. Financial Appraisal

This is a very important section of your business case because this is where you explain how the financial benefits outweigh the costs. Compare the financial costs and benefits of your project. You can do this by doing a sensitivity analysis and a cost-benefit analysis.

14. Market Assessment

Research your market, competitors and industry, to find opportunities and threats

15. Competitor Analysis

Identify direct and indirect competitors and do an assessment of their products, strengths, competitive advantages and their business strategy.

16. SWOT Analysis

A SWOT analysis helps you identify your organization’s strengths, weaknesses, opportunities and threats. The strengths and weaknesses are internal, while the opportunities and threats are external.

17. Marketing Strategy

Describe your product, distribution channels, pricing, target customers among other aspects of your marketing plan or strategy.

18. Risk Assessment

There are many risk categories that can impact your project. The first step to mitigating them is to identify and assess the risks associated with your project activities.

ProjectManager , an award-winning project management software, can collect and assemble all the various data you’ll be collecting, and then easily share it both with your team and project sponsors.

Once you have a spreadsheet with all your tasks listed, you can import it into our software. Then it’s instantly populated into a Gantt chart . Simply set the duration for each of the tasks, add any dependencies, and your project is now spread across a timeline. You can set milestones, but there is so much more you can do.

You have a project plan now, and from the online Gantt chart, you can assign team members to tasks. Then they can comment directly on the tasks they’re working on, adding as many documents and images as needed, fostering a collaborative environment. You can track their progress and change task durations as needed by dragging and dropping the start and end dates.

But that’s only a taste of what ProjectManager offers. We have kanban boards that visualize your workflow and a real-time dashboard that tracks six project metrics for the most accurate view of your project possible.

Try ProjectManager and see for yourself with this 30-day free trial .

If you want more business case advice, take a moment to watch Jennifer Bridges, PMP, in this short training video. She explains the steps you have to take in order to write a good business case.

Here’s a screenshot for your reference.

Transcription:

Today we’re talking about how to write a business case. Well, over the past few years, we’ve seen the market, or maybe organizations, companies or even projects, move away from doing business cases. But, these days, companies, organizations, and those same projects are scrutinizing the investments and they’re really seeking a rate of return.

So now, think of the business case as your opportunity to package your project, your idea, your opportunity, and show what it means and what the benefits are and how other people can benefit.

We want to take a look today to see what’s in the business case and how to write one. I want to be clear that when you look for information on a business case, it’s not a briefcase.

Someone called the other day and they were confused because they were looking for something, and they kept pulling up briefcases. That’s not what we’re talking about today. What we’re talking about are business cases, and they include information about your strategies, about your goals. It is your business proposal. It has your business outline, your business strategy, and even your marketing plan.

Why Do You Need a Business Case?

And so, why is that so important today? Again, companies are seeking not only their project managers but their team members to have a better understanding of business and more of an idea business acumen. So this business case provides the justification for the proposed business change or plan. It outlines the allocation of capital that you may be seeking and the resources required to implement it. Then, it can be an action plan. It may just serve as a unified vision. And then it also provides the decision-makers with different options.

So let’s look more at the steps required to put these business cases together. There are four main steps. One, you want to research your market. Really look at what’s out there, where are the needs, where are the gaps that you can serve? Look at your competition. How are they approaching this, and how can you maybe provide some other alternatives?

You want to compare and finalize different approaches that you can use to go to market. Then you compile that data and you present strategies, your goals and other options to be considered.

And then you literally document it.

So what does the document look like? Well, there are templates out there today. The components vary, but these are the common ones. And then these are what I consider essential. So there’s the executive summary. This is just a summary of your company, what your management team may look like, a summary of your product and service and your market.

The business description gives a little bit more history about your company and the mission statement and really what your company is about and how this product or service fits in.

Then, you outline the details of the product or service that you’re looking to either expand or roll out or implement. You may even include in their patents may be that you have pending or other trademarks.

Then, you want to identify and lay out your marketing strategy. Like, how are you gonna take this to your customers? Are you going to have a brick-and-mortar store? Are you gonna do this online? And, what are your plans to take it to market?

You also want to include detailed information about your competitor analysis. How are they doing things? And, how are you planning on, I guess, beating your competition?

You also want to look at and identify your SWOT. And the SWOT is your strength. What are the strengths that you have in going to market? And where are the weaknesses? Maybe some of your gaps. And further, where are your opportunities and maybe threats that you need to plan for? Then the overview of the operation includes operational information like your production, even human resources, information about the day-to-day operations of your company.

And then, your financial plan includes your profit statement, your profit and loss, any of your financials, any collateral that you may have, and any kind of investments that you may be seeking.

So these are the components of your business case. This is why it’s so important. And if you need a tool that can help you manage and track this process, then sign up for our software now at ProjectManager .

Deliver your projects on time and under budget

Start planning your projects.

• Search for:
• Apple Numbers
• Apple Pages
• Software Testing
• White Paper Templates
• Business Process Design
• Software Development
• Writing Tips
• Action Plan Writing
• Business Plan Writing

No products in the cart.

Business Writing

How to write a business use case.

So, you want to write a business use case ? In this tutorial, we’ll look at how to write, structure, and format a use case. First, let’s define a business use case and explain how it differs from a system use case.

What is a business use case?

A business use case defines a sequence of actions that a business performs in order to produce observable results for an actor in that business.

It forms part of the user requirements specification, and define the scope of User Acceptance Testing. It describe the business requirements of the system to be developed, that is, from the point of view of a business user, not the underlying technology. In other words, a business use case is used to capture how a customer can make use of the business to get the result they want. For example, if the business in question was a bank, the use case might capture how a customer would apply for a credit card, renew a contract, or pay an invoice.

What’s the difference between a business use case and a system use case?

Business Use Case – The design scope of a Business Use Case is its business operations. It describes how an actor outside the organization, e.g. a customer, can achieve their goal with respect to the organization. In general, it does not mention the technology. It’s more concerned with how the business operates.

System Use Case – The design scope of a System Use Case is the computer system. It describes how an actor, e.g. another software program, achieves a goal with the computer system.

Different Categories of Business Use Cases

According to the Rational Unified Process (RUP), business activities include three main categories of work:

• Commercially important activities, often called business processes.
• Activities that are not that commercially important, but must be performed, such as systems administration, cleaning and security.
• Management work that captures the business’ relationships, such as executive level roles and regular employees.

What is a business use case template?

This Business Use Case template includes instructions on how to write your first business use case instance. It describes the difference between business use cases and system use cases, and provides different layouts you can modify to document your business use case.

Each section in the template includes guidelines to help you populate the template and ensure that your document captures the necessary information to design your business solution.

• Format: MS Word
• Number of Pages: 14
• Language: English

To learn more, visit the Business Use Case page on our store.

Anthony James

Username or email address  *

Password  *

Remember me Log in

Lost your password?

Usability.gov is archived and no longer updated

External links may not function and information on the site may be out of date. Visit digital.gov for current information.

• What & Why of Usability
• Get Involved

Home > How To & Tools > Use Cases

A use case is a written description of how users will perform tasks on your website.  It outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.

Benefits of Use Cases

Use cases add value because they help explain how the system should behave and in the process, they also help brainstorm what could go wrong.  They provide a list of goals and this list can be used to establish the cost and complexity of the system. Project teams can then negotiate which functions become requirements  and are built.

Elements of a Use Case

Depending on how in depth and complex you want or need to get, use cases describe a combination of the following elements:

• Actor – anyone or anything that performs a behavior (who is using the system)
• Stakeholder – someone or something with vested interests in the behavior of the system under discussion (SUD)
• Primary Actor – stakeholder who initiates an interaction with the system to achieve a goal
• Preconditions – what must be true or happen before and after the use case runs.
• Triggers – this is the event that causes the use case to be initiated.
• Main success scenarios [Basic Flow] – use case in which nothing goes wrong.
• Alternative paths [ Alternative Flow] – these paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level.

How To Write a Use Case

Write the steps in a use case in an easy-to-understand narrative. Kenworthy (1997) outlines the following steps:

• Identify who is going to be using the website.
• Pick one of those users.
• Define what that user wants to do on the site. Each thing the use does on the site becomes a use case.
• For each use case, decide on the normal course of events when that user is using the site.
• Describe the basic course in the description for the use case. Describe it in terms of what the user does and what the system does in response that the user should be aware of.
• When the basic course is described, consider alternate courses of events and add those to "extend" the use case.
• Look for commonalities among the use cases. Extract these and note them as common course use cases.
• Repeat the steps 2 through 7 for all other users.

Example Use Cases

Below, are examples of three use cases with increasing levels of complexity.  For our purposes we have defined them as Simple, Middleweight and Heavyweight use case for doing the laundry.  In each of these types of uses cases you will see that:

• A housekeeper does laundry on a Wednesday
• She washes each load.
• She dries each load.
• She folds certain items.
• She irons some items.
• She throws away certain items.

Simple Laundry Use Case

Middleweight laundry use case, heavyweight laundry use case, basic flow: do laundry, alternative flow 4a: laundry item needs ironing., alternative flow 4b: laundry item is dirty., alternative flow 4c: laundry item shrank., alternative flow 5a: laundry item needs hanger..

Post conditions: All laundry clean and folded or hung up.

Business Rules:

• Laundry can only be done on Wednesdays.
• All ironed laundry items get hung on hangers
• Any laundry item that is irrevocably soiled, shrunken, scorched, etc. , gets thrown out.

Related Content

• USDA Invites You to Reimagine the National School Meals Program Application
• Welcome to the Reimagined HHS.gov
• Creating Cross-Channel Experiences
• User-Centered Design Process Map
• Creating a User-Centered Approach in Government

Related Resources

• Creating Wireframes
• User-Centered Design - A Developer's Guide to Building User-Friendly Applications
• Defensive Design for the Web: How to improve error messages, help, forms, and other...
• Universal Principles of Design, Revised and Updated: 125 Ways to Enhance Usability,...

Related Categories

• Interaction Design

• Accessibility
• Privacy Policy
• Tour the Site
• Website Policies
• WhiteHouse.gov
• GobiernoUSA.gov