Business Rules – Enfocus Solutions Inc

This article provides a primer on business rules. Business rules describe in plain language policies for making decisions, formulas for calculations, definitions used in the business, and key facts and assumptions of how the business operates.  Business rules exist whether or not you have an automated system. Business rules are owned by the business and not IT, and not every business rule is implemented in software.

Simply stated, business rules are lists of statements that tell you whether you may or may not do something, or give you the criteria and conditions for making a decision. Business rules include corporate policies, government regulations, industry standards (such as accounting practices), and computational algorithms. Below are some examples of some business rules.

• A past due account is an account that has not been paid in full after 5 business days of the payment due date.
• Past due accounts are subject to late fees, interest rate increases, and suspension of the customer’s credit limit.
• Net sale is defined as the total sales price of an order before discounts, allowances, shipping, and other charges.
• When an order is initiated via the Internet, sales taxes will be calculated by multiplying the net sale amount by the sales tax rate in effect in the state from which the order was placed.

Business rules are not software requirements. They exist outside the boundaries of software and therefore should be regarded as an enterprise-level asset. However, business rules often require that specific functionality be implemented to ensure that the system enforces or complies with those rules.  Business rules may be implemented in a variety of ways. The easiest way to enforce a business rules is manually through a written policy or procedure. Business rules may also be implemented in software, database stored procedures, or a business rule engine.

A word of caution.  Some people have made business rules so complex that it would take 20 PHDs to understand them. Business rules are not supposed to be complex; adding this amount of complexity simply destroys a much needed capability. Below are some general guidelines for writing business rules.

• Business oriented—The rules are stated in terms business people can understand. The rules must use terms that are meaningful, understood, and confirmed across the business domain. They should be expressed in such a way that business people can validate them for correctness.
• Owned by the business—Business rules are created and maintained by business people and not by IT.  Article 9 of the Business Rules Manifesto states this in very clear terms “Of, By, and For Business People, Not IT People.” As owners of business rules, only business people can create, modify, or state that a rule is no longer valid.
• Declarative—Business rules are declarative and not stated procedurally. The rule is declared; how the rule is enforced isn’t part of the rule.
• Separate from Processes—Rules are not processes or procedures.  They apply across processes and procedures and should not be contained within them. There should be one cohesive body of rules, enforced consistently across all business activities.
• Precise—A business rule must be open to only one interpretation. If the rule can be understood to mean more than one thing, you have to restate it.
• Atomic—A business rule contains a single complete thought, but not more than one. The business rule must be indivisible; if you try to break up a true business rule into parts, you’ll lose information. However, just because the rules are atomic does not mean that the business rules do not build on each other.
• Consistent—A set of business rules must not contain conflicting rules.
• Non-redundant—A set of business rules must not contain rules stating the same information.

Business rules are best maintained in rulebooks. Each rulebook has an owner responsible for maintaining the business rules. Several rulebooks might exist for a particular function.  For example in HR, you might have rule books for paid time off, time reporting, overtime pay, benefit eligibility, etc.

Rulebooks and associated rules are well suited to be maintained in a repository as they often span multiple projects across an organization. A repository, such as the one included in the Enfocus Requirement SuiteTM, manages version control problems and ensures that anyone who needs to review the rule has access to the most recent version. Managing one repository eliminates business rule duplication and contradictions across multiple projects and considerably eases the maintenance effort for all projects. The repository can maintain a record of all rules whether it is automated or not. When a business rule changes, you no longer need to update each project individually. You update the repository once, and trace the effects of the change to each project

Business rules operationalize broader business policies. For example, a policy such as “provide discounts to repeat customers” is further clarified by stating a more discrete, atomic business rule: “If a customer orders products totaling $1,000 or more in any calendar year, then offer a 10% discount on each non-sale product item.” This business rule in turn is dependent on another, more fundamental business rule: “Each customer orders one or more products.”

As stated earlier, business rules are not functional requirements; however, business rules may strongly influence functional requirements.  If business rules are not clearly documented, it is easy to miss them and can result in a significant amount of costly project rework. Even when they’re explicit, business rules may be vague and contradictory. Software teams often need formal guidance in uncovering, analyzing, and capturing business rules. Otherwise, developers simply make whatever assumptions are needed to write the code, building their assumptions into the software with little regard the impact on the business. Inevitably, developers guess wrong, and only during the latter phases of implementation will it be discovered that essential business rules have not been implemented. These late defects could have been avoided if the rules had been baselined during requirements analysis. The lack of explicit focus on capturing the business rules creates rework and other inefficiencies.

Every organization has lots of business rules.  I have seen organizations with tens of thousands.  One of the first principles of the Business Rules Manifesto is to treat business rules as a first-class citizen of the requirements world.  This means externalizing your business rules from all your documents and managing them on their own right.  Business rules are embedded in business documents, such as agreements, regulations, and marketing materials, or in requirement documents, such as use cases and business requirements documents.  For a business rules project, these business rules should be specified independently from the other deliverables.

When you conduct a project using the business rules approach, many rules are going to be identified and defined.  These rules are not going to be useful if they are not organized in a way that allows you to find and group them for review and analysis.  The rules should be organized into rulebooks and maintained separately from the requirements. Requirements should reference the rules to ensure that the solution enforces the rule as planned. If you can trace a specific functional requirement back to the business rule from which it originated, it is easier to modify the system to comply with a change in that rule. Different functional areas may have different sets of rules, which need to be negotiated so a uniform set is applied.

There has been much discussion of how business rules should be defined. I prefer to group rules into the following five types, which are explained in more detail in the table below.

• Terms
• Facts
• Constraints
• Action Enablers
• Calculations

Enfocus Requirement SuiteTM provides strong capabilities to manage business rules. The rules are managed in an enterprise knowledgebase by business people. Business analysts reference the rules in requirements providing complete traceability.  To find out more, download our product fact sheet.

[cta id=”7421″]