Decision table

from Wikipedia, the free encyclopedia

Decision tables are one of many ways of presenting complex sets of rules in a clear manner. A rule here is to be understood as a provision stating which actions are to be carried out when a given combination of conditions is present. A set of rules is a collection of different rules.


Decision tables are used to show complex dependencies between several conditions and the actions to be performed in a clear, complete and consistent manner. Application examples are the design of computer programs , programmable logic controllers (PLC), test data constellations and many others. In addition, the set of rules is often represented graphically or in matrices using a clearer decision tree. However, the table (s) are more systematic and can therefore be checked more easily than the tree for consistency and completeness. The amount of work involved in the formulation, the coordination with those involved and the control must not be underestimated. In return, there is an enormous relief in the project handling, the change service and the cost calculation.

Decision tables are also used in a business rule management system (BRMS) to enable both the definition and automatic execution of business rules . The decision tables are managed there in a business rule repository .


A decision table consists of four parts:

  • A list of the conditions to be considered
  • A list of the possible actions
  • An area in which the possible combinations of conditions are compiled
  • An area in which the activities to be carried out are assigned to each combination of conditions.
Table name R1 R2 R3 R4 R5 R6 R7 R8
1 deliverable? j j j j n n n n
2 information complete? j j n n j j n n
3 OK? j n j n j n j n
A Delivery with invoice x
B Delivery as cash on delivery x
C Complete information x x
D Notify: not available x x x x

The columns R1 to R8 identify the respective rules. Using the example of rule 7, it is explained how the rules are to be read: If condition 3 is met, but conditions 1 and 2 are not, then action D must be carried out.


Four criteria for assessing decision tables are presented below.


A decision table is complete when all possible combinations of conditions have been recorded. If there are n conditions, these are combinations. You can see that the number of possible combinations grows exponentially with the number of conditions - with ten conditions there are already 1024 combinations. In most cases, however, this does not result in the same number of rules, since rules are often redundant. If, despite all care or due to changed circumstances, a decision table does not (any longer) cover all cases, you end up with no result and no action from the last condition column. Therefore it makes sense, especially for computer programs, to introduce an additional column (e.g. "RF") with all conditions n after the last condition column . If the program runs in this column, a message can be output as an action, e.g. B. "Error - decision table incomplete".


A decision table can be consolidated if several rules can be combined into one. For example, the rules R5, R6, R7 and R8 can be summarized in the basic pattern shown above: Since the actions to be carried out only depend on condition 1 and conditions 2 and 3 are irrelevant, they can be represented by a single rule:

Table name R5 (new)
Condition 1 n
Condition 2 -
Condition 3 -
Action 1
Action 2
Action 3
Action 4 x

The horizontal lines are called "irrelevance indicators" or "don't care signs". They indicate that conditions 2 and 3 are irrelevant for determining the action to be taken, provided that condition 1 is met.

In general, there are two rules for the consolidation: 1. If two rules lead to the same action or sequence of actions AND if these 2. only differ in one condition display, then these two rules can be consolidated. In the consolidated rule, the irrelevance pointer is used instead of the different condition indicators.


A decision table is redundant if several rules contain identical cases. A case is a combination of conditions (e.g. here: "y, n, n") that has no “don't care” (irrelevance indicator). In the following table, rule R4 ("j, j, n" and "j, n, n") also includes the case of rule R3. Both rules lead to the same actions, so there is redundancy, otherwise there is a contradiction. Rule R3 can therefore be omitted without any loss of information occurring.

Table name R3 R4
Condition 1 j j
Condition 2 n -
Condition 3 n n
Action 1
Action 2
Action 3 x x
Action 4 x x
Action 5

Freedom from contradictions (consistency)

As soon as a decision table contains irrelevance pointers, there is a possibility that the table will become inconsistent. Here, too, an example:

Table name R3 R4
Condition 1 j j
Condition 2 n n
Condition 3 - n
Action 1
Action 2
Action 3 x x
Action 4 x
Action 5

Rule R3 states that actions 3 and 4 should be carried out as soon as condition 1 is met and condition 2 is not met. Rule R4, on the other hand, states that only action 3 should be carried out if condition 3 is also not met. Both rules contradict each other, so the decision table is inconsistent.

Decision tables for test data determination

After decision tables have been created and validated, they can be used to generate test data. The following are strategies for how test data can be generated and how a test suite can be sensibly restricted.

  • All-Explicit Variants
  • All-Variants, All-True, All-False, All-Primes
  • Each-Condition / All-Conditions
  • Binary Decision Diagram (BDD) Determinants
  • Variable negation (* will not be discussed)
  • Nonbinary Variable Domain Analysis

With all procedures there is always the problem between the scope of the test and the costs for the respective test. The difficulty with decision tables is that their creation is very time-consuming. Software contains many conditions and the specifications are usually incomplete, so that deriving a decision table is too time-consuming. Once you have created a decision table, the test strategies mentioned can be applied automatically.

Extensive or complicated processes can be recorded more easily in decision tables by creating several related decision tables. For this purpose, actions that can be broken down into further sub-actions are shown as separate decision tables. The branch from the first decision table then takes place there z. B. by the action "continue in ET 2". It is helpful to design the first decision table in such a way that it primarily represents the direct, fastest or most frequently used sequence, and the branches the less frequently used. This results in a kind of hierarchy of decision tables. This makes the entire system of processes clear.

See also


  • W. Vieweg: The construction of decision tables . Gabler, 1973, ISBN 3-409-32872-6
  • R. Irrgang: Decision table technique , create and analyze decision tables . Kt. Expertverlag, 1995, ISBN 3-8169-1106-4 , 185 pages, diskette (, 19).
  • R. Binder: Testing Object Oriented Systems, Models, Patterns and Tools . Addison-Wesley, 1999.
  • G. Jüttner: Decision tables and knowledge-based systems . Oldenbourg, ISBN 3-486-21454-3 , 1989.
  • H.Strunz: Decision table technique . Hanser, 1977, ISBN 3-446-12382-2 .
  • B. Moritz: Diagram Techniques for the EDP Practitioner . Self-published, Klausdorf / Schwentine 1977.
  • DIN 66241