This column is excerpted from Decision Analysis Using Decision Tables and Business Rules by Ronald G.  Ross (Oct. 2010), an in-depth white paper available free on:  http://www.brsolutions.com/b_decision.php

Managing any project effectively requires clearly defined scope.  Projects involving decision analysis are no different in that regard.

In decision analysis, scope is always ultimately based on cases.  A case that is not in scope must be handed off (to some expert, manager, process, or other decision logic).  The decision logic produced from decision analysis must be able to give a definite outcome^[1] for every case provably in scope.

Scope for decision analysis is based on three essential elements:

1. The question the decision logic answers.
2. Limitations about the kinds of cases covered.
3. Exceptions.

The first two elements are highly intertwined.  For example, the question for some decision logic might be expressed in either of the following two ways:

(a)  Is an applicant eligible for auto insurance?

(b)  Is an applicant eligible for insurance?

Cases in Scope:  auto insurance

The resulting scope is the same for either form of specification.

Refinements to scope mean adding additional limitations that narrow the range of cases the decision logic handles (i.e., should give definite outcomes for).  For example, the scope of the decision logic above might be further refined in either of the following ways:

(a)  Is an applicant eligible for auto insurance for USA under $1 million?

(b)  Is an applicant eligible for insurance?

Cases in Scope:
  •  auto insurance
  •  USA
  •  under $1 million

Two more limitations, USA and under $1 million, have been added to both expressions above.  An implicit AND is understood to exist among all three scope items in each expression.  (If there is any doubt about the intended ANDing it should be given explicitly.) As before, both forms of specification result in exactly the same scope.

As scope is increasingly refined, listing limitations on scope separately — as in (b) — usually proves more effective, especially if the vocabulary used in the expressions is coordinated with a fact model (structured business vocabulary) — strongly recommended.  For example:

Question:  Is an applicant eligible?

Cases in Scope:  Any application submitted by an applicant that:
  •  is for the product 'auto insurance'
  •  is for a policy covering the 'USA'
  •  requests a coverage amount less than $1 million

Considerations and Exceptions

The outcome for a case in scope is usually determined by a standard or typical set of considerations.  If not, then the case is an exceptional case, or simply an exception.

A consideration is a factor for making an operational business decision.  For auto insurance, considerations might include driving history, evidence of insurance, insurance risk score, credit rating, and state/province.  As these examples illustrate, considerations should always involve business factors.

The relation of considerations to cases is generally class to instance.

• A consideration is a kind of circumstance that some decision logic addresses.
• A case is some particular circumstance(s) the decision logic addresses.

For example, suppose state/province is a consideration for a decision.  Then the particular instances Texas and British Columbia are cases of that consideration for that decision.  As this example illustrates, a case considered by an operational business decision can be as simple as a single instance for just one of the decision's considerations.  Such a case is very general.

More often, cases addressed by an operational business decision represent combined instances of many or all of the decision's considerations.  Such a case is very specific.  For example, the following instances might combine to represent one specific case addressed by a decision:

Consideration           Instance
driving history         good
evidence of insurance   acceptable
insurance risk score    154         one specific case
credit rating           poor
state                   Texas

An exceptional case (or simply exception) is a case that is based on none of the standard or typical considerations.  Suppose as before that for auto insurance the standard considerations are:  driving history, evidence of insurance, insurance risk score, credit rating, and state/province.  Then suppose there are business rules denying auto insurance for any:
      •  felon
      •  person under age 16

Since criminal status and age respectively are not among the standard or typical considerations for the decision logic, these cases are deemed exceptions.

It is important to note that exceptions are in scope.  Definite outcomes are always given for exceptions, even if simply to deny (or accept) some result out-of-hand.

Typically at most 20% of all possible cases are exceptional.  If the percentage of exceptional cases exceeds 20% for some decision logic, the standard or typical considerations should be re-examined.

Cases that are not exceptional are considered standard.  A standard case is a case in scope that is:

• Regular or common.
• Based on some or all the usual considerations.
• Subject to normal treatment and cannot be denied (or accepted) out of hand.

To complete specification of scope for some decision logic, the business rules for handling exceptions must be given.  For example:^[2]

• An applicant that has been convicted of a felony involving a motor vehicle is always considered ineligible for auto insurance.
  
  
• An applicant younger than 16 years of age is always considered ineligible for auto insurance.

Simplifying the Expression of Decision Logic for Standard Cases

Techniques for simplifying the expression of decision logic focus on where and how various components are specified.  Expression of decision logic for standard cases can be simplified in two important ways:

1. By listing limitations for scope separately.  As discussed earlier, this can be accomplished either by including the limitations in the question representing the decision logic or by listing them apart from (but associated with) the question.
   
   
2. By writing business rules for the exceptional cases.  These business rules handle the special circumstances in which the exceptions apply.

Specifying these two components separately allows them to be assumed by the decision logic for standard cases.  They do not need to be addressed again in expressing the decision logic for standard cases.

In other words, specifications for the decision rules covering all non-exceptional cases within scope need consider only standard or typical considerations.  Circumstances pertaining to scope and exceptions do not have to be addressed explicitly in the decision logic for standard cases.  This simplification results no matter what form that decision logic takes (e.g., decision tables, business rule statements, or other).

This simplification results in slim decision logic for standard cases.  Since that decision logic can be quite complex itself, such a priori simplification proves very helpful.  Two additional points are worth noting:

• How the overall configuration of decision logic is implemented 'under the covers' should not be a concern.  All components of the decision logic needed for correct evaluation of cases from a business point of view have been addressed.
  
  
• Wherever the decision logic is re-used, all the logic must be applied (deployed), including the separate specifications for scope items and exceptions.  The decision logic for standard cases depends on the whole; re-use of just some subset can easily produce inappropriate or incorrect results.

Simplifying the Analysis of Decision Logic for Standard Cases

A key to simplifying the analysis of decision logic for standard cases is to divide and conquer.  Projects should be carved out that can be undertaken separately and, if resources permit, in parallel.  For example:  Suppose the considerations used to determine eligibility for auto insurance in the USA for well-heeled applicants are different from those for ordinary applicants in terms of income, employment, and experience.  If the two sets of considerations are non-overlapping, the decision logic for the two kinds of cases can be developed separately.

Often, the divide-and-conquer strategy leads to independent subdecisions.  An independent subdecision is one of a collection of two or more decisions on which another decision is dependent, where each subdecision has its own set of distinct (non-overlapping) considerations.

A good example of independent subdecisions is the launching of a space shuttle or manned rocket.  Before the ultimate decision Should the craft be launched?  is addressed, an entire checklist of subdecisions is addressed, each with its own set of considerations.  These subdecisions pertain to weather, fuel systems, communications, down-field recovery, etc.

The decision logic for the decision Is an applicant eligible for auto insurance for USA under $1 million?  might be analyzed as independent subdecisions.  If so, each of the following subdecisions would have its own unique set of considerations.

• Is the applicant's driving history acceptable?
  
  
• Has the applicant given acceptable evidence of insurance?
  
  
• Is the applicant's Insurance Risk Score O.K.?
  
  
• etc.

Figure 1.  Q-Chart for the decision Is an applicant eligible for auto insurance for USA under $1 million?

The decision logic for the overall decision can be portrayed as a Question Chart (Q-Chart for short) as in Figure 1.  This Q-Chart provides a visualization of a decision structure; that is, how some decisions are formally organized.  Q-Charting is an important and powerful new tool for business analysts.^[3]

References

[1] Definite outcome means a real business answer to the question being asked.  An outcome such as unable to determine is not a real business answer.  Any such case is not in scope and must be handed off.

[2]  RuleSpeak is a set of guidelines for expressing business rules in structured natural language.  RuleSpeak guidelines are available for free in English, Spanish, Dutch and German on www.RuleSpeak.com.  All statements of business rules in this discussion use RuleSpeak.

[3]  For more about Q-Charting, refer to:  Ronald G.  Ross, "Introducing Question Charts (Q-Charts™) for Analyzing Operational Business Decisions:  A New Technique for Getting at Business Rules," Business Rules Journal, Vol.  11, No.  12 (Dec.  2010), URL:  http://www.BRCommunity.com/a2010/b567.html

# # #