"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:
- 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.
- 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:
- 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.
- 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:
- First comes Business Strategy
- Business Goals are defined from Business Strategy
- Business Objectives are SMARTly decomposed from Business Goals
- 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
- Stakeholder Requirements (or User Requirements) are needs of Stakeholders from the selected Solution, in the context of a Business Requirement
- Solution Requirements define the behavior of and constraints imposed on the Solution in order to deliver the Stakeholder Requirements