Behavioral rules are one of the two kinds of business rules, the kind that can be broken.^[1]  The possibility of violations raises two important questions for business analysts to answer for each such business rule, as follows.

1. How strictly should the rule be enforced?  Possible levels of enforcement are presented in Table 1 below.^[2]
   
   
2. How should the rule be enforced — what violation response is appropriate?  Such responses can be in the form of sanctions (more business rules), reactive procedures, human intervention, or some combination thereof.

The choice of appropriate enforcement level and violation response for a behavioral rule is always a question of business policy — or if you prefer, a special kind of business requirement.

One question remains though:  Can the same behavioral rule have more than one enforcement level and violation response?  The answer to this question — an important one for re-use of the rule — is yes.

Let's take an example.  From health insurance we might have the following rule.

Rule:  The amount claimed for a "sling" must be LE the special limit for an incidental if the claimant is out-of-state and the claim amount is LE $500.

What happens if this rule is violated?  The answer is probably 'it depends'.  In other words, both the enforcement level and the response to a violation may be selective to circumstances.  That's especially true if we consider re-use of the rule cross-functionally.

From a business perspective, re-use of the rule means the rule is to be applied at different points with the company's business process(es).  For example, the rule might be used both in responding to customer queries (e.g., "Would I be covered if …?") and for validating actual claims.  Clearly, the appropriate level of enforcement and violation response depends on the situation.

• For customer queries, there might be no real enforcement at all, simply a polite informational message.
  
  
• For validating claims, the rule is strictly enforced, with outright rejection a real possibility.

Specifying Context for Behavioral Business Rules

Here then is a more complete specification about the business rule about using RuleSpeak.^[3]

Rule:  The amount claimed for a "sling" must be LE the special limit for an incidental if the claimant is out-of-state and the claim amount is LE $500.

	Applicability Condition	Enforcement Level	Violation Response
1.	The claim is submitted for inquiry only.	guideline	Return polite message to the submitter.
2.	The claim is submitted for payment.	strictly enforced	Mark the claim non-payable.

This more complete specification introduces the notion of applicability condition.  Essentially, applicability conditions represent a kind of externalized "if" condition.

Note that the rule statement remains exactly as it was before — no changes in its expression.  Think of the actual business rule then as that part of the decision logic that remains constant even if enforcement levels and violation responses vary for different circumstances.

Why is that important?  In a business with 1,000s of rules, keeping your eye on the 'constants' is not merely helpful, it's essential.  Otherwise, the number of rules starts to balloon out of control.  By the way, that's one highly undesirable consequence of if-then syntax of rule expression.^[4] 

From a business perspective, an applicability condition can be viewed as a context of enforcement.  Potential contexts might fall into any of the following six categories:^[5] 

1. A business thing, or verb concept (fact type) about some thing(s).
2. A business process, or input/output thereof.
3. A business location or jurisdiction, or linkage between locations.
4. An organizational unit or role within a business, or work product that is handed-off between such units or roles.
5. A business event (point in time), or period of time.
6. A business goal or objective, or means to achieve it.

The earlier sample business rule specification was based on the second of these, business processes.  Since business rules and business processes are so often addressed by business analysts in tandem, that kind of applicability condition is the most commonly recognized in today's work with business requirements.

A Word about Semantics and Time

Formally, applicability conditions are not part of the semantics (meaning) of a business rule per se.  This distinction is usually not hard to follow.  Potential applicability conditions that are time-based, however, do present a special challenge.

In using applicability conditions, it is important to remember the business rule must always be true for as long as the rule remains in effect — even if its enforcement is so light as to be negligible.  If, at any time, the business rule does not have to be true then there is some specification (semantics) needed for the rule itself.

Suppose, for example, the earlier 'sling' rule is effective only during 2011, not before or after that particular year.  That means the rule does not have to be true before 2011 and after 2011.  That's part of semantics of the business rule,^[6] not any applicability condition.

That brings us to the bottom line principle for what constitutes an actual business rule:  The business rule is whatever should be true all the time, no matter how lightly or how strongly the rule is enforced while it applies.

References

[1]  Ronald G. Ross, "What Is a Business Rule?" Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL:  http://www.BRCommunity.com/a2010/b525.html

[2]  Ronald G. Ross, Business Rule Concepts:  Getting to the Point of Knowledge, 3rd ed.:  Business Rule Solutions, LLC, ©2009, 2005, 1998, p. 135.  ISBN 0-941049-07-8.  Available at http://www.brsolutions.com/b_concepts.php

[3]  Basic RuleSpeak guidelines are available for free in English, Spanish, German, and Dutch on www.RuleSpeak.com

[4]  Ronald G. Ross, "What's Wrong with If-Then Syntax For Expressing Business Rules ~ One Size Doesn't Fit All," Business Rules Journal, Vol. 8, No. 7 (July 2007), URL: http://www.BRCommunity.com/a2007/b353.html

[5]  Based on the six columns (primitives) of the Zachman Architecture Framework.

[6]  Even if specified as separate effective dates and times (meta-data), rather than as part of the rule statement itself.

# # #