4 Types of Business Analysis Deliverables Every Good Business Analyst Needs to Understand

A lot of business analysts, especially new business analysts, have questions regarding what it exactly they are supposed to deliver.  After some research and applying my personal experience, I've found a simpler way to "shed some light" on exactly what it is we're supposed to be doing.

4 Business Analysis Deliverables

First, business analysis isn't a single task. It actually encompasses a few value-adding activities. For the purposes of this article, I'll break them up into the follow sections or categories that make sense in terms of deliverables.

  • Understanding The Business
  • Planning Your Work
  • Defining The Solution
  • Evaluating The Solution

Let's break these down so you can understand what they are and what deliverables would come out of each. One thing to remember is that different companies may name some of these items or concepts differently, so what's important is understanding the value of the end result not what it is named.

Understanding the Business

This part of the job is where you figure out whether there is really anything to be solved. This is not always done by a person titled "business analyst," because at this point you are figuring out returns on investment, getting business justifications, etc which more senior business analysts tend to be more prepared for. Depending on the company, this senior business analyst may have many different titles. My company, for example, calls it an IT Partner, usually partnering with a particular business segment like marketing, sales, etc.

The High-Level Deliverable: A Business Case 

The business case is typically what comes out of this, and it may include outputs of various techniques that come together to show that a problem needs to be solved or there is an opportunity to take advantage of.

Planning Your Work

Once you or someone else has determined there is a project worth doing. It is time to plan how you are going to do the rest of the business analysis work. The planning is important because a business analyst can't do very much alone. An analyst needs to plan how they are going to interact with all the stakeholders and get what they need out of them to create a solution that works for them. It prepares everyone involved and also ensures they have the resources (people, tools, facilities, etc) they need. This becomes especially important if you are a contractor and statements of work will be required.

The High-Level Deliverable: The Business Analysis Plan

While at high-level everything that comes out of this might be included in business analysis plan, they may be broken down into smaller common deliverables like work breakdown structure (WBS), communication plan, business analysis approach (plan vs change driven), and requirements management plans. 

Defining the Solution

This step is typically what people believe the "business analysis" is, and what their deliverables should be centered around. Defining the solution is essentially documenting what the future solutions should be capable of doing to meet the business needs, also known as requirements gathering. 

The High-Level Deliverable: A Requirements Document

This can come in many shapes and sizes. Requirements document makes it sound like it should be a paper document, but it doesn't aways have to be. The BABOK terms this the "requirements package" which I think better describes what it is. This could include a traceability matrix, use cases, business requirements, stakeholder requirements, solutions requirements and they can be textual or in the form of diagrams, models, or wireframes. 

Evaluating the Solution

Sometimes your job may require you to evaluate whether a given solution actually meets business needs. This can happen in two ways. The first is when the requirements document has been done, the solutions have been designed/built, and you need to make sure it meets the actual business needs. The second is when the requirements are defined, and you want to assess a bunch of different potential solutions. Kind of like creating a list things you want in a car and checking cars out to see which models meet your criteria (instead of building your own).

High-Level Deliverable: Acceptance/Evaluation Criteria & User Acceptance Test Cases

Acceptance and Evaluation criteria are typically lumped together, the main difference is acceptence describes the first scenario where you making sure what you build or purchased is really meeting your needs. Evaluation is usually used when you are using your list decide on which option your going to go with. This can come in the form of user acceptance test criteria, vendor selection criteria, etc.


I hope that helped and put some perspective into your BA world. Do any of you have examples of specific deliverable names you have ben asked to deliver?

Side note: Even in an agile world, a BA needs to accomplish these same things, but they are done within the scope of sprints/iterations and are typically named differently.

Don't forget to check out

3 Types of Business Analyst Tools to Produce High-Quality Deliverables


Business Analysis Tips to Produce Effective Deliverables

3 thoughts on “4 Types of Business Analysis Deliverables Every Good Business Analyst Needs to Understand”

  1. Angelo, good Article. I’d like to add another couple of deliverables that I think BAs must also be thinking about.

    1. User Acceptance Testing document – Once the solution has been delivered, the BA is the best person to ensure that the original requirements / acceptance criteria have been met and deliver real business value. They do this by doing the initial UAT, and should also be creating the UAT scripts that the ultimate users can use to start their UAT testing

    2. Training/ help documentation – As opposed to technical documentation, the BA should also be involved in producing documentation that can be used by the people using the solution delivered to understand how the solution works (and fits into their business process) and how to use it most efficiently for their specific purpose.

    What are your thoughts on this?

    1. Tasneem,

      Thanks for you reply

      I would include the UAT testing portion within my Acceptance testing category (4th category). So yes I agree that would fall within our area of expertise (modified article to reflect that).

      As for training and help documentation. I would say that its not necessarily the job of the BA, andt depending on the size of the team, the business analyst may not be the person doing it. This is what I’d consider a deployment activity, and I’ve been on projects where it was my responsibility (because I was the most qualified), but for systems that interface to potential customers, people who are more qualified (like technical writers) have been called upon to do the work.

Leave a Reply

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