I received an email from one of my mentees who was struggling to explain to his stakeholders a series of operational conditions with many different rules — everyone was frustrated and confused.  After reading the first few paragraphs, I realized there was an obvious solution to his communication problem:  build a decision table.

I would argue a decision table is a critical tool for a Business Analyst for the following reasons:

• simplification of rule statements,
• identification of "hidden" conditions,
• recognition of repeating results,
• reuse for the entire software development life cycle, from the business requirements to software development to testing.

What exactly is a decision table?

Ron Ross in Business Rule Concepts 4th Edition defines a decision table to "…represent sets of business rules" and provides three conditions suitable for decision table creation:

• A number of the rules are similar, "…the business rules all share a common pattern and purpose."
• Each rule has a finite number of occurrences.
• The outcomes are different.

A decision table always begins with a question requiring an operational decision and the associated rules needed to make a correct action.  The decision table does not require specific software but may be built using spreadsheet or word processing software available to any BA.  There are different variations of the structure of the decision table but all include:

• conditions,
• business rules,
• actions or decisions based on combination of business rules for each condition.

The decision table is a matrix with each condition as a row and each business rule as a column; the typical construction will list all possible actions in a section below the list of conditions.  Each business rule is analyzed with "True" or "False" (or "Yes" or "No") alternatives; "Does not apply" may be included.  A decision rule must be related to an action.  If there may be circumstances where "Does not apply" is found across all conditions, these should be removed from the decision table.

The number of rules can be calculated as 2ⁿ where n = the number of rules.  For example, if there are four conditions then the number of rules is 24 or 32.  By comparing the decision table rules to the mathematical result, the BA can determine if more analysis is necessary.  Impossible combinations may also surface; those should be eliminated.  Redundant conditions will be discovered; these need to be removed as well, and the final decision table should be in normalized form.

A decision table does have limitations.  A major drawback is that the number of rules rises rapidly; this may be remedied by decomposing the decision table.  The decision table also does not describe the process flow or the sequence of the conditions and rules.  A complementary decision tree may also need to be developed.

If you want to learn more about decision tables, I recommend downloading the free document, "Decision Tables — A Primer:  How to Use TableSpeak," available from Ron Ross at www.brsolutions.com/publications/decision-tables-a-primer/

# # #