Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Agile Crash Course: Agile Project Management & Delivery - Master the most important concepts & tools of Agile

Your Company Name Here - Reach 30'000 visitors/month and 35'000 software development professionals for $145.

How to Use a Decision Table Methodology for the Analysis
of Complex Conditional Actions Requirements

D. Robert Baker

Background: Decisions

A decision is a choice about a "course of action". A course of action may include many individual actions. A decision may be characterized on a continuum from unstructured to structured (Simon 1960) [1].

Unstructured Decisions

Unstructured decisions are generally one-time propositions taken in emergent situations (Holsapple and Whinston 1996) [2], i.e. the set of conditions are unique and there are no fixed rules for the course of action to take based on the conditions. The possible courses of action need not be finite. Making an unstructured decision is therefore heuristic. Automating such decisions involves the use of Decision Support Systems, which attempt to obtain and organize as much relevant information as possible for presentation to the decision maker. The decision maker then applies whatever heuristics he considers appropriate to come up with a course of action.

Structured Decisions

Structured decisions are predictable, i.e. given a particular set of conditions, the course of action to be taken is clear and definable. The choice is which actions to take among a predefined, finite collection of actions. Making a structured decision is therefore algorithmic. There are three common methods of expressing these algorithms. Note that all three of these methods are capable of dealing with multivariate, not merely binary conditions.

Figure 1 - A typical natural language expression of a simple policy
for charging for in-flight services on charter flights

Structured English

Structured English is an attempt to allow the use of natural language, stripped of ambiguity, to express actions to be taken under particular conditions. This is accomplished by:

  • choosing a simple subset of natural language verbs and nouns, and
  • defining constructs to express
  • sequence
  • selection
  • and iteration

If this stripping of ambiguity is sufficiently rigorous, the resulting definition defines an executable programming language. This was the approach taken in the creation of the original procedural computer language compilers in the 50s and 60s. These definitions were (and remain) so complex that programmers required months and even years of training to acquire competence in the syntax and semantics of the definition. This made it almost impossible to combine knowledge of the business domain and technical proficiency in the programming language in one individual.

Less rigorous non-executable Structured English definitions are known as pseudocode and are used as analytical tools by analysts to create an intermediate specification. This specification is passed to programmers who translate it into actual compiler-compliant code. This extra step results in added expense both because of extra specialist personnel and because of the inevitable miscommunications and errors involved in an intermediate translation.

Attempts were made in the 70s and 80s to create "natural computer languages" (e.g. NATURAL, ENGLISH) with much looser syntactic and semantic restrictions. The hope was to eliminate the intermediate step by empowering the compiler to successfully interpret the "sloppy" natural language of the domain expert directly. These efforts met with limited success and are rarely seen today.

decision table

Figure 2 a typical executable structured English expression of the policy in Figure 1

Decision Trees

A decision tree is a graphic tool that represents conditions and their resulting actions. It consists of a directed acyclic graph (rooted tree) in which the non-terminal edges represent a set of conditions evaluated sequentially from the root. A node is a decision point where a condition is evaluated. The terminal edges (leaves) represent actions.

Decision trees are a useful tool for expressing complex decision variables in a format conducive to human visualization. Software that directly manipulates decision trees is available (Oblique Classifier 1, TreePlan), but tends to be limited to highly technical scientific specialties like astronomy or DNA sequence analysis and requires a high degree of technical sophistication to use.

decision table

Figure 3. a typical decision tree of the policy in Figure 1

Decision Tables

A decision table is a two-dimensional matrix with one row for each possible action and one row for each relevant condition and one column for each combination of condition states. A decision table can very concisely and rigorously show complex conditions and their resulting actions while remaining comprehensible to a human reader.

The first set of rows indicates the possible actions that may be taken. An "X" in an action row shows that the action will be taken under the condition states indicated in the column below.

In a bivariate decision table, conditions are binary, restricting condition evaluations to "yes" and "no". This results in a number of columns equal to 2 number of conditions. This can quickly result in a huge number of columns as the number of conditions rise. Fortunately, it is unusual that every combination of conditions results in a different action.

In Figure 4, the use of the "-", or "donít care" notation is illustrated. This means that the condition in that row does not affect the action to be taken. Looking at the first column, we see that no action will be taken no matter the state of the last two conditions as long as the first condition is false. Each "donít care" reduces the number of columns necessary and increases the comprehensibility of the table. In this example the 23 = 8 possible combinations are reduced to 4.

The most common tool for the creation of decision tables is spreadsheet software, such as Microsoft Excel. Although this is really quite sophisticated software, it is cheap, readily available, and has a large base of trained users. Because of the ubiquity and sophistication of this software, it is quite easy to create additional software that can read decision tables created in the spreadsheet, understand the semantics therein contained, and take action to implement the logic expressed in the table.

Such simple software finally allows the removal of the "3rd man" in the analysis-synthesis process, allowing an analyst or even a logic-savvy policy expert alone to directly create executable code to implement policy.

decision table

Figure 4 a typical bivariate decision table of the policy in Figure 1

Page 2   Back to the archive list

Methods & Tools
is supported by


Simpliv IT Courses

Vornexinc.com

Testmatick.com

Software Testing
Magazine


The Scrum Expert