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
How to Use Data Flow Diagrams to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
May 16, 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
How to Use Data Dictionaries to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
May 09, 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. The...
Blog Article
Top 4 Reasons to Attend WI BADD 2019
Shannon PagelsShannon Pagels  |  
Mar 21, 2019
WI BADD® (pronounced ”we bad”) is the annual Wisconsin Business Analyst Development Day held every May in Madison, Wisconsin (This year’s event will be held on May 15-16.) We are excited to again be sponsors and speakers at this event. Keep reading to learn more about the...
Blog Article
6 Hybrid Business Analyst Combinations
Rachael WilterdinkRachael Wilterdink  |  
Feb 19, 2019
There's been a lot of talk lately (and a lot of requests from our clients) for flexible hybrid roles. Our clients are looking for flexible people who can take on a variety of work to bring a project to fruition.   Here, I'm going to explore some of the more common combination roles...
Blog Article
Diagramming & Modelling Tips for Business Analysts
Kurt WondraKurt Wondra  |  
Nov 20, 2018
Among the many responsibilities of Business Analysts, including Backlog Management and Communicating and Collaborating with our teams, the skill of diagramming and modelling is one which seems to be more taboo than mainstream. Have you ever wondered why that is?   One observation I&rsquo...