Extracted from Decision Tables: A Primer: How to Use TableSpeak™, by Ronald G. Ross, 2013, available (free) on http://www.brsolutions.com/IPSpeakPrimers

See [glossary definitions] for terms colored like this:  decision table

---

An example of a simple decision table is presented in Figure 1.  This decision table addresses the question What coat should be worn?

Figure 1.  Example of a Simple Decision Table

The decision table in Figure 1 can be used to answer four specific variations of the question What coat should be worn?, as follows.

1. What coat should be worn if it is cold and rainy?
   
   
2. What coat should be worn if it is cold and not rainy?
   
   
3. What coat should be worn if it is not cold and not rainy?
   
   
4. What coat should be worn if it is not cold but rainy?

The answers can be found in the appropriate intersection cells (for convenience, lightly colored), starting at the top row on the left, then reading clockwise.

Decision Rules and Outcomes

The answers to the four specific questions above represent four decision rules, which could be expressed as follows.

1. A lined raincoat should be worn if it is cold and rainy.
   
   
2. A wool overcoat should be worn if it is cold and not rainy.
   
   
3. A coat need not be worn if it is not cold and not rainy.
   
   
4. An unlined raincoat should be worn if it is not cold but rainy.

A decision rule is a business rule that guides the making of an operational business decision, a business rule that provides a specific answer to a selective question.

A significant benefit of using decision tables is that there is no need to write out the decision rules as above (unless desired for clarification).  Appropriate outcomes simply appear in the decision cells of the decision table.

An outcome is the result, conclusion, or answer given by a decision rule to a selective question being asked.  Example: 

Lined raincoat is the outcome given by the decision rule A lined raincoat should be worn if it is cold and rainy.

The outcome given by a decision rule is selected from among a set of potential outcomes, all the individual outcomes permitted for answering the overall question.  Potential outcomes for the decision table in Figure 1 include at least: 

1. lined raincoat
   
   
2. wool overcoat
   
   
3. no coat (none)
   
   
4. unlined raincoat

Other potential outcomes might exist besides these four.  Identifying the complete set of potential outcomes is always an important concern in decision analysis.

What a Decision Table Is

A decision table is simply a structured means of visualizing decision rules in rows and columns.

A decision table in TableSpeak always

• addresses questions — once generally and many times specifically.
  
  
• implicitly represents decision rules.
  
  
• provides answers (outcomes) selected from among potential outcomes.

A key word in the definition of decision table is visualizing.  Decision tables are a means of representing decision rules for viewing and updating in the best (most business-friendly) way possible.

Decision tables are not a data management or database scheme — an entirely different issue.  Some practitioners — and experts as well — are quite confused on this important point.^[1]

Not every table, of course, is a decision table.  Tables can be used productively for a great many purposes.  If a table does not represent decision rules fully the table is not a decision table.

About TableSpeak™ TableSpeak is a BRS set of conventions for business-friendly representation of decision tables and their meaning (semantics) in declarative fashion. Central to TableSpeak are: Highly pragmatic guidelines and thresholds for selecting the best decision-table format.  TableSpeak avoids simplistic and counterproductive one-size-fits-all approaches. The principle of single-sourcing, essential for achieving true business agility. Restrictions — business rules for ensuring the integrity (correctness) of decision-table content. TableSpeak optimizes for readability by non-IT professionals and business people. The question the decision table answers is always emphasized. Scope (applicability) is declared explicitly. Unnecessary complications to decision-table structure (such as exceptions) are externalized. Meaning is comprehensively expressed. Business vocabulary is carefully used. Decision tables based on TableSpeak are free of hidden assumptions and implicit interpretation semantics.

The Cases that a Decision Table Addresses

What we want from a decision table are the answers to a question.  First, however, the decision table must be structured properly to provide and manage these answers in optimal fashion.

The most fundamental idea in structuring a decision table is that it addresses particular cases of interest.

A case is simply some particular situation — nothing more, nothing less.  Cases might be called scenarios, but we prefer the term case to avoid any sense of events or actions — i.e., 'flow'.  Think of a case as a snapshot of circumstances that at least momentarily don't flow.

The decision table in Figure 1 specifically addresses the following four cases:

1. It is cold and rainy.
   
   
2. It is cold but not rainy.
   
   
3. It is not cold and not rainy.
   
   
4. It is not cold but rainy.

These four cases are composite.  Each is clearly based on two factors rather than just one:

1. Is it cold?
   
   
2. Is it rainy?

In TableSpeak these factors are called considerations.

A consideration is a factor in making an operational business decision; something that can be resolved to two or more cases.

Important points:

How should considerations be worded?

Although considerations can always be worded as questions (as above) we do not insist on that.  For example, the two considerations above could be called temperature and precipitation, respectively.

The key is to word or name each consideration in a clear, business-friendly fashion.

How many considerations should a decision table include?

The decision table in Figure 1 involves two considerations.

Many decision tables, of course, involve more than that.  As more considerations are added, the complexity of representation, analysis, and management naturally escalates.

It is generally recommended that the number of considerations for a decision table not exceed 7.

What kinds of cases can considerations produce?

Considerations produce two fundamental kinds of cases, elemental and intersection, as discussed below.

Elemental Cases

An elemental case is a case produced directly from a single consideration.  Examples: 

1. The consideration Is it cold? produces the two elemental cases:

• Yes, it's cold.
• No, it's not cold.

2. The consideration Is it rainy? also produces two elemental cases:

• Yes, it's rainy.
• No, it's not rainy.

How should elemental cases be worded?

Elemental cases need not be specified in quite so wordy a fashion as above.  For example, simply yes and no would probably suffice.  TableSpeak, however, always focuses on avoiding any possibility of ambiguity or misinterpretation.  Good judgment in this regard should be exercised.

Note that cases are never worded as questions.

How many elemental cases can a consideration produce?

The two considerations above are binary — they each produce two elemental cases.  Many considerations produce more than two cases.  Examples:

• category of customer might produce three cases — platinum, gold, and silver.
  
  
• province of Canada produces ten cases.
  
  
• zip code or postal code can produce many thousands of elemental cases.

Each consideration should always produce at least two elemental cases.

A factor that results in only one elemental case (in scope) — e.g., California — can be handled in some better way.  Such a consideration might be treated as a scope item or an exception.

What quality considerations apply to the elemental considerations?

It is extremely important that the set of elemental cases for a consideration be

1. exhaustive (inclusive of all cases in scope).
   
   
2. disjoint (non-overlapping).

Anomalies can occur in decision tables when these quality criteria are not satisfied.

Intersection Cases

An intersection case is a compound case involving two or more elemental cases.  Example: 

The intersection case It is cold and rainy. is produced from the two considerations:

1. Is it cold?
   
   
2. Is it rainy?

A decision table with only one consideration does not comprise any intersection cases.  Since most decision tables involve two or more considerations, however, most do involve intersection cases.

---

How intersection cases are handled is a central issue in structuring decision tables.  Part 2 of this 3-part series explains and identifies the fundamental styles of decision tables.

References

[1]  In terms of three-schema architecture, decision tables are an external schema.  Refer to:  http://en.wikipedia.org/wiki/Three_schema_approach  

# # #