These are a form of Requirement  that must be met to give a solution, feature, or functionality a pass or fail. You should expect to do this a lot as a BA as it is core to writing requirements.

The BRD or business requirements document is one of the original standard business analysis deliverables in a waterfall methodology. It is typically the result of weeks or months of work. As you will see, it represents a very formal document that essentially becomes a contract between the business owners who want the software or features and the designers and developers who will be creating it.  

Business Analysis Template (Google Doc)

Quick Video describing a day in the life of an entry-level business analyst on my team.

As an entry-level business analyst most of your daily activity will fall into 4 categories.

• Meeting with the business team
• Meeting with the development team
• Conducting & documenting analysis work
• Getting feedback.

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 following 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. Planning is important because a business analyst can’t do very much alone. Analysts need 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 a 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 always 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 of 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 acceptance describes the first scenario where you make sure what you build or purchased is really meeting your needs. Evaluation is usually used when you are using your list to decide on which option you are 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

It is funny how when looking back it seems so obvious how you should have done something, but at the start, finding the right method or rhythm is difficult. I know my first couple of requirements documents were kind of all over the place. Most of the templates I came across (internal & external to my company) focused on making sure requirements are clear (S.M.A.R.T.) and well written, but never on their structure as a whole. After some years of experience and great mentorship, I think I’ve come to a nice and clean way to keep your requirements organized.

Keep High-Level Requirements and Solution Requirements Together

Most templates recommended organizing requirements by first having business requirements then in a separate section having functional/solution requirements. Some organizations may even separate these out into different documents.

Traditional Model

• Business Requirements
  • Business Req 1
  • Business Req 2
  • Business Req 3
• Solution/Function Requirements (traced back)
  • Solution Req 1 : BR1
  • Solution Req 2 : BR1
  • Solution Req 3 : BR2
  • Solution Req 4 : BR3

This doesn’t work well for me. Instead, I prefer a requirements decomposition model.

Requirements Decomposition Model

• Requirements
  • Business Req 1
    • Solution Req 1
    • Solution Req 2
  • Business Req 2​
    • Solution Req 3
  • Business Req 3
    • Solution Req 4

The end result can be easily diagrammed (which will look like an organizational chart) and it helps stakeholders EASILY understand why everything is being done. The breakdown may not always be just 2 levels. I find that it usually breaks down a few levels before getting to actual solution requirements. I’ll give a non-IT-centric example to make it fun (and prove that Business Analysis Does Make You Sexier!).

Lets say I’m the business and I want to look better in a bathing suit, so I need to implement a system or process to help me do this. Lets break this down

• Business Objective: Get A Beach Ready Body
  • BR1: Lower % Body Fat
    • BR1.1: Eat Less Carbohydrates
      • SR1: Throw Away Carby Snacks
      • SR2: Remove/Reduce Carbs from Regular Diet
    • BR1.2: Do More Cardio Exercises
      • SR3: Establish cardio schedule
  • BR2: Gain More Muscle
    • BR2.1: Eat More Protein
      • SR4: Stock Fridge With Meat
      • SR5: Buy Protein Powder
    • BR2.2: Lift Heavy Weights
      • SR6: Buy heavy weights
      • SR7: Establish weight lifting schedule
  • BR3: Enhance Overall Wellness
    • ​BR3.1 : Get More Sleep
      • SR8: Got to bed by 10PM
    • BR3.2: Get More Nutrients
      • SR9: ​Consume daily multivitamins
    • BR3.3: Reduce Stress Levels
      • ​SR10: Morning Yoga (30 min)

​​​​I like this method because the alternative is having to trace requirements, which gets cumbersome and usually out of sync. Then you forget why you are doing yoga every morning for 30 minutes and it gets cut from the document and you get less than optimal results because your stress levels are too high releasing cortisol which leads to fat retention… etc… you get the picture.

Some of you are asking, what about the additional details within the requirements. Those don’t have to go away. In fact, one way to do this is to use your table of contents as the decomposition structure by taking advantage of the heading levels (Heading 1, Heading 2, etc). In the document itself, you can include the necessary details under the heading levels. This structure works well with both standard requirements structure as well as user stories and use cases.  What do you think? Do you have a better way to organize your requirements?

If you need a more generic overview of all deliverables for a business analyst check out 4 Types of Business Analysis Deliverables Every Good Business Analyst Should Know

Many of us get confused when we are told a business analyst writes requirements, but then we are told we also write use cases, user stories, business rules, decision tables, functional requirements, and so forth. So, I’ll start with a basic hierarchy to get the ball rolling, then break it down from there

Business Processes

• Business Rules
• Decision Tables

Business Requirements – User Stories

• Stakeholder Requirements – Use Cases
• Solution Requirements
  • Functional Requirements – Acceptance Criteria – Non-Functional Requirements
• Transition Requirements

First: The Business

The first thing you need to understand is that as a business analyst, your first task is to analyze the business before you determine any needs. This analysis should be about how the business runs and should remain separate from the tools used to run it (in most cases, your project will be to determine which features or capabilities best fulfill the business needs). This is typically done by business processes, business rules, and decision tables.

The business process, if done well, is a set of sequential tasks that are performed that are supposed to achieve business value. The tasks usually follow a “verb + noun” structure

• Example:  [receive order] -> [process order] -> [ship product]

The business rules and decisions tables usually relate to the individual tasks and help guide the process against the business rules. This is where you will likely get into the business of writing “must” or “shall”.

• Example:
  • [process order]
    • Rule 1.0 Order must have a valid purchase order number
    • Rule 1.1 Order must contain a valid shipping address
    • Decision 1.0 If the order contains software send to software fulfillment
    • Decision 1.1 If the order contains hardware send it to hardware fulfillment

The business process, rules, and decisions should exist before any type of project requirement are developed and the requirements should fulfill the process, rules, and decisions of the business. (Side note: Business Rules and Decisions help keep the business process from looking too crazy with so many decision diamonds and branches. Great for quick and easy readability/understandability)

Second: The Project

The second thing you need to understand is that “requirement” is a generic term that basically means “capability.” In fact, you can refer to requirements as “required capabilities” after all, when you do a gap analysis, you are analyzing the gap in capabilities that eventually become business requirements.

Generally, business requirements are at the highest level and represent the enterprise’s needs. Next, you need to determine what stakeholders will need to be able to do to meet those needs, so you develop stakeholder requirements. You can write these types of requirements as user stories, use cases, business requirements, or stakeholder requirements.

As you dig in to get more detail, you start moving into solutions requirements, which are literally what the system needs to be able to do. Sometimes these are functional or non-functional. Generally speaking, business requirements and solution requirements revolve around “ability”. Some practitioners advocate using “the ability to” or “must be able to” in your requirements statements. Some examples

• the ability for the company to do something (business requirements) to do something
  • The organization must be able to process orders
• the ability for a user/stakeholder to do something
  • The salesperson must be able to override pricing
• or the ability of the system to do something
  • The system must be able to double authenticate logins (non-functional requirement)

User Acceptance criteria are another form of requirement and can be used as requirements because they are literally what the system must do (capabilities), in order to be considered a successful project. These are more popular to use with SaaS/Cloud software since you won’t be building it internally, you only need to evaluate whether it meets your business needs.

Finally: Deployment

Sometimes, in order to get a system up and running, you need to do a few things in order to manage the transition. The easiest example of this is when migrating into a new system, you might need to build a capability to import masses of data into the new system from the old. However, once the migration is done, the capability is basically obsolete. This is a transition requirement. It can technically fall into any of the above “requirements” types; the only difference is that it’s temporary.-