Continuing with my Top 10 Mistakes series this month, let's investigate Mistake #3:  "Assume everyone knows what a business rule is."

My daughter is in the process of applying for university.  If you have gone through that process, you will empathize with my anxiety.  The university application process is daunting and full of rules. There are rules for acceptance.  For example, if a student is accepted through early decision, he or she must enrol at that university and withdraw all applications to other universities. 

There are also rules for applying, of which the most important are related to the essay submissions.  Each university requires 2-3 essays.  Each essay has word or character count limits.  For my daughter, the shorter the essay requirement, the longer it takes her to write.  She is applying to 10 universities ... translation — having to endure her writing process for 20-30 essays, with an average of 6 revisions for each.  You do the math.  You can't imagine my jubilation when I saw the instruction on one of the applications that read: "The following essays are optional  — and yes, they truly are optional!  If you choose not to answer them, your chance of admission will not be affected."  I was so excited and exclaimed to my daughter, "Look, you don't need to do essays for that university."  Her immediate response was, "Yes, I do, Mom.  It's the rule."  At that point I realized my daughter does not know what a rule is.

One of the best parts of my job is the opportunity to visit major organizations worldwide.  In guiding organizations in the business rules approach, one of the first things that becomes clearly apparent is that different people have different perceptions of business rules.  So, if you are embarking on a project on business rules, do not assume everyone knows what a business rule is or assume everyone thinks about business rules the same way you do.

Some people might think business rules are requirements:  "Provide a feature to handle electronic funds transfer."

Some people might think business rules are use case statements:  "Customer provides account ID.  System displays account information."

Some people might think business rules are system 'if/then' statements:  "If the overdrawn flag is set to 'yes', then reject transaction."

So what is a business rule?  The definition I like is from Guide 1995:  "A statement that defines or constrains some aspect of the business… [which is] intended to assert business structure, or to control or influence the behavior of the business."^[1]

By that definition, business rules related to the requirement, use case, and system 'if/then' statements given above might be, respectively:

"Each employee expense reimbursement must be processed through electronic funds transfer."

"A customer must have a valid account ID."

"An account must not be overdrawn."  "An account may be considered overdrawn only if the amount of a cash withdrawal is greater than the balance of the account at the time of the withdrawal."

You can read more about the definition of business rules in Ron Ross's book Business Rule Concepts:  Getting to the Point of Knowledge, 3rd Edition.^[2]  Clearly a guru in the field, he has also published an article on BRCommunity.com on this subject:  "Five Tests for What Is a Business Rule?"^[3]

My advice is to have a clear definition of business rules before you start a project.  However, the definition in itself is not enough.  In order for a project that is focused on business rules to be successful, you will also need to know:

1. The level of detail you would like your business rules expressed at.  Business rules can be expressed at a very high level, like a policy statement, or be very detailed, showing all conditions of the business logic.
   
   
2. How you want to group sets of business rules that provide complete business logic for guidance or operational business decisions.
   
   
3. How you would like to express your business rules.  In Business Rule Solutions, we use RuleSpeak^®[4] for business rule statements and Q-charting™^[5] for decision structures.
   
   
4. Whether you need to capture business rules or system rules or both.
   
   
5. How you would want to manage the business rules you discover (which I can guarantee will be in the hundreds, if not thousands).
   
   
6. How the business rules deliverable gets integrated into the rest of your project deliverables (i.e., use cases, business requirement documents, etc.).

Just Remember…

Plainly speaking, here are some of the main things you need to remember:

• Business rules are lists of statements that tell you whether you may (or may not) do something or that give you the criteria and conditions for making an operational business decision.  Make sure you and everyone involved in the project know what that means.
  
  
• You must define some basic principles for business rules before you start your project.
  
  
• You will harvest A LOT of business rules.  Knowing in advance how to write them, find them, categorize them, and manage them is essential.

References

[1]  Business Rules Group.  [July 2000].  Defining Business Rules ~ What Are They Really? (4th Ed).  Available at:  http://www.BusinessRulesGroup.org  Note:  Formerly known as the GUIDE Business Rules Project Report, (1995).

[2]  Business rules are detailed by Ron Ross in Business Rule Concepts:  Getting to the Point of Knowledge, available at http://www.BRSolutions.com/b_concepts.php

[3]  Ronald G. Ross, "Five Tests for What Is a Business Rule?" Business Rules Journal, Vol. 11, No. 10 (Oct. 2010), URL:  http://www.BRCommunity.com/a2010/b556.html

[4]  RuleSpeak® is a set of guidelines developed by Ron Ross for expressing business rules in concise, business-friendly fashion.  For details refer to  http://www.RuleSpeak.com/en/

[5]  For more information on Q-Charts™ refer to http://www.brsolutions.com/b_decision.php

# # #