Back to List

How To Use Business Rules Analysis to Model and Analyze BI Requirements

Rachael Wilterdink Rachael Wilterdink  |  
Apr 25, 2019
 
Welcome to my latest blog series! This is the direct result of a request I received to speak at a local Business Intelligence (BI) meet-up. While this was originally intended for business analysts, it applies to anyone who is involved in eliciting, modeling, analyzing, or consuming requirements for BI projects. It does not matter what job title you have – if you are involved in a BI project, knowledge of these techniques will be useful to you. Over the next several months, we will be releasing all 10 techniques on our blog. The first technique in this blog series is Business Rules Analysis.
 

What is Business Rules Analysis?

The technical definition of Business Rules Analysis is:

"Business Rules analysis is used to identify, express, validate, refine, and organize the rules that shape day-to-day business behavior and guide operational business decision making."

- BABOK® v3.0

Business Rules are directives that serve as criteria to:
 
  • Guide behavior
  • Shape judgments
  • Make decisions
 

General Business Rules Principles

There are some general principles regarding Business Rules that should be considered when using this technique:
 
  • Base them on standard business vocabulary
  • Express them separately from how they will be enforced
  • State them atomically and declaratively
  • Map them to decisions the rule supports (or constrains)
  • Maintain them so they can be monitored and adapted
 

When to use it?

When eliciting requirements, it is not uncommon for analysts to [accidentally] discover Business Rules. While they might resemble requirements, they are distinctly different in that they apply to the whole organization and are self-imposed constraints that the business needs to operate within. If you do identify Business Rules during the course of your project, that is when you might start to consider using this technique.
 

Where do you find Business Rules?

Business Rules may be discovered during requirements elicitation, but they may also be found in other places. Business Rules may be either explicitly or tacitly found:
 
Explicitly Tacitly
  • Documented policies
  • Regulations
  • Contracts
  • Undocumented stakeholder “know-how”
  • Generally-accepted business practices
  • Norms of the corporate culture
 
The explicitly found Business Rules are obviously much simpler to identify and manage. Tacitly found Business Rules will take some disentangling to identify, document, and consistently apply.
 

What are the attributes of Business Rules?

When you have identified Business Rules, there are certain attributes about the Business Rules that it is important to take note of. They must be:
 
Specific They can’t be vague or broadly stated
Testable They need to be able to be verified
Explicit The must be completely stated
Clear They are distinctly stated and well-understood
Accessible They are published to a place where people can view (and manage) them
Single-sourced They should exist in only one place, without duplications or conflicts in other locations
Practicable They need no further interpretation
 

How to use this technique?

Once you have identified your Business Rules and their attributes, it’s time to document those rules. If you’re lucky, your organization may already have a Business Rules “engine” that exists in a location that enables it to apply those rules across your business systems. If you’re not that lucky, you will have a bit more difficulty, but it still worthwhile to separate the Business Rules from a project’s requirements.A sample of a set of Business Rules might look something like this:
 
business rules sample set
Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®
 

Pros

If you have a lot of Business Rules, using this technique will aid you in ensuring that you are applying all the Business Rules to not just your project, but across the organization. It will also help to reduce the possibility of duplicate or conflicting Business Rules from being applied.

It’s sometimes difficult to distinguish between requirements and Business Rules, and you may inadvertently include a rule as acceptance criteria. As a result, Business Rules will be sprinkled throughout the organization and will be extremely difficult to apply and manage. By having a consolidated set of Business Rules, you will alleviate these problems.

By breaking what might seem like a complex set of rules down into atomic, individual rules that can be combined to achieve the same result, it will be much simpler to manage and change any of the individual components of a rule.
 

Cons

Business Rules are often tricky to find and nail down. It’s also difficult to make sure that they have all of the attributes described above. If you end up embedding them in requirements and acceptance criteria, rather than in a single source, your rules will end up getting lost.

If you have a large number of Business Rules, but don’t have a way to systematically apply them across systems, it will still be difficult to apply those rules – even if you have a single source.

Many Business Rules will likely end up needing a management system in order to make the best use of those rules, and to apply them across the organization. This can be a costly proposition.
 

Conclusion

Business Rules are important constraints that an organization imposes on itself, and separating them from project requirements can be difficult. But if you do the analysis and split them into their own separate list, you will be doing the right thing for your organization and alleviating the problems that occur when this technique is not used. This is especially true for Business Intelligence projects, where you are likely to uncover large quantities of business rules masquerading as requirements.

Do you have experience with Business Rules Analysis? How do you identify and manage those rules? Let me know in the comments below.

Next up in this blog series: Data Dictionary.
 

Free Agile Resources


References:
“IIBA Home.” IIBA | International Institute of Business Analysis, www.iiba.org/.
“PMI.” PMI | Project Management Institute, www.pmi.org/.
Business AnalysisBusiness Intelligence

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Data Lake vs Data Warehouse: Avoiding the Data Swamp
Scott HietpasScott Hietpas  |  
Jul 16, 2019
In this blog series, Scott Hietpas, a principal consultant with Skyline Technologies’ data team, and Matt Pluster, the Data Analytics and Data Platform director, respond to some common questions on data warehouses and data lakes. Previous installments covered pros and cons of each solution,...
Blog Article
10 Communication Tips for Business Analysis and Project Success
Brian LaehnBrian Laehn  |  
Jul 09, 2019
I am often asked what is the most essential skill that a Business Analyst (BA) should possess. 100% of the time my answer is that a BA must demonstrate the ability to communicate effectively with their project team and all project stakeholders.   Communication, when performing...
Blog Article
Data Lake vs Data Warehouse: What’s the Best Configuration?
Scott HietpasScott Hietpas  |  
Jul 02, 2019
In this blog series, Scott Hietpas, a principal consultant with Skyline Technologies’ data team, responds to some common questions on data warehouses and data lakes. For a full overview on this topic, check out the original Data Lake vs Data Warehouse webinar.   In my previous blog...
Blog Article
How to Use Report Tables to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Jun 27, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. Over the next several months, we will be releasing 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements on our blog...
Blog Article
Data Lake vs Data Warehouse: Pros and Cons
Scott HietpasScott Hietpas  |  
Jun 18, 2019
In this blog series, Scott Hietpas, a principal consultant with Skyline Technologies’ data team, responds to some common questions on data warehouses and data lakes. For a full overview on this topic, check out the original Data Lake vs Data Warehouse webinar.   There's a lot of...