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

Question Charts (Q-Charts for short) provide a means to diagram and visualize the structure of decisions.  In a Q-Chart, an elongated hexagon stands for a decision.  The question representing the decision is indicated inside the hexagon.

We use the hexagon shape itself in facilitated sessions and other analysis work for brainstorming key elements of a decision.  As illustrated in Figure 1, a Q-COE™ is a graphic representation of a decision indicating what question ("Q") is being asked, and usually one or more of the following:  considerations ("C"), outcomes ("O"), and exceptions ("E").

Figure 1.  A Q-COE for Brainstorming the What coat should be worn today? Decision^[1] 

A Q-COE is an intermediate step toward development of actual, complete decision logic in the form of some decision table(s).  For example, the Q-COE in Figure 1 as yet indicates no outcome for the exceptional case, Halloween.  This decision logic is clearly not yet in a form that is deployable into the business or its systems.

In general, decision analysis always begins in 'sketch' mode, where the four key elements of a decision are captured, named, analyzed, and organized.  Too much structure early-on works against effective collaboration and dialog.

Later on, Q-Charts become more rigorous as decision analysis moves into detail mode.  For example, the expression of scope items and exceptional cases should be refined and carefully coordinated with the fact model.  Then decision tables — complete with consideration restrictions, outcome restrictions, and possibly defaults — take center stage.

Decision Dependency

In a Q-Chart, connections between decisions always pertain to dependencies between the decisions.  A dependency between decisions occurs when one decision is prerequisite for another.  To avoid any possible suggestion of flow or sequence (as in a process model), dependency connections in Q-Charts are always oriented vertically rather than horizontally.

As shown in Figure 2, a dependency connection always includes a hitch point (a solid circle) at the bottom.  The hitch point always goes with the decision most able to stand on its own — i.e., with the bottom, more independent decision.

Figure 2.  Dependency Between Decisions

There are two fundamental kinds of decision dependency in Q-Charts:  consideration dependency and relevance dependency, represented by solid lines and dashed lines, respectively.

Consideration Dependency

In consideration dependency, one decision depends on the outcome of another decision such that the outcome of the latter decision provides or supports one of the considerations for the dependent decision.  In the coat problem, for example, it might not be possible to decide what coat to wear unless you decide whether it is cold.  Deciding whether it is cold might have considerations all its own.  This consideration dependency is illustrated in Figure 2 using a solid-line connector.

Relevance Dependency

In relevance dependency, one decision depends on the outcome of another decision such that the outcome of the other decision may completely eliminate the need for any outcome from the dependent decision.  In the auto insurance problem, for example, if an applicant is not eligible for coverage, there is no need to determine what to charge the applicant as a premium.  In other words, the dependent decision is preempted — indeed, meaningless.  This relevance dependency between decisions is illustrated in Figure 3 using a dashed connector.

Figure 3.  Relevance Dependency Between Decisions

Do processes always have to ask the questions in a relevance dependency in bottom-to-top sequence?  No, but caution should be exercised.

For the questions in Figure 3, for example, a customer-friendly, web-based application might permit price-conscious consumers to ask about the premium before asking about eligibility.  If so, it would probably be a good idea to include a disclaimer indicating that securing coverage at the given price is subject to eligibility.  An explicit business rule should be written for that purpose.  The rule ensures a disclaimer is given by any process or use case that supports a price-before-eligibility sequence.

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 similarly 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.

The decision logic for the overall decision can be portrayed as a Question Chart (Q-Chart for short) as in Figure 4.  This Q-Chart provides a visualization of overall decision structure; that is, how related decisions are formally organized.

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

References

[1]  Adapted from:  Decision Tables in Software Engineering, by Richard B. Hurley, Van Nostrand Reinhold Company, New York (1983), pp. 8-10.

# # #