Computer Science 9608 (Notes)

Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Decision tables are compact and precise ways of modeling complicated logic, such as that which you
might use in a computer program. Decision tables can make it easy to see that all the possible
combinations of conditions have been discovered and when conditions are missed, it is easy to see this.
Decision tables make troubleshooting easy by mapping the different states of a program to an action that
a program should perform. Decision tables take on the following format:

The limited-entry decision table is the simplest to describe. The condition alternatives are simple Boolean
values, and the action entries are check-marks, representing which of the actions in a given column are to
be performed.

A technical support company writes a decision table to diagnose printer problems based upon symptoms
described to them over the phone from their clients. They type the following data into the advice program:

Printer does not print

Red light is flashing

Printer is recognized

The program then uses the decision table

to find the correct actions to perform,
namely that of Check / Replace Ink.

Page 1 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Lets take an example for an ATM where a decision table would be of use.

A customer requests a cash withdrawal. One of the business rules for the ATM is that the ATM machine
ejects the cash amount if the customer has sufficient funds in their account or if the customer has the
credit granted. Already, this simple example of a business rule is quite complicated to describe in text. A
decision table makes the same requirements clearer to understand:

In a decision table, conditions are usually expressed as true (T) or false (F). Each column in the table
corresponds to a rule in the business logic that describes the unique combination of circumstances that
will result in the actions. The table above contains three different business rules, and one of them is the
withdrawal granted if the requested amount is covered by the balance. It is normal to create at least one
test case per column, which results in full coverage of all business rules.

One advantage of using decision tables is that they make it possible to detect combinations of conditions
that would otherwise not have been found. And therefore not tested or developed. The requirements
become much clearer and you often realize that some requirements are illogical. (Something that is hard
to see when the requirements are only expressed in text.)

A disadvantage of the technique is that a decision table is not equivalent to complete test cases
containing step-by-step instructions of what to do in what order. When this level of detail is required, the
decision table has to be further detailed into test cases. (not of our concern right now)

Page 2 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Step 1 Analyze the requirement and create the first column
U

Requirement: Withdrawal is granted if requested amount is covered by the balance or if the customer is
granted credit to cover the withdrawal amount.

Express the conditions are resulting actions in a list so that they are either TRUE or FALSE. In this case,
there are 2 conditions, withdrawal amount balance and credit granted. There is one result, the
withdrawal is granted.

Step 2 Add Columns

U

Calculate how many columns are needed in this table. The number of columns depends on the number of
conditions and the number of alternatives for each condition. If there are 2 conditions and each condition
can be either true are false, you need four columns. If there are three conditions there will be eight
columns are so on.

Mathematically, the number of columns is 2conditions. In this case 22 = 4 columns.

P P P P

Rule of thumb is that you should create many smaller decision tables instead of fewer larger ones,
otherwise you can run the risk of the decision tables being so large as to be unmanageable. Test the
technique by picking areas with fewer business rules.

Page 3 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Now its time to fill in the T (TRUE) and F (FALSE) for the conditions. How do you know that? The simplest
is to say that is should look like this:

Row 1: T F
Row 2: T T F F
Row 3: T T T T F F F F

In our example, the decision table would look something like this:

Step 3 Reduce the table

U

Mark the insignificant values with -. If the requested amount is less than or equal to the account
balance, the customer will not want to opt for a credit withdrawal. In the next step, you should simplify the
table.

Check for
invalid
combinatio
ns. Invalid
combinatio
ns are
those that
cannot
happen, for example, that someone is both an infant and a senior. Mark them somehow with an X
maybe. In this example, there are no invalid combinations.

Finish by removing duplicate columns, In this case, the first and third column are equal, thus one of them
is removed.

Page 4 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Step 4 Determine actions

Enter actions for each column in the table. You will be able to find this information in the requirement.
Name the columns (the rules). They may be names R1/Rule 1, R2/Rule 2 and so on, but you can also give
them more descriptive names.

Lets take a look at a computer game example, for a football simulation the following rules are set up. In
this example, the rules have been predefined, so we do not have to fill up the table with T F T F etc

Page 5 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

What happens if:

1. 90 minutes are up (Ans Keep Playing)

2. The game is a draw (Ans Keep playing and give them some extra time)

Another example: Create a decision table for the following program in an office email system

Send an email when recipient address present, subject present, before 5:30 pm

If after 5:30 pm, then put it in pending folder

If recipient address is missing or subject message, show error message

First what we do is to create the decision table and populate the conditions section with the appropriate
rules.

Then we mark Xs in the actions column according to the criteria in the conditions section.

Finally, we check which columns are repeated or which criteria is repeated, eliminate those, and analyze
the final table.

The first action Send Mail can only occur if all three conditions are TRUE.

The second action Make Pending can only occur if Before 5:30 is FALSE, but we only have to record
this scenario once. We will remove the other similar columns.

Page 6 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Similarly, for the last condition, we will only show the scenarios in which either address is missing but
subject is present or vice versa. We do not need to show the scenario in which both the address and the
subject are missing.

After
eliminati
ng all the
insignific
ant cells,
you will
be left
with the
remainin
g table.

Page 7 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Page 8 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

Page 9 of 10
Computer Science 9608 (Notes)
Chapter: 4.2 Algorithm design methods

Topic: 4.2.1 Decision tables

a)

b) Looking at the table carefully and with the question in mind, you can see that the product will be
rejected in 2 cases,

If Group 1 test fails.

If Group 1 test is passed but Group 2 and Group 3 tests are failed.

Page 10 of 10