While this blog series was originally intended for business analysts, it applies to anyone who is involved in eliciting, modeling, analyzing, or consuming requirements for Business Intelligence (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.
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 policiesRegulationsContracts | Undocumented stakeholder “know-how”Generally-accepted business practicesNorms 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:
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.
References:
“IIBA Home.” IIBA | International Institute of Business Analysis, iiba.org/.
“PMI.” PMI | Project Management Institute, pmi.org/.
