Is this you?
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, 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.
Start with an IF
Conditions are the ‘IFs’ and possibly the ‘WHENs’. E.g.,
- IF order value greater than £500.00
- IF client is loyalty scheme member
However, in decision tables we do not include the IF word. For example, we could simply write:
- Order value greater than £500.00
- Client is loyalty scheme member
Imagine a question mark at the end of each of the above statements, e.g. Order value greater than £500.00?
This is either TRUE or FALSE. Some decision table users refer to YES and NO. The more mathematically minded might even use the numbers ‘1’ and ‘0’ instead of true or false, yes or no.
Brainstorm or workshop all the conditions that you can think of. One of the great things with decision tables is that you can write them down in any order.
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.
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:
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’.
Having identified the conditions, we can identify actions. Note that we could have identified the actions before we identified each of the combinations of conditions, i.e. the rules. Decision tables allow us great flexibility in the order with 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
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
- If a room is available
- 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
- 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
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
Not every requirement is best specified with 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.