The Community Blog for Business Analysts

Praveen Udupa
Praveen Udupa

Business Requirement: Clarified

"Business Requirement" is a maligned phrase. Different people have different interpretations for what it means. The worst interpretation that I have come across is, “hey, if the requirement comes from a business stakeholder, then it is a business requirement”. Requirement from business is NOT business requirement. For God's sake, every requirement comes from a stakeholder, otherwise it is not a requirement.

In this blog, I wish to clarify what exactly is a business requirement. I base this entirely on the best practice definitions documented in the BABOK v2 (and v3…truth rarely changes!)

Let’s take a short case:

Assume there is an insurance company that is dealing with a sticky business problem: they have a significant proportion of the policies lapsing by the first anniversary. In other words, the customers who buy an insurance policy today do not renew it the following year and, instead, let the policy lapse. Upon performing root cause analysis, the insurance company determines that the customers do not care to renew their policy because they don’t like to travel all the way to the branch office to pay the premium in order to renew their policy. In fact, they find commuting to the branch office so troublesome that they find it acceptable to let their policy lapse.

Now, what does this insurance company need to deal with the policy lapsing problem?

The insurance company requires an Ability To Collect Premium Remotely. This is a business requirement.

According to the BABOK, a business requirement is simply a statement of goal, objective or outcome of why a change is initiated. (Please see my P.S. at the end of this article)

Let’s take a closer look at the above business requirement:

  1. Business Requirement exists in the Problem Domain. It captures the need of the business in order to eliminate a problem (actually the symptom). If the insurance company develops the ability to collect premium remotely, then, according to the root cause analysis, more customers will be willing to renew their policies, and consequently the lapse rate will decline.
  2. Business Requirement MUST NOT capture how it will be met, i.e. the statement of business requirement must not include the solution. This is important. Very important. Well, why is this so? There are a couple of reasons:
    1. First: Business requirements are developed during Enterprise Analysis (BABOK v2) or Strategy Analysis (v3). To be more specific, they are developed after assessing current state of the organization. At this point in time, no one even know what the solution is because it is not yet identified. Hence the question of including the solution in the statement of business requirement does not even arise.
    2. Second: there always are multiple potential solutions that can be employed to meet a business requirement. If the statement of business requirement includes a solution, one would tie the organization to the said solution without considering any of the other solutions. In the above insurance company example, there are several solutions possible:
      • First obvious solution: enable internet and mobile payment
      • Enable direct debit from the customer’s bank account
      • Partner with one or more banks and enable the banks to collect the premium
      • Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
      • Establish several satellite premium collection centres

As you can see, any one or more of the above solutions will provide the remote premium collection ability to the insurance company. Thus, it is not prudent to include the solution in the statement of business requirement.

Most people whose role/designation is Business Analyst operate in the IT space. They define the requirements for an IT solution. More often than not, these BAs do not get to define the business requirements because they mostly never participate in Strategy Analysis projects. However, every BA participating in defining the User and Solution requirements MUST begin by understanding the Business Requirements.

More on this in my subsequent blogs...but for now, I will look forward to your comments! 

P.S: 

 BABOK is probably confusing for a first time reader (even if this first time reader is a seasoned BA). The BABOK makes a confusing statement - it says business requirements are high level statements of goals. This seems incorrect because a goal and requirement are clearly two different things. Here is how I reconcile various terms: 

  1. First comes Business Strategy 
  2. Business Goals are defined from Business Strategy
  3. Business Objectives are SMARTly decomposed from Business Goals
  4. Business Requirements are high level statements of goals (not Business Goals) in order to eliminate a Problem that is preventing the org from meeting its Objectives, without including any indication of the Solution in its statement
  5. Stakeholder Requirements (or User Requirements) are needs of Stakeholders from the selected Solution, in the context of a Business Requirement
  6. Solution Requirements define the behavior of and constraints imposed on the Solution in order to deliver the Stakeholder Requirements
This entry was published on May 06, 2016 / Praveen Udupa. Posted in Requirements Analysis (BABOK KA) , Functional Specifications, Business Analysis, IIBA & BABOK. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  22 members liked this article

COMMENTS

Leslie posted on Saturday, May 14, 2016 1:57 PM
"The insurance company requires an Ability To Collect Premium Remotely. This is a business requirement."

As someone who has worked with requirements for a very long time, I would take this further and correction further and describe the above as a business 'Need'.

In my profession the word 'requirement' has a very specific definition which is based upon several attributes. A prime example attribute is that it must be testable. Without a lot more information, the above statement cannot be validated.
sureshbrady posted on Saturday, May 28, 2016 7:36 AM
I thought that according to BABOK business requirements do NOT refer to the needs of individual stakeholders. From BABOK:
They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and NOT groups or stakeholders within it.

The problem is a lower than desired renewal rate (i.e. %60). The business requirement is to increase the renewal rate to say 85% by a certain time post project as measured by a particular organisational report. The solution direction becomes the building of a remote mechanism for collection. The stakeholder requirements are then listed in your next article (i.e. to view policies, pay policies, update policies etc).
Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
11 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC