Decision tables are a great way for business analysts to capture situations, requirements, and business rules which have multiple conditions. They ensure that every situation is covered and can be represented as an easy to understand table. 

Estimated reading time: 9 minutes

Is this you?

Have you ever struggled to capture business rules or requirements that involve multiple conditions?

If yes, you’re not alone. I’ve met many business analysts struggling to specify business rules and multiple conditions using techniques such as user stories or traditional requirements formats. And they end up in a tangle.

When I demonstrate decision tables, it’s like an epiphany. I’ve even had analysts ask if they’re allowed to use the technique – “Shouldn’t we be using user stories?”

Decision tables are a great technique for business analysts, business architects, developers, business rules specialists and testers alike. They are equally applicable to agile and to traditional teams. And the good news is, they’re simple to learn.

There are two forms of decision table. In this article we’ll look at the most basic form, known as ‘limited entry’.

We start with the conditions.

Conditions in decision tables

Start with an ‘IF’

Conditions are the IFs and possibly the WHENs, in a specification, e.g.

• IF order value greater than £500.00
• IF client is loyalty scheme member

However, in decision tables, we do not include IFs and WHENs explicitly. Instead, we simply make statements, e.g.

• Order value greater than £500.00
• Customer is loyalty scheme member

Imagine that there is a question mark (?) at the end of each of the above two statements. E.g.,

Order value greater than £500.00?

Customer is loyalty scheme member?

These statements are either true or false. e.g.

True

• Order value is greater than £500.00
• Customer is a loyalty scheme member?

False

Order value is not greater than £500.00

Customer is not a loyalty scheme member

Yes/No – 1/0

Some decision table users refer to YES and NO rather than true and falso. The more mathematically minded might even use the numbers ‘1’ and ‘0’ (zero) instead of true or false, yes or no.

Procedure for completing a decision table

For a given specification, get the team to brainstorm or workshop all the conditions that the can think of.

One of the great things with decision tables is that you can list the conditions in any order, so write them down as soon as anyone calls one out.

Decision tables can handle any number of conditions but to explain the technique we’ll start with a very simple situation with only two conditions.

Example showing how to list conditions

The situation is a hotel check-in. Possible conditions might be:

• Does the client have a booking?
• Is there a room available?

The column of conditions is known as the ‘condition stub’

True or false?

Each condition is either true or false, e.g. the guest either has a booking or they don’t. A typical beginner’s mistake is to add additional conditions such as, ‘Guest does not have a booking’; this is unnecessary.

In the diagram labelled ‘Simple Conditions’, we have represented ‘True’ with a ‘Y’ for YES. We have represented ‘False’ with an ‘N’ for ‘No’.

Combinations of conditions – Rules

You can see that with two conditions there are 4 possible combinations of true and false. A great thing about decision tables is that we can be absolutely certain that we have identified all combinations of conditions; we have missed nothing.

If there are 3 conditions, there are 8 combinations of true and false.

For 4 conditions there are 16 combinations of true and false.

You can probably see that the number of combinations rises steeply with each extra condition. But however large the number combinations becomes, we can be absolutely certain that we have identified all of them; we will have missed nothing. That should be reassuring to business analysts, solutions architects, programmers, testers, project managers and business stakeholders.

The good news is that there are a couple of techniques we can apply to simplify complex tables. These are known as:

• Indifference
• Else

We shall examine these later.

We have labelled each combination of  conditions as a ‘Rule’; i.e. Rule 1, Rule 2, Rule 3 and Rule 4. In the language of decision tables, these are collectively known as the ‘condition entries’.

Actions in decision tables

Having identified the conditions, we can identify actions. Note that we could have identified the actions before we identified each combination of conditions, i.e. the rules. Decision tables allow great flexibility in the order in which we do things.

In our example, we have identified four actions:

• Check in guest
• Create booking
• Find room in another hotel
• Recompense guest

This set is referred to as the ‘action stub’.

In our decision table, we have listed the actions below the conditions. We have separated conditions and actions with a thick blue line.

We could have listed the actions in any order we like. There is no limit to the number of actions we can identify.

Associating Rules and Actions

The combination of conditions, as defined in the rules, with the actions is a way of writing business rules.

For each combination of conditions, i.e. for each rule, we examine each action in turn.

For each rule, we determine whether or not an action is applicable. We do this by putting an X where it is applicable and a dash (–) where it’s not.

If the action is applicable for a particular rule, put an ‘X’ in the cell for that action in the column for that rule. E.g.

• If a guest has a booking
• AND
• If a room is available
• THEN
• Check in guest.

In the diagram, ‘Condition and Action Stubs + Condition Entries‘, notice the ‘X’ in:

• Row: ‘Check in guest’
• Column: Rule 1

If the action is not applicable, either:

• Put a dash, ‘-‘, in the cell
• OR
• Leave cell empty

For example, notice in the diagram that there is a ‘-‘ in the column, ‘Rule 1’, for each of the the following action rows,

• Create booking
• Find room in another hotel
• Recompense guest

I.E., none of these 3 actions is applicable if the guest has a booking and a room is available.

More complex decision tables

The example, ‘Incomplete decision table with 3 conditions’, shows  all the combinations of true and false, or yes and no, when there are three conditions.

We can see that in this case there 8 possible combinations of true and false (yes and no), denoted by rules 1 – 8.

The decision table format gives us confidence that there are no more possibilities. We have not missed anything.

We can similarly handle 4 or more conditions. Each time we will know that we have identified all possible combinations.

However, it’s always a good idea to try to simplify things a bit.

Simplifying complex decision tables

If there are many conditions, a decision table can become very large. Fortunately we can usually manage to simplify such tables by using ‘indifference’ and ‘else’

Simplifying by using the ‘Indifference’ symbol

The indifference symbol is a ‘-‘ (i.e. a dash or a hyphen).

The example shown in the adjacent diagram, ‘Partial decision table showing indifference’, is based on a scenario such as purchasing a train ticket online.

Before the payment can be processed, it is often necessary to accept the terms and conditions (T&Cs). This is usually done by clicking in a checkbox.

If the user had not indicated acceptance of the T&Cs, the payment cannot be processed. Typically the system displays a message telling the user that they must accept.

In our diagram, there is an ‘N’ in Rule 1 of the ‘Terms and conditions agreed’ row.

The ‘N’ tells us that the T&Cs have not been accepted. In that case, it does not matter what is in the other conditions for Rule 1. The resultant action will always be the same. If T&Cs have not been agree, we are not going any further.

The action is ‘Display “T&Cs must be agreed” ‘. In the diagram there is an X in the row for that action.

There are likely to be similar conditions, e.g.

• Card payment details incorrect
• Post code missing
• etc.

Items such as the above are mandatory for payment processing to proceed.

Simplifying with Else

Having dealt with cases such as mandatory items being completed, we often find that all other rules result in the same action or actions. This allows us to replace all of those rules (columns) with a single column labelled ELSE. See the adjacent diagram, ‘Partial decision table showing use of ELSE’.

Notice that all the cells in the ELSE column are blank. ELSE represents all situations other than the three covered by rules 1, 2 and 3.

The table shows us that for all situations other than for rules 1, 2 and 3, the resultant actions are:

• Action 2
• Action 3

Summary

Not every requirement is best specified as a user story or a use case or with traditional formats such as, “The user shall …..”.

Decision tables are a useful technique for business analysts when specifying applications and systems that involve multiple conditions and business rules.

They are also useful for programming, design, testing and management.

Try adding them to your toolbox of business analysis techniques.