Learn from the expert (part 2) – textual rules: out of fashion or a classic?

This is the second in a series of columns inspired by one of my recent consulting assignments.  In that project I reviewed the work of a couple of novice rule authors.

Nowadays there is renewed interest in graphical ways to state rules (compared with the textual format used in SBVR and RuleSpeak).  In this column I want to assess if the graphical methods would have helped our novice rule analyst (from the previous column[1]) to write rules better and quicker.

Last time, we ended with the following textual rule:

The end-date of a policy must be equal to the most recent date of the following dates: 

  • date insurer is not eligible,
  • date insurer stops payment of the insurance,
  • date insurer ends the insurance.

Let’s see how this rule is presented in three formats:  Decision table, Decision tree, and Nassi–Shneiderman diagram.

Decision table

Decision tree

Nassi–Shneiderman diagram

In my opinion, the textual form is the most readable version for anyone who has at least finished elementary school, and I believe most business people will agree with me.  What is an easy-to-use best practice that provides guidance for this conclusion?  In other words, how may we know in advance which format is useful for which case?

A graphical representation assumes that a certain algorithm is processed while the diagram is read.  The algorithm for the decision table (for example) can be described as follows:

IF the concept in each column header matches the concept expression in each corresponding cell
THEN perform the action in the same row as the cell and continue with the next row.

When the logic of a given rule easily fits the diagram’s algorithm we may find that presentation useful for the rule.  However, since the logic we wanted to express in our example rule does not fit the algorithm for a decision table at all, the table version of our rule does not read well.

Below is an example of a rule that does fit well in a decision table (green), along with some rules that do not fit well (red).

  • The discount for a customer must be equal to 20% if the customer is a gold customer.
  • Net income must be equal to the sum of the gross income plus taxes.
  • A visitor must show an ID.
  • A shipment always has a destination.

Keep in mind that the one that fits well with a decision table representation uses the word IF (like the algorithm for a decision table).

Hmmm….  Does this mean that we can’t use graphics at all for such rules?  There are some alternatives that may be useful.  I will discuss these in my next column.  Meanwhile, you can look at the new whitepaper on decision tables from Ron Ross.[2]

Want to know more? Let me know by sharing this post.

This article was originally published by BRCommunity (link).


[1]  Silvie Spreeuwenberg, “Learn from the Expert (Part 1) — A Business Analyst must ask “Why?”,” Business Rules Journal, Vol. 12, No. 3 (Mar. 2011), URL: http://www.BRCommunity.com/a2011/b584.html
[2]  Ronald G. Ross, Decision Analysis Using Decision Tables and Business Rules, URL:  http://www.brsolutions.com/b_decision.php