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

---

No decision table is complete until its meaning (semantics) has been fully exposed.  Otherwise, opportunities for misinterpretation abound.

The meaning of a decision table involves two core aspects:

Aspect of Meaning 1.  The individual meanings of terms and wordings — i.e., the business vocabulary — used for the decision table.

A decision table should always be based on a structured business vocabulary (concept model).

Aspect of Meaning 2.  The collective purpose and relevance (semantics) of the decision table.

Three TableSpeak approaches for explicitly communicating the collective semantics of a decision table are discussed below, along with advantages and possible disadvantages of each.  The discussion focuses on two items of special importance, name and scope.

Other important items include defaults, exceptions, and restrictions.

Without adequate clarification of both aspects of meaning, a decision table cannot serve its purpose very well, whether for actually running the business or as a requirement for IT development.  Remember, as is true for all business rules, you can never be sure who will eventually view a decision table, or for what purpose they might try to use it.

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 Name of a Decision Table

Common industry practice is to name a decision table roughly after what it concerns.  The decision table in Figure 1, for example, concerns the choice of coats, so it might be called Coat Table.

Figure 1. Example of a Simple Decision Table

TableSpeak, however, recognizes the central importance to the business of the question that a decision table answers.  That question is fundamental to what the decision table represents (i.e., its meaning).

We strongly recommend using the question as the table's name.

Instead of Coat Table, for example, we would recommend What coat should be worn?

The Scope of a Decision Table

Addressing scope is essential for analyzing operational business decisions and representing the decision logic that supports them.  Delineating scope for operational business decisions is often not a trivial matter.  With respect to decision tables, misuse is almost guaranteed without adequate specification and communication of scope.

For example, suppose the decision table in Figure 1 was created to represent decision logic applicable to just females, and just to San Francisco.  Use of the decision logic for males or any other city would therefore be unwarranted and very likely incorrect.  Such use would represent inductive reasoning, something generally inappropriate for business rules.

Unless the scope of a decision table is universal within a business (not impossible but seldom the case), some explicit scope item(s) should be expressed for the decision table.  The scope items for the decision table in Figure 1, for example, could be expressed as follows.  (An implicit 'and' is always assumed between scope items.)

• gender:  female
  
  
• city:  San Francisco

Scope items also serve as a TableSpeak technique to achieve the crucial objective of keeping decision tables as simple as possible.  For example, treating gender and city as considerations for the decision table in Figure 1 is pointless (at least at the present time).  Doing so would simply add complexity — and that complexity would compound as the size of the decision table grows.

A final observation:  Scope items do not preclude modifying a decision table to broaden its coverage.  When the scope is broadened, the relevant scope items should simply be dropped or revised as appropriate.

Now let's examine the three approaches for explicitly communicating the collective semantics of a decision table.

Approach to Semantics 1:  Wrapper Rule Statement

A concern in rule management is often that decision tables participate fully in a larger body of guidance (business rules) that also includes a significant number of textual business rule statements.  In this circumstance writing a wrapper rule statement for the decision table often proves the best approach.  That way each decision table has a specific textual 'handle' in and among all the other rule statements.

The wrapper rule statement for a decision table indicates what the decision table represents and how it should be interpreted — i.e., how to 'read' the decision table.  For example, an appropriate wrapper rule statement for the decision table in Figure 1 might be expressed as follows.  (Note that the two scope items have been carefully included as qualifications.)

Wrapper Rule Statement:  The coat for a female person to wear in San Francisco must be as in the decision table 'What coat should be worn?'

Suppose these scope items can be suitably documented elsewhere and still remain highly visible whenever the decision table is used (a bit doubtful).  A shorter 'stub' version might be:

Revised Version:  The coat to wear must be as in the decision table 'What coat should be worn?'

Approach to Semantics 2:  Embedded Semantics

A second approach aims at making the decision table itself as self-explanatory and as self-contained as possible.  This approach involves embedding its collective semantics directly into it.  No wrapper rule statement is necessary.  Figure 2 illustrates.

Figure 2.  Decision Table with Embedded Semantics

In this approach, both of the following have been directly embedded within the decision table:

• the question the decision table addresses (which also serves as the name of the decision table)
  
  
• the two scope items

This approach serves quite well for this simple example.  As additional semantics are added, however, such representation can become increasingly cluttered.

Approach to Semantics 3:  Decision Box

A third approach aims toward providing a focal point for managing all the interrelated semantics of a more complex decision table.  This approach involves creating a paired decision box for each decision table, which always appears whenever the decision table itself appears.  Again, no wrapper rule statement is necessary.  Figure 3 illustrates.

Figure 3.  Decision Table with Paired Decision Box

This decision table features a paired decision box providing the table's collective semantics:

• the question the decision table addresses (which also serves as the name of the decision table)
  
  
• the two scope items

The usefulness of a decision box becomes more and more apparent as the number and complexity of specifications related to the decision table increase.  As mentioned earlier, such specifications can include defaults, exceptions, and restrictions.

Besides high visibility for these aggregate semantics, the decision box also provides a focal point for managing all such specifications as a unit (i.e., single-sourced).  These specifications can prove quite difficult to coordinate on an individual basis apart from the decision table.

To highlight the importance of the aggregate semantics, sometimes the best approach is to put the decision table inside its decision box.  Figure 4 illustrates.

Figure 4.  Decision Box with Embedded Decision Table

# # #