I have a lot to cover, so let’s get right into it. There is some confusion around the different terms for items common in business analysis deliverables, so this is really about the details of what goes into your deliverables. I’m gonna make a short and sweet version of some simple truths to help everyone get to the gold faster.

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