• Teresa Bennett

Business Requirements Definition

"Business Requirement" is a phrase so widely used it's starting to lose its true meaning. I want to bring us back around to what it truly means.

Different people have different interpretations for what it means. The worst interpretation that I have come across is, “if the requirement comes from a stakeholder, then it's a business requirement”. Just because someone on the business side of the house said it, doesn't mean it's a business requirement. Every requirement comes from a stakeholder, but not every stakeholder is a "business" stakeholder.

Let’s take a look at an example scenario.

We have an insurance company dealing with a business problem: they have a significant number of their renter's policies lapsing by the first anniversary. In other words, the customers who buy a renter's 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 renew their policy because they feel it's inconvenient. They don’t like to go in person to the insurance once to pay the premium in order to renew their policy and hold times are too long when they attempt to call in to customer service to pay over the phone with a representative of the company. They find both options to be so much of a hassle that they let their policies lapse.

What could help solve this problem?

An Ability To Collect Premiums Remotely. This is a business requirement.

According to the IIBAs BABOK guide, a business requirement is simply a statement of goal, objective or outcome of why a change is initiated. That's it.

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

1. This requirement captures the need of the business in order to eliminate a problem (actually the symptom). If the insurance company develops the ability to collect premiums remotely, then, according to the root cause analysis, more customers will be willing to renew their renter's policies, and consequently the lapse rate should decline.

2. Business requirements do not capture how the requirement will be met. In other words, the business requirement statement must not include the solution. This is important for a couple of reasons:

  • Business requirements are developed during Enterprise Analysis/Strategy Analysis. The business requirements are developed after assessing current state of the organization. At this point, we have no clue what the solution is because we haven't even finished defining the requirements. I often see people try to dene requirements based on the solution. They try to make the requirements t the solution. Never determine the solution before the requirements are determined.

  • There are always multiple potential solutions that can be employed to meet a business requirement. If the business requirement includes a solution, we're now forcing the organization to use that solution without considering if any other solutions might be a better option. In the above insurance company example, there are several solutions possible:

- 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             - Enable automated telephone payments that do not require the customer to speak with a representative

Any of the above solutions will provide the remote premium collection ability for the insurance company.

Can you see why we don't want to include the solution in the business requirement statement?

Most people whose role is Business Analyst operate in the IT space and they are defining the requirements for an IT solution. Every BA participating in defining the user and solution requirements needs to begin by understanding the business requirements.

Even though you know you're going to meet the requirements with a technology solution, don't start off with the solution in mind. If you do, you'll be leading your stakeholders down a very specific solution rather being open to options for the best possible solution.

Want to learn more about eliciting and defining requirements? Consider one of our online training programs.

#effortlessbusinessanalysis #businessanalysis #businessanalysistraining #businessanalyst

#businessanalysts #businessanalysttraining #businessanalystcareer #juniorbusinessanalyst

#seniorbusinessanalyst #businessanalystbyday #businessrequirements #softwaredevelopmentlifecycle #softwarerequirements #careersuccess #processengineering

#careersuccess #businessrelationships

98 views1 comment

Recent Posts

See All