Decision Tables: Every Combination, No Gaps

A decision table lays out every combination of conditions and the action each one produces, in a grid that makes gaps and contradictions impossible to hide. When business rules have several interacting factors, it is the tool that guarantees you have specified every case.

A decision table represents complex business logic as a grid: the conditions that affect a decision down one side, the possible actions, and a column for each combination of condition values recording the resulting action. Each column is a rule, a specific combination of inputs and the outcome it produces. The power of the format is completeness: it forces every combination of conditions to be considered, which surfaces the gaps and contradictions that prose rules quietly hide. When a rule says “approve the payment if the account is active and the amount is within limit and the customer is verified,” a decision table makes you account for every combination of those three conditions, including the ones the prose glosses over, and that is where the undefined behavior lives. This is a sharp functional analyst tool, complementing the state machine and the functional specification.

I reach for a decision table whenever business logic involves several conditions interacting, because prose simply cannot guarantee completeness the way a grid can. The templates for decision tables and the rest of an analyst’s deliverables are in Real-World BA Deliverables.

Why do prose rules hide gaps?

Prose rules hide gaps because language naturally describes the cases the author thought of and silently omits the ones they did not, and with multiple interacting conditions the number of cases quickly exceeds what anyone tracks in their head. The result is rules that feel complete but leave combinations undefined.

Consider three conditions affecting a decision: account active or not, amount within limit or not, customer verified or not. That is three binary conditions, which means eight combinations. A prose rule typically describes two or three of them, the happy case where everything is fine, the obvious rejection where the account is inactive, and perhaps one more, and leaves the other five implicit. What happens when the account is active and the amount is within limit but the customer is not verified? What about active, over limit, and verified? The prose did not say, and “did not say” in practice means “nobody decided,” which means the developer guesses and the behavior is undefined.

This is the fundamental weakness of prose for combinational logic: it scales badly. With each added condition the number of combinations doubles, and prose, written linearly, cannot keep up, so gaps are not just possible but nearly guaranteed. The decision table fixes this by being exhaustive by construction: it has a column for every combination, so there is nowhere for a case to hide. This is the same completeness problem the state transition table solves for lifecycles, and the same precision that makes a good functional requirement testable, applied to combinational rules.

How do you build a decision table?

Build a decision table by listing the conditions, enumerating every combination of their values, recording the action for each, then collapsing the columns where some conditions do not matter. The enumeration is what guarantees completeness; the collapsing is what keeps the result readable.

Start by identifying the conditions, the inputs that affect the decision, and list them as rows. Identify the actions, the possible outcomes. Then enumerate the combinations: for n binary conditions there are 2 to the power n, so three conditions give eight columns, four give sixteen. Create a column for each combination of condition values, and fill in the resulting action for each. Here is the shape for the three-condition payment example:

Conditions          R1   R2   R3   R4   R5   R6   R7   R8
Account active?     Y    Y    Y    Y    N    N    N    N
Amount within limit Y    Y    N    N    Y    Y    N    N
Customer verified?  Y    N    Y    N    Y    N    Y    N
Action: Approve     X
Action: Reject           X    X    X    X    X    X    X

Now every combination has a defined action, with no gaps. The next step is to collapse: where a condition does not affect the outcome, you can merge columns and mark that condition as “does not matter” for the merged rule. In the example, once the account is inactive the other conditions are irrelevant, the payment is rejected, so the four inactive columns collapse into one rule with the account condition N and the others marked as not applicable. Collapsing simplifies the table without losing completeness, turning eight columns into a handful of meaningful rules. The discipline of enumerating first and collapsing second is what gives you both completeness and clarity, and it often reveals that the real logic is simpler than the raw combinations suggested.

How do decision tables surface contradictions and gaps?

Decision tables surface gaps as combinations with no action and contradictions as combinations assigned conflicting actions, both of which are visible at a glance in the grid but invisible in prose. The table turns completeness and consistency into things you can simply look at and check.

A gap appears as a combination, a column, with no action filled in. Because the table has a column for every combination, an empty action cell is an undefined case staring at you, and you cannot miss it the way you can miss an unstated case in prose. Finding a gap is finding a real requirement question: what should happen in this combination. Often the answer is obvious once the question is forced, but it had to be forced, and the table forces it. A contradiction appears when the logic, as written, would assign two different actions to the same combination, which the table makes visible because each combination is one column with one outcome; trying to specify two reveals the conflict. Prose can contain contradictions across paragraphs that no one notices until production; the table cannot.

This is the analytical payoff of the format. Building the table is not just documentation; it is an analysis that interrogates the logic for completeness and consistency, the way drawing a sequence diagram interrogates a flow for missing error paths. The questions the table raises, the empty cells and the conflicts, are exactly the requirements work that needs doing, and doing it on the table before the build is far cheaper than discovering the same gaps in testing or production. This is why I treat the decision table as an elicitation tool, not just a notation: it generates the right questions automatically, which is the hallmark of a good functional analysis technique.

How do decision tables drive complete testing?

Decision tables drive complete testing because each rule column becomes a test case: the condition values are the input and the action is the expected result. Testing every column gives systematic coverage of the logic, every combination verified, rather than testing a few cases and hoping the rest behave.

The translation is direct and clean. Take the collapsed table, and for each rule, construct a test: set up the inputs to match the rule’s condition values, execute, and assert the action matches the rule’s outcome. Because the table covers every meaningful combination, testing every rule covers the entire logic, which is exactly the systematic coverage that ad hoc test selection misses. This is decision table testing, a recognized technique precisely because combinational logic is where untested combinations hide defects, and the table guarantees none are skipped. It pairs naturally with negative test design, since many of the rules are the failure cases, and with the broader discipline of deriving tests from a complete model rather than from intuition.

This requirement-to-test traceability is one of the cleanest you will find: rule column to test case, one to one. It makes coverage provable, you can show every rule has a test, which connects to the requirements traceability matrix and gives a QA analyst a defensible basis for claiming the logic is fully tested. And because the table is the shared artifact, the same grid that the functional analyst used to specify the logic completely is the one the tester uses to verify it completely, which keeps specification and testing in lockstep. That tight loop, complete specification driving complete testing from one artifact, is the whole appeal of decision tables, and the skills to exploit it are part of The Technical Skills Guide for BAs.

The takeaway

A decision table represents combinational business logic as a grid of conditions and the action for every combination, making completeness and consistency things you can see rather than hope for. It surfaces the gaps and contradictions that prose hides, because every combination is a column and an empty or conflicting cell is obvious. Build it by enumerating all combinations then collapsing the irrelevant ones, and turn each rule column directly into a test case for systematic coverage.

Use it whenever several conditions interact to determine an outcome, and the undefined cases that would have become production defects become questions you answer up front. Start with Real-World BA Deliverables for the templates and From Vague BR to Functional Requirements for the method, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Functional Analysis, Business Rules, Requirements, Software Testing, Business Analysis