Business Rules

As a concept, Business Rules are not new, to the Business or IT; what is new is the focus on separating them from other forms of documentation so they can better defined and managed. Business Rules are similar to Process Models/Maps in that they are subject to more frequent change than other aspects of the business, frequently enough that if rules are hard-coded in an Information System, the effort and elapsed time to change the system can be too large to be tolerated by the business over time.
So, just as generic Process ‘systems’ are emerging to support rapid process change, so are Business Rule Systems and Vendors that support Business Rule Management and Change independently of the information systems that uses them.

What is a Business Rule?
A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems) project are atomic – that is, they cannot be broken down further.
“Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group.

I would add the word ‘declarative’ to the definition, as in “a business rule is a declarative statement that defines…” emphasizing that Business Rules do not imply and process, procedure, flow or other ‘system’ structure. If Business Rules are separately defined and managed, they can then be used as needed by any process/procedure/flow that needs a rule’s guidance or constraint.

The paper with the above definition is available at http://www.businessrulesgroup.org/first_paper/br01ad.htm
It includes an example case study of a fictitious car rental company with many defined business rules; here is a sample:

Rental reservation acceptance
- If a rental request does not specify a particular car group or model, the default is group A (the lowest-cost group).
- Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up day.
- If the customer requesting the rental has been blacklisted, the rental must be refused.
- A customer may have multiple future reservations, but may have only one car at any time.

So, please go read that article at the Business Rules Group website (I want to avoid any charges of plagiarism of that site on my site).

To ensure that Business Rules are meaningful and clear, they are always based on a defined set of ‘Terms and Facts’, which are used as the language of the Rules. Terms from the above examples include rental request, car group, reservation, branch, and customer. An example of a fact would be "a customer may have multiple future reservations": it’s when you add the constraint "but may have only one car at any time" that you have a rule, using that fact and the relevant terms.

Defining terms and facts can also be seen as a role of an Entity-Relationship Data Model, such that the Entities/Attributes and Relationships of such a Data Model can readily be used as the Terms and Facts for defining Business Rules. The two types of models are different in some ways, but they are similar enough that if you have both, you can easily use one to drive the creation of the other.


So, now we have covered all the Requirements formats that I commonly use:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules

… and I have already touched on some aspects of how these formats can be inter-related and integrated. I will review all those and add some more aspects in my next post on Integrating Requirements Deliverables.