How to Organize Your Business Analysis Deliverables: Requirements, Business Rules, User Stories, and Use Cases.

I have a lot to cover, so lets 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

Business Analysis Deliverables Explained

For many of us, including myself, we 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 Critieria - 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 tools 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:  [recieve order] -> [process order] -> [ship product]

The business rules and decisions tables usually relate to the individuals tasks and help guide the process against the businss rules. This is where you will likely get into the business of writing "must" or "shall"... FYI... I won't be entertaining any discussion on whether to use "must" or to use "shall." Your an analyst, figure it out!

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

The business process, rules, and decision 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 capabilites" 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 needs. Next you need to determine what stakeholders will need to be able to do to meet those needs, so you develope stakeholders requirements. In form, 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 requirments revolve around "ability". Some practictioners 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 sales person must be able to override pricing
  • or the ability for the system to do something
    • The system must be able to double autheticate logins (non-functional requirement)

User Acceptance criteria is 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 it 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 its temporary.-


2 thoughts on “How to Organize Your Business Analysis Deliverables: Requirements, Business Rules, User Stories, and Use Cases.”

  1. I find that considering decisions explicitly rather than trying to link decision tables and business rules to process works better. Decisions are often reused across processes and have potentially complex structures that deserve to be modeled in their own right rather. While some can be represented by a single decision table others require many, for instance, that must be combined into an effective dependency network or Decision Model.
    If you try and map business rules/decision tables directly to processes, and if you regard them as “part” of the process then you will often miss the potential for reuse and make your processes over complex by smearing rules throughout them. Check out this presentation for instance for my thoughts.
    You can also check out the Decision Model and Notation, for example, as an emerging standard for doing this. There’s more on this approach here.
    Thanks for raising the visibility of process and rules in requirements!

    1. Thanks for your comment James. That video around decision tables and business rules was very informative. The video started doing some weird stuff with the audio around 9min.

Leave a Reply

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