A decision table is a table composed of rows and columns, separated into four separate quadrants.
| Conditions | Condition Alternatives |
| Actions | Action Entries |
In order to build decision tables, you need to determine the maximum size of the table, eliminate any impossible situations, inconsistencies, or redundancies, and simplify the table as much as possible. The following steps provide offer some guidelines to developing decision tables:
1. Determine the number of conditions that may affect the decision. Combine rows that overlap, for example, conditions that are mutually exclusive. The number of conditions becomes the number of rows in the top half of the decision table.
2. Determine the number of possible actions that can be taken. This becomes the number of rows in the lower half of the decision table.
3. Determine the number of condition alternatives for each condition. In the simplest form of decision table, there would be two alternatives (Y or N) for each condition. In an extended-entry table, there may be many alternatives for each condition.
4. Calculate the maximum number of columns in the decision table by multiplying the number of alternatives for each condition. If there were four conditions and two alternatives (Y or N) for each of the conditions, there would be sixteen possibilities as follows:
| Condition 1: | x | 2 alternatives |
| Condition 2: | x | 2 alternatives |
| Condition 3: | x | 2 alternatives |
| Condition 4: | x | 2 alternatives |
| 16 possibilities |
5. Fill in the condition alternatives. Start with the first condition and divide the number of columns by the number of alternatives for that condition. In the foregoing example, there are sixteen columns and two alternatives (Y and N), so sixteen divided by two is eight. Then choose one of the alternatives and write Y in all of the eight columns. Finish by writing N in the remaining eight columns as follows:
Condition 1 YYYYYYYYNNNNNNNN
Repeat this for each condition using a subset of the table:
Y Y Y Y Y Y Y Y N N N N N N N N Y Y Y Y N N N N Y Y N N Y N and continue the pattern for each condition:
Condition 1 Y Y Y Y Y Y Y Y N N N N N N N N Condition 2 Y Y Y Y N N N N Y Y Y Y N N N N Condition 3 Y Y N N Y Y N N Y Y N N Y Y N N Condition 4 Y N Y N Y N Y N Y N Y N Y N Y N
6.Complete the table by inserting an X where rules suggest
certain actions.
7.Combine rules where it is apparent that an alternative does
not make a difference in the outcome; for example:
| Condition 1 | Y Y |
| Condition 2 | Y N |
| Action 1 | X X |
| Condition 1 | Y |
| Condition 2 | -- |
| Action 1 | X |
8.Check the table for any impossible situations, contradictions,
redundancies.
9. Rearrange the conditions and actions (or even rules) to make
the decision table more understandable.
A store wishes to program a decision on non-cash receipts for
goods into their intelligent tills.
The conditions to check are agreed as:
1. Transaction under £50
2. Pays by cheque with cheque card (guarantee £50)
3. Pays by credit card
The possible actions that a cashier could take are agreed as:
1. Ring up sale
2. Check credit card from local database
3. Call a supervisor
4. Automatic check of credit card company database
Using the rules above construct a decision table showing all possible combinations of alternatives.
The condition rules are yes or no, therefore the number of possible condition rules are 2 alternatives for condition 1 x 2 alternatives for condition 2 x 2 alternatives for condition 3 or 2 3 = 8
| Under £50 | Y | Y | Y | Y | N | N | N | N |
| Pays by cheque | Y | Y | N | N | Y | Y | N | N |
| Pays by credit card | Y | N | Y | N | Y | N | Y | N |
| Ring up sale | ||||||||
| Check from local database | ||||||||
| Call Supervisor | ||||||||
| Check credit card database |
We can see that some of the condition rules are invalid, the customer cannot pay by cheque AND pay by credit card or not pay by either method. We have decided that these combinations are mutually exclusive. This decision table can be reduced to 4 condition rules.
| Under £50 | Y | Y | N | N |
| Pays by cheque | Y | N | Y | N |
| Pays by credit card | N | Y | N | Y |
| Ring up sale | ||||
| Check from local database | ||||
| Call Supervisor | ||||
| Check credit card database |
Indicate the actions.
| Under £50 | Y | Y | N | N |
| Pays by cheque | Y | N | Y | N |
| Pays by credit card | N | Y | N | Y |
| Ring up sale | X | |||
| Check from local database | X | |||
| Call Supervisor | X | |||
| Check credit card database | X |
Check for completeness.
What if the customer has not shopped their before? Missing some as obvious as this means reconstructing the table!
The conditions are now:
1. Transaction under £50
2. Pays by cheque with cheque card (guarantee £50)
3. Pays by credit card
4. Unknown customer
The actions remain the same but the number of condition rules increases by a multiple of 2.
| Under £50 | Y | Y | Y | Y | N | N | N | N |
| Pays by cheque | Y | Y | N | N | Y | Y | N | N |
| Pays by credit card | N | N | Y | Y | N | N | Y | Y |
| Unknown customer | Y | N | Y | N | Y | N | Y | N |
| Ring up sale | ||||||||
| Check from local database | ||||||||
| Call Supervisor | ||||||||
| Check credit card database |
The dash in the Pays by credit row indicates that it does not matter about the condition rule since if a customer pays by cheque they will not pay by credit card and vice versa ( mutually exclusive ).
| Under £50 | - | Y | - | Y | - | N | - | N |
| Pays by cheque | Y | Y | N | N | Y | Y | N | N |
| Pays by credit card | - | - | - | - | - | - | - | - |
| Unknown customer | Y | N | Y | N | Y | N | Y | N |
| Ring up sale | X | |||||||
| Check from local database | X | |||||||
| Call Supervisor | X | X | X | |||||
| Check credit card database | X | X | X |
Look for redundancies, contradictions and impossible situations.
| Under £50 | - | Y | - | Y | - | N | - | N |
| Pays by cheque | Y | Y | N | N | Y | Y | N | N |
| Pays by credit card | - | - | - | - | - | - | - | - |
| Unknown customer | Y | N | Y | N | Y | N | Y | N |
| Ring up sale | X | |||||||
| Check from local database | X | |||||||
| Call Supervisor | X | X | X | |||||
| Check credit card database | X | X | X |
The red and cyan columns are repeats and one is therefore redundant.
| Under £50 | - | Y | - | Y | N | N |
| Pays by cheque | Y | Y | N | N | Y | N |
| Pays by credit card | - | - | - | - | - | - |
| Unknown customer | Y | N | Y | N | N | N |
| Ring up sale | X | |||||
| Check from local database | X | |||||
| Call Supervisor | X | X | ||||
| Check credit card database | X | X |
Some condition rules can be combined by examing the action
stub for identical actions and the pay by credit row in the condition
stub can be removed since it can create an impossible situation.
| Under £50 | - | Y | - | Y | N | N |
| Pays by cheque | Y | Y | N | N | Y | N |
| Pays by credit card | - | - | - | - | - | - |
| Unknown customer | Y | N | Y | N | N | N |
| Ring up sale | X | |||||
| Check from local database | X | |||||
| Call Supervisor | X | X | ||||
| Check credit card database | X | X |
Final version of the decision table.
| Under £50 | Y | Y | N | N |
| Pays by cheque | Y | N | Y | N |
| Unknown customer | N | N | - | - |
| Ring up sale | X | |||
| Check from local database | X | |||
| Call Supervisor | X | |||
| Check credit card database | X |