It’s Only Logical: Decision Tables and Decision Trees

Karl Wiegers
Feb 1 · 5 min read

A software system often is governed by complex logic, with various combinations of conditions and actions leading to different system behaviors. For example, if the driver presses the accelerate button on a car’s cruise control system and the car is currently cruising, the system increases the car’s speed. If the car isn’t cruising, though, the system shouldn’t do anything.

Developers must base their work on a set of functional requirements that describe what the system should do under all possible combinations of both normal and error conditions. However, it’s easy to overlook a specific condition combination, which then results in a missing requirement. These knowledge gaps are hard to spot by reviewing a specification written in natural language, with all its bulkiness and ambiguities.

Decision tables and decision trees are two effective techniques for representing how a system should behave when complex logic and decisions come into play.

Decision Tables

As an illustration, let’s consider a chemical tracking system that I worked on once. This system managed the inventories of chemicals in a large company’s research labs. It allowed scientists to request new chemicals, tracked the location and status of individual chemical containers, provided health and safety information, and so forth.

Whether or not the chemical tracking system should accept a request for a new chemical from an individual depends on four factors:

  1. Whether the user who is creating the request is authorized to request the chemical.
  2. Whether the chemical is available either in the chemical stockroom or from a vendor.
  3. Whether the chemical is on the list of hazardous chemicals that require special training in safe handling.
  4. Whether the user who is creating the request has been trained in handling this type of hazardous chemical.

Some of these considerations are derived from business rules: user authorizations and the need for training in handling hazardous chemicals. Others are based on system data at the time the user attempts to place the request: whether the chemical is available and whether the user has received any necessary training.

You could imagine trying to write out all the logic combinations of these four factors in the form of functional requirements specified in natural language. It would quickly become bulky and convoluted. It would be easy to miss one of the combinations, to include combinations that are not logically sensible, or to write requirements in an ambiguous way that could lead to incorrect implementation.

Figure 1 shows an alternative way to depict these logic combinations in the form of a decision table. This table makes it explicitly clear whether the chemical tracking system should accept or reject each request for a new chemical.

Figure 1. Sample decision table for the chemical tracking system.

Each of these four factors has two possible conditions, true or false. In principle, this gives rise to 2 to the fourth power, or 16, possible true/false combinations, for a potential of 16 distinct functional requirements. In practice, though, many of the combinations lead to the same system response. For example, if the user is not authorized to request chemicals (the first condition is false) then the system won’t accept the request, so the other conditions are irrelevant. Those irrelevant condition combinations have dashes in the decision table’s corresponding cells.

The table shows that only five distinct functional requirements arise from the various combinations. It’s always nice when a problem turns out to be smaller than you thought it was. The decision table is a compact and efficient way to communicate the outcome of these various logic combinations unambiguously.

Decision Trees

Figure 2. Sample decision tree for the chemical tracking system.

The four diamonds illustrate the four factors with their possible true and false outcomes. Some outcomes lead to asking the next question; others lead to a conclusion about whether the system should accept or reject the chemical request. The five boxes indicate the five possible outcomes of either accepting or rejecting the chemical request.

A decision tree takes up more space than a decision table. You can imagine problems that have more — maybe a lot more — than four decisions, with perhaps more than just two outcomes from each decision. A decision tree for a problem like that could get large and complex. Tracing through the decision pathways in a decision tree does make the logic sequence clearer than does the more compact summary of conditions and outcomes shown in a decision table.

The Testing Benefit

My Decision: Yes!

====================

This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Data Driven Investor

from confusion to clarity not insanity

Karl Wiegers

Written by

I’ve written on software development and management, consulting, self-help, chemistry, military history, and a mystery novel. More info at karlwiegers.com.

Data Driven Investor

from confusion to clarity not insanity

More From Medium

More from Data Driven Investor

More from Data Driven Investor

More from Data Driven Investor

More from Data Driven Investor

PowerPoint: The Most Underrated Diagram Tool

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade