Decision Tables: BABOK 10.17 Example

Decision tables put rule logic in a grid: conditions in columns, one combination of values per row, the outcome in the last column. A full table lists every combination, so a rule with one 4-value condition and four yes/no conditions gives 4 × 2 × 2 × 2 × 2 = 64 rows. You then merge rows where a condition does not matter. In BABOK v3 this sits in technique 10.17, Decision Modelling.

Last verified: October 2026.

What a decision table is

A decision table is a grid of conditions, rules and outcomes. Every rule is one combination of condition values. It is the core of the Decision Modelling technique — BABOK v3 says it shows how repeatable business decisions are made [4]. The Decision Model and Notation (DMN) standard from the Object Management Group uses the same idea for business rules [3].

Testers know the same tool from the other side. The ISTQB Foundation syllabus says three things [1]:

a full table covers every combination of conditions;
a dash means the condition does not matter for the outcome;
such columns can be merged to make the table smaller.

The same syllabus adds that the table helps find gaps and contradictions in requirements [1].

Opinions on the technique differ. A business rules consultant argues that most decision tables are written for developers, and business people struggle to read them [7]. Other consultants say the opposite: tables are visual and need no formal language, so business readers handle them well [8]. A developer who has used them says they do not like them and see value only when end users change the rules themselves [12].

Personally, I think it is an excellent technique. It shows the cases that text hides, and for me this outweighs the cost of building the table.

Part	What it holds	Events example below
Condition	An input that can change the result	Who is looking, visibility, registration
Condition value	One allowed value of the input	Friend, Stranger; Yes, No
Rule (row)	One combination of values	Stranger + visible + seats left
Outcome	What the system does	Join, Register, Waitlist, Hidden
"–"	This condition does not matter for this rule	Visibility for the author

Why it matters for the CBAP exam

Decision tables are the main model inside technique 10.17, so they matter for the Certified Business Analysis Professional (CBAP) exam. A typical scenario: a stakeholder describes a decision that depends on several factors, and you pick the technique. Two traps:

Decision Modelling vs Decision Analysis. Decision Modelling (10.17) captures repeatable rule logic. Decision Analysis (10.16) compares options for a one-time choice. See decision modeling and decision analysis for the older overview.
Decision tables vs business rules. A decision table is a way to present and check rules. The rules themselves are analysed in Business Rules Analysis (BABOK 10.9); the difference between definitional and behavioural rules is in definitional vs behavioural business rules.

For the full list of techniques by knowledge area, see the BABOK techniques map. To practise scenario questions, try the CBAP simulator.

How I used decision tables on a real project

I used decision tables on a social network for Australian students. I wanted a very detailed set of requirements, and I ended up with many tables. Each one described its own layer of the system:

Entities. One table mapped the entities of the system to user stories and screens. It worked a bit like a glossary. Strictly speaking it is a matrix, not a decision table — it has no conditions and outcomes. But I built it the same way: everything against everything.
Logic inside user stories. Here decision tables did the real work. They showed me cases I would not have noticed otherwise.
Gherkin at the end. I closed each table with a Gherkin scenario (Given / When / Then). To some degree this covered the test cases for our tester.

The tables lived in Confluence. At that time it was the de facto standard for a team knowledge base; today there are other tools. The whole team used the tables, because they helped.

The method also works well with document analysis. Take a contract or a credit application. You can draw it as an activity diagram or a sequence diagram. Or you can put it in a table: steps or required documents on one axis, applicants with different credit histories on the other. Each cell says what the algorithm does in that case.

So a decision table is not a separate artefact for me. It is a way to multiply everything by everything and see all the cases at once.

Worked example: who can join an event (64 rows)

The example is made up for this article, but the shape is the same as on my project. An app lets users create events. By default only friends and friends of friends can see and join. The author can turn on three switches, and seats can run out.

Conditions:

Condition	Values
Viewer	Author, Friend, Friend of friend, Stranger
Visible to all in area	Yes, No
Anyone can join	Yes, No
Registration required	Yes, No
Seats left	Yes, No

Rules in plain text:

The author always sees the event and can manage it.
Friends and friends of friends always see the event and may join.
A stranger sees the event only if it is visible to everyone in the area.
A stranger may join only if the event is visible and "anyone can join" is on.
If joining is allowed: no seats left means "Waitlist"; registration on means "Register"; otherwise "Join".

Five short rules look complete. Now multiply: 4 × 2 × 2 × 2 × 2 = 64 combinations. The full table:

#	Viewer	Visible to all in area	Anyone can join	Registration	Seats left	Outcome
1	Author	Yes	Yes	Yes	Yes	Manage
2	Author	Yes	Yes	Yes	No	Manage
3	Author	Yes	Yes	No	Yes	Manage
4	Author	Yes	Yes	No	No	Manage
5	Author	Yes	No	Yes	Yes	Manage
6	Author	Yes	No	Yes	No	Manage
7	Author	Yes	No	No	Yes	Manage
8	Author	Yes	No	No	No	Manage
9	Author	No	Yes	Yes	Yes	Manage
10	Author	No	Yes	Yes	No	Manage
11	Author	No	Yes	No	Yes	Manage
12	Author	No	Yes	No	No	Manage
13	Author	No	No	Yes	Yes	Manage
14	Author	No	No	Yes	No	Manage
15	Author	No	No	No	Yes	Manage
16	Author	No	No	No	No	Manage
17	Friend	Yes	Yes	Yes	Yes	Register
18	Friend	Yes	Yes	Yes	No	Waitlist
19	Friend	Yes	Yes	No	Yes	Join
20	Friend	Yes	Yes	No	No	Waitlist
21	Friend	Yes	No	Yes	Yes	Register
22	Friend	Yes	No	Yes	No	Waitlist
23	Friend	Yes	No	No	Yes	Join
24	Friend	Yes	No	No	No	Waitlist
25	Friend	No	Yes	Yes	Yes	Register
26	Friend	No	Yes	Yes	No	Waitlist
27	Friend	No	Yes	No	Yes	Join
28	Friend	No	Yes	No	No	Waitlist
29	Friend	No	No	Yes	Yes	Register
30	Friend	No	No	Yes	No	Waitlist
31	Friend	No	No	No	Yes	Join
32	Friend	No	No	No	No	Waitlist
33	Friend of friend	Yes	Yes	Yes	Yes	Register
34	Friend of friend	Yes	Yes	Yes	No	Waitlist
35	Friend of friend	Yes	Yes	No	Yes	Join
36	Friend of friend	Yes	Yes	No	No	Waitlist
37	Friend of friend	Yes	No	Yes	Yes	Register
38	Friend of friend	Yes	No	Yes	No	Waitlist
39	Friend of friend	Yes	No	No	Yes	Join
40	Friend of friend	Yes	No	No	No	Waitlist
41	Friend of friend	No	Yes	Yes	Yes	Register
42	Friend of friend	No	Yes	Yes	No	Waitlist
43	Friend of friend	No	Yes	No	Yes	Join
44	Friend of friend	No	Yes	No	No	Waitlist
45	Friend of friend	No	No	Yes	Yes	Register
46	Friend of friend	No	No	Yes	No	Waitlist
47	Friend of friend	No	No	No	Yes	Join
48	Friend of friend	No	No	No	No	Waitlist
49	Stranger	Yes	Yes	Yes	Yes	Register
50	Stranger	Yes	Yes	Yes	No	Waitlist
51	Stranger	Yes	Yes	No	Yes	Join
52	Stranger	Yes	Yes	No	No	Waitlist
53	Stranger	Yes	No	Yes	Yes	View only
54	Stranger	Yes	No	Yes	No	View only
55	Stranger	Yes	No	No	Yes	View only
56	Stranger	Yes	No	No	No	View only
57	Stranger	No	Yes	Yes	Yes	Hidden
58	Stranger	No	Yes	Yes	No	Hidden
59	Stranger	No	Yes	No	Yes	Hidden
60	Stranger	No	Yes	No	No	Hidden
61	Stranger	No	No	Yes	Yes	Hidden
62	Stranger	No	No	Yes	No	Hidden
63	Stranger	No	No	No	Yes	Hidden
64	Stranger	No	No	No	No	Hidden

What the full table showed

Rows 57–60 are the interesting ones. A stranger, the event is not visible to all in the area, but "anyone can join" is on. The author said anyone may join. And at the same time a stranger cannot even see the event. Which switch wins?

The five rules in text do not say. In this example the product decision is "hidden wins". The decision itself is not important. What matters is that the table forced it before development, not after a bug report.

Hence the main point: an empty or unclear outcome cell is a requirements gap, not a test problem. The ISTQB syllabus says the same about gaps and contradictions [1]. A requirements consultant recommends tables and trees for complex logic for the same reason [13]. A software engineer describes a migration where the team used decision tables to cover every possible case, dropped an input that turned out to be irrelevant, and generated the test suite from the table [5].

How to collapse 64 rows into 9 rules

Full tables grow fast, and practitioners deal with it in different ways. A business analyst who mentors other BAs recommends splitting a big table into smaller ones [6]. A QA engineer splits the table or switches to pairwise testing at around five conditions [10]. I prefer to collapse.

You collapse a decision table by merging rows with the same outcome that differ only in conditions that do not matter. The merged condition gets a "–" [1]. I do it in three passes:

Find a condition that wins alone. For the author the outcome is always "Manage". All 16 author rows become one rule with four dashes.
Merge condition values that behave the same. Friend and friend of friend give the same outcome in every row, so they become one value: "Friend or friend of friend".
Drop conditions that do not matter inside a group. For friends, visibility and "anyone can join" never change the result. For a hidden event, strangers get "Hidden" whatever the other switches say.

The result:

Rule	Viewer	Visible to all in area	Anyone can join	Registration	Seats left	Outcome	Rows covered
R1	Author	–	–	–	–	Manage	16
R2	Friend or friend of friend	–	–	–	No	Waitlist	16
R3	Friend or friend of friend	–	–	Yes	Yes	Register	8
R4	Friend or friend of friend	–	–	No	Yes	Join	8
R5	Stranger	No	–	–	–	Hidden	8
R6	Stranger	Yes	No	–	–	View only	4
R7	Stranger	Yes	Yes	–	No	Waitlist	2
R8	Stranger	Yes	Yes	Yes	Yes	Register	1
R9	Stranger	Yes	Yes	No	Yes	Join	1

The rows covered add up to 64. Every original row matches exactly one rule — I checked it with a short script. A spreadsheet works too. Do this check before you throw the full table away. A QA engineer with 15+ years of test design gives the same advice: verify the full result before you merge [10].

Two rules for myself:

Collapse after you fill the full table, not instead of it. If you start from the short version, you never see rows 57–60.
Rules must not overlap. If one combination matches two rules with different outcomes, the table is contradictory. DMN handles this with "hit policies", but in a requirements document it is simpler to keep rules disjoint.

One more warning comes from decision modelling consultants. Organisations often create isolated tables that repeat the same logic, and then every change becomes error-prone [8]. A DMN consultant puts the target as "one business change, one rule change" [9].

From the table to Gherkin test cases

Each collapsed rule becomes one row in a Gherkin Scenario Outline. Cucumber runs the outline once for each row of Examples [2]. So the table and the tests stay in sync.

Scenario Outline: Event access for a viewer
  Given an event with visibility to all in area "<visible_to_area>"
  And "anyone can join" is "<anyone_can_join>"
  And registration required is "<registration_on>"
  And seats left is "<seats_left>"
  When a "<viewer_type>" opens the event
  Then the viewer sees the "<expected_outcome>" option

  Examples:
    | rule | viewer_type      | visible_to_area | anyone_can_join | registration_on | seats_left | expected_outcome |
    | R1   | Author           | No      | No     | Yes          | No    | Manage    |
    | R2   | Friend           | No      | No     | No           | No    | Waitlist  |
    | R3   | Friend of friend | No      | No     | Yes          | Yes   | Register  |
    | R4   | Friend           | Yes     | Yes    | No           | Yes   | Join      |
    | R5   | Stranger         | No      | Yes    | No           | Yes   | Hidden    |
    | R6   | Stranger         | Yes     | No     | No           | Yes   | View only |
    | R7   | Stranger         | Yes     | Yes    | Yes          | No    | Waitlist  |
    | R8   | Stranger         | Yes     | Yes    | Yes          | Yes   | Register  |
    | R9   | Stranger         | Yes     | Yes    | No           | Yes   | Join      |

A dash cannot run as a test, so each "–" gets one concrete value. I pick values that could expose a bug. R5 uses "anyone can join = Yes" on purpose: that is the conflict from rows 57–60.

Nine rows also keep the block readable. A BDD engineer recommends only a few rows and columns per examples table [11]. A 64-row block would break that advice.

The second example: an entity matrix

On my project the entity layer was a matrix like this one. Here it is on the same made-up Events example. Rows are entities, columns are screens. Each cell says what the screen does with the entity: C = create, R = read, U = update, D = delete.

Entity	Event feed	Event page	Create or edit event	My events	Profile
User	R	R	R	R	R, U
Friendship	R	R	–	–	C, R, D
Event	R	R	C, U, D	R	R
Visibility settings	–	R	C, U	–	–
Registration form	–	R	C, U	–	–
Attendance	R	C, R, D	–	R	R
Waitlist	–	C, R, D	R	R	–

A glossary says what an entity is. The matrix says where it lives:

which screen creates attendance;
where a friendship can be removed;
which screens change if the visibility settings change.

An entity with no "C" anywhere is the same signal as an empty outcome cell. For the definitions themselves, a data dictionary is the better home.

Common misconceptions

"A decision table is the same as a decision matrix." A weighted decision matrix compares options against criteria; that is Decision Analysis (10.16). A decision table maps conditions to outcomes; that is Decision Modelling (10.17).
"Collapsing loses information." It does not if each "–" truly does not change the outcome. Check every original row against the collapsed rules.
"The table replaces the text." It replaces the ambiguous part of the text. Keep one sentence per rule so stakeholders know why the rule exists.
"Decision tables are only for testers." Testers use them for test design [1], but for an analyst the main value comes earlier, when an empty cell turns into a question for the product owner.

Practice Questions

1. A loan offer depends on credit history (good, fair, poor) and two yes/no conditions: existing customer and collateral provided. How many rules does a full decision table have?

A. 5 B. 7 C. 12 D. 64

2. In a decision table, a rule shows "–" for "Registration required". What does it mean?

A. The value is unknown and must be elicited. B. The condition does not change the outcome for this rule. C. Registration is not required. D. The rule is out of scope.

3. A stakeholder explains that the delivery fee depends on order value, customer tier and region, and that the logic changes every quarter. Which BABOK technique best captures this logic?

A. Decision Analysis B. Decision Modelling C. Financial Analysis D. Process Modelling

Answers. 1 — C: 3 × 2 × 2 = 12. 2 — B: the dash means the condition is irrelevant for that rule [1]. 3 — B: the decision is repeatable and rule-based, which is Decision Modelling (10.17); Decision Analysis is for comparing options in a one-time choice.

Conclusion: the gap between BABOK and real decision tables

BABOK presents decision tables as a model of repeatable decisions; in practice analysts also use them to find gaps, generate tests and keep the team on one page.

Area	Standard	Reality	Delta
Purpose	Show how repeatable decisions are made [4]	Also used to prove coverage and find missing cases [5, 13]	Added by practitioners
Size	Full table covers every combination [1]	Split or collapsed at around 5–7 conditions [6, 10]	Reduced to collapsed tables
Notation	DMN decision tables [3]	Spreadsheets and wiki tables are common; isolated tables cause rework [8]	Under-used
Testing link	Tables support test design [1]	Rows become Gherkin or parametrized tests [5, 10]	No gap
Audience	Business decision logic	Often written for developers [7]	Reduced to a technical artefact

So: build the full table to think, collapse it to communicate, end it with scenarios. Then the tester and the developer work from the same rows.

Behaviour-driven development — where Gherkin scenarios come from.

FAQ

What is a decision table in business analysis?

A decision table is a grid that maps every combination of conditions to an outcome. Each row is one rule. In BABOK v3 decision tables belong to technique 10.17, Decision Modelling, which shows how repeatable business decisions are made.

How many rows does a full decision table have?

Multiply the number of values of each condition. Four yes/no conditions give 16 rows; one 4-value condition plus four yes/no conditions gives 64. The number grows exponentially, so analysts collapse the table after checking it.

What does a dash mean in a decision table?

A dash means the condition does not change the outcome for that rule. Merging rows with dashes is how a 64-row table becomes 9 rules without losing any case.

How do you turn a decision table into test cases?

Use one test per collapsed rule. In Gherkin, write a Scenario Outline and put each rule in the Examples table; replace each dash with a concrete value that could expose a bug.

What is the difference between Decision Modelling and Decision Analysis?

Decision Modelling (BABOK 10.17) captures repeatable rule logic, such as who can join an event. Decision Analysis (BABOK 10.16) compares options for a one-time choice, such as which vendor to select.

Sources

Last verified: October 2026.

What a decision table is

Testers know the same tool from the other side. The ISTQB Foundation syllabus says three things [1]:

a full table covers every combination of conditions;
a dash means the condition does not matter for the outcome;
such columns can be merged to make the table smaller.

The same syllabus adds that the table helps find gaps and contradictions in requirements [1].

Personally, I think it is an excellent technique. It shows the cases that text hides, and for me this outweighs the cost of building the table.

Part	What it holds	Events example below
Condition	An input that can change the result	Who is looking, visibility, registration
Condition value	One allowed value of the input	Friend, Stranger; Yes, No
Rule (row)	One combination of values	Stranger + visible + seats left
Outcome	What the system does	Join, Register, Waitlist, Hidden
"–"	This condition does not matter for this rule	Visibility for the author

Why it matters for the CBAP exam

Decision Modelling vs Decision Analysis. Decision Modelling (10.17) captures repeatable rule logic. Decision Analysis (10.16) compares options for a one-time choice. See decision modeling and decision analysis for the older overview.
Decision tables vs business rules. A decision table is a way to present and check rules. The rules themselves are analysed in Business Rules Analysis (BABOK 10.9); the difference between definitional and behavioural rules is in definitional vs behavioural business rules.

For the full list of techniques by knowledge area, see the BABOK techniques map. To practise scenario questions, try the CBAP simulator.

How I used decision tables on a real project

I used decision tables on a social network for Australian students. I wanted a very detailed set of requirements, and I ended up with many tables. Each one described its own layer of the system:

Entities. One table mapped the entities of the system to user stories and screens. It worked a bit like a glossary. Strictly speaking it is a matrix, not a decision table — it has no conditions and outcomes. But I built it the same way: everything against everything.
Logic inside user stories. Here decision tables did the real work. They showed me cases I would not have noticed otherwise.
Gherkin at the end. I closed each table with a Gherkin scenario (Given / When / Then). To some degree this covered the test cases for our tester.

The tables lived in Confluence. At that time it was the de facto standard for a team knowledge base; today there are other tools. The whole team used the tables, because they helped.

So a decision table is not a separate artefact for me. It is a way to multiply everything by everything and see all the cases at once.

Worked example: who can join an event (64 rows)

Conditions:

Condition	Values
Viewer	Author, Friend, Friend of friend, Stranger
Visible to all in area	Yes, No
Anyone can join	Yes, No
Registration required	Yes, No
Seats left	Yes, No

Rules in plain text:

The author always sees the event and can manage it.
Friends and friends of friends always see the event and may join.
A stranger sees the event only if it is visible to everyone in the area.
A stranger may join only if the event is visible and "anyone can join" is on.
If joining is allowed: no seats left means "Waitlist"; registration on means "Register"; otherwise "Join".

Five short rules look complete. Now multiply: 4 × 2 × 2 × 2 × 2 = 64 combinations. The full table:

#	Viewer	Visible to all in area	Anyone can join	Registration	Seats left	Outcome
1	Author	Yes	Yes	Yes	Yes	Manage
2	Author	Yes	Yes	Yes	No	Manage
3	Author	Yes	Yes	No	Yes	Manage
4	Author	Yes	Yes	No	No	Manage
5	Author	Yes	No	Yes	Yes	Manage
6	Author	Yes	No	Yes	No	Manage
7	Author	Yes	No	No	Yes	Manage
8	Author	Yes	No	No	No	Manage
9	Author	No	Yes	Yes	Yes	Manage
10	Author	No	Yes	Yes	No	Manage
11	Author	No	Yes	No	Yes	Manage
12	Author	No	Yes	No	No	Manage
13	Author	No	No	Yes	Yes	Manage
14	Author	No	No	Yes	No	Manage
15	Author	No	No	No	Yes	Manage
16	Author	No	No	No	No	Manage
17	Friend	Yes	Yes	Yes	Yes	Register
18	Friend	Yes	Yes	Yes	No	Waitlist
19	Friend	Yes	Yes	No	Yes	Join
20	Friend	Yes	Yes	No	No	Waitlist
21	Friend	Yes	No	Yes	Yes	Register
22	Friend	Yes	No	Yes	No	Waitlist
23	Friend	Yes	No	No	Yes	Join
24	Friend	Yes	No	No	No	Waitlist
25	Friend	No	Yes	Yes	Yes	Register
26	Friend	No	Yes	Yes	No	Waitlist
27	Friend	No	Yes	No	Yes	Join
28	Friend	No	Yes	No	No	Waitlist
29	Friend	No	No	Yes	Yes	Register
30	Friend	No	No	Yes	No	Waitlist
31	Friend	No	No	No	Yes	Join
32	Friend	No	No	No	No	Waitlist
33	Friend of friend	Yes	Yes	Yes	Yes	Register
34	Friend of friend	Yes	Yes	Yes	No	Waitlist
35	Friend of friend	Yes	Yes	No	Yes	Join
36	Friend of friend	Yes	Yes	No	No	Waitlist
37	Friend of friend	Yes	No	Yes	Yes	Register
38	Friend of friend	Yes	No	Yes	No	Waitlist
39	Friend of friend	Yes	No	No	Yes	Join
40	Friend of friend	Yes	No	No	No	Waitlist
41	Friend of friend	No	Yes	Yes	Yes	Register
42	Friend of friend	No	Yes	Yes	No	Waitlist
43	Friend of friend	No	Yes	No	Yes	Join
44	Friend of friend	No	Yes	No	No	Waitlist
45	Friend of friend	No	No	Yes	Yes	Register
46	Friend of friend	No	No	Yes	No	Waitlist
47	Friend of friend	No	No	No	Yes	Join
48	Friend of friend	No	No	No	No	Waitlist
49	Stranger	Yes	Yes	Yes	Yes	Register
50	Stranger	Yes	Yes	Yes	No	Waitlist
51	Stranger	Yes	Yes	No	Yes	Join
52	Stranger	Yes	Yes	No	No	Waitlist
53	Stranger	Yes	No	Yes	Yes	View only
54	Stranger	Yes	No	Yes	No	View only
55	Stranger	Yes	No	No	Yes	View only
56	Stranger	Yes	No	No	No	View only
57	Stranger	No	Yes	Yes	Yes	Hidden
58	Stranger	No	Yes	Yes	No	Hidden
59	Stranger	No	Yes	No	Yes	Hidden
60	Stranger	No	Yes	No	No	Hidden
61	Stranger	No	No	Yes	Yes	Hidden
62	Stranger	No	No	Yes	No	Hidden
63	Stranger	No	No	No	Yes	Hidden
64	Stranger	No	No	No	No	Hidden

What the full table showed

How to collapse 64 rows into 9 rules

You collapse a decision table by merging rows with the same outcome that differ only in conditions that do not matter. The merged condition gets a "–" [1]. I do it in three passes:

Find a condition that wins alone. For the author the outcome is always "Manage". All 16 author rows become one rule with four dashes.
Merge condition values that behave the same. Friend and friend of friend give the same outcome in every row, so they become one value: "Friend or friend of friend".
Drop conditions that do not matter inside a group. For friends, visibility and "anyone can join" never change the result. For a hidden event, strangers get "Hidden" whatever the other switches say.

The result:

Rule	Viewer	Visible to all in area	Anyone can join	Registration	Seats left	Outcome	Rows covered
R1	Author	–	–	–	–	Manage	16
R2	Friend or friend of friend	–	–	–	No	Waitlist	16
R3	Friend or friend of friend	–	–	Yes	Yes	Register	8
R4	Friend or friend of friend	–	–	No	Yes	Join	8
R5	Stranger	No	–	–	–	Hidden	8
R6	Stranger	Yes	No	–	–	View only	4
R7	Stranger	Yes	Yes	–	No	Waitlist	2
R8	Stranger	Yes	Yes	Yes	Yes	Register	1
R9	Stranger	Yes	Yes	No	Yes	Join	1

Two rules for myself:

Collapse after you fill the full table, not instead of it. If you start from the short version, you never see rows 57–60.
Rules must not overlap. If one combination matches two rules with different outcomes, the table is contradictory. DMN handles this with "hit policies", but in a requirements document it is simpler to keep rules disjoint.

From the table to Gherkin test cases

Each collapsed rule becomes one row in a Gherkin Scenario Outline. Cucumber runs the outline once for each row of Examples [2]. So the table and the tests stay in sync.

Scenario Outline: Event access for a viewer
  Given an event with visibility to all in area "<visible_to_area>"
  And "anyone can join" is "<anyone_can_join>"
  And registration required is "<registration_on>"
  And seats left is "<seats_left>"
  When a "<viewer_type>" opens the event
  Then the viewer sees the "<expected_outcome>" option

  Examples:
    | rule | viewer_type      | visible_to_area | anyone_can_join | registration_on | seats_left | expected_outcome |
    | R1   | Author           | No      | No     | Yes          | No    | Manage    |
    | R2   | Friend           | No      | No     | No           | No    | Waitlist  |
    | R3   | Friend of friend | No      | No     | Yes          | Yes   | Register  |
    | R4   | Friend           | Yes     | Yes    | No           | Yes   | Join      |
    | R5   | Stranger         | No      | Yes    | No           | Yes   | Hidden    |
    | R6   | Stranger         | Yes     | No     | No           | Yes   | View only |
    | R7   | Stranger         | Yes     | Yes    | Yes          | No    | Waitlist  |
    | R8   | Stranger         | Yes     | Yes    | Yes          | Yes   | Register  |
    | R9   | Stranger         | Yes     | Yes    | No           | Yes   | Join      |

A dash cannot run as a test, so each "–" gets one concrete value. I pick values that could expose a bug. R5 uses "anyone can join = Yes" on purpose: that is the conflict from rows 57–60.

Nine rows also keep the block readable. A BDD engineer recommends only a few rows and columns per examples table [11]. A 64-row block would break that advice.

The second example: an entity matrix

Entity	Event feed	Event page	Create or edit event	My events	Profile
User	R	R	R	R	R, U
Friendship	R	R	–	–	C, R, D
Event	R	R	C, U, D	R	R
Visibility settings	–	R	C, U	–	–
Registration form	–	R	C, U	–	–
Attendance	R	C, R, D	–	R	R
Waitlist	–	C, R, D	R	R	–

A glossary says what an entity is. The matrix says where it lives:

which screen creates attendance;
where a friendship can be removed;
which screens change if the visibility settings change.

An entity with no "C" anywhere is the same signal as an empty outcome cell. For the definitions themselves, a data dictionary is the better home.

Common misconceptions

"A decision table is the same as a decision matrix." A weighted decision matrix compares options against criteria; that is Decision Analysis (10.16). A decision table maps conditions to outcomes; that is Decision Modelling (10.17).
"Collapsing loses information." It does not if each "–" truly does not change the outcome. Check every original row against the collapsed rules.
"The table replaces the text." It replaces the ambiguous part of the text. Keep one sentence per rule so stakeholders know why the rule exists.
"Decision tables are only for testers." Testers use them for test design [1], but for an analyst the main value comes earlier, when an empty cell turns into a question for the product owner.

Practice Questions

1. A loan offer depends on credit history (good, fair, poor) and two yes/no conditions: existing customer and collateral provided. How many rules does a full decision table have?

A. 5 B. 7 C. 12 D. 64

2. In a decision table, a rule shows "–" for "Registration required". What does it mean?

A. The value is unknown and must be elicited. B. The condition does not change the outcome for this rule. C. Registration is not required. D. The rule is out of scope.

3. A stakeholder explains that the delivery fee depends on order value, customer tier and region, and that the logic changes every quarter. Which BABOK technique best captures this logic?

A. Decision Analysis B. Decision Modelling C. Financial Analysis D. Process Modelling

Conclusion: the gap between BABOK and real decision tables

BABOK presents decision tables as a model of repeatable decisions; in practice analysts also use them to find gaps, generate tests and keep the team on one page.

Area	Standard	Reality	Delta
Purpose	Show how repeatable decisions are made [4]	Also used to prove coverage and find missing cases [5, 13]	Added by practitioners
Size	Full table covers every combination [1]	Split or collapsed at around 5–7 conditions [6, 10]	Reduced to collapsed tables
Notation	DMN decision tables [3]	Spreadsheets and wiki tables are common; isolated tables cause rework [8]	Under-used
Testing link	Tables support test design [1]	Rows become Gherkin or parametrized tests [5, 10]	No gap
Audience	Business decision logic	Often written for developers [7]	Reduced to a technical artefact

So: build the full table to think, collapse it to communicate, end it with scenarios. Then the tester and the developer work from the same rows.

Behaviour-driven development — where Gherkin scenarios come from.

FAQ

What is a decision table in business analysis?

How many rows does a full decision table have?

What does a dash mean in a decision table?

A dash means the condition does not change the outcome for that rule. Merging rows with dashes is how a 64-row table becomes 9 rules without losing any case.

How do you turn a decision table into test cases?

Use one test per collapsed rule. In Gherkin, write a Scenario Outline and put each rule in the Examples table; replace each dash with a concrete value that could expose a bug.

What is the difference between Decision Modelling and Decision Analysis?

Decision Modelling (BABOK 10.17) captures repeatable rule logic, such as who can join an event. Decision Analysis (BABOK 10.16) compares options for a one-time choice, such as which vendor to select.

Decision Tables for Business Analysts: BABOK 10.17 Worked Example

What a decision table is

Why it matters for the CBAP exam

How I used decision tables on a real project

Worked example: who can join an event (64 rows)

What the full table showed

How to collapse 64 rows into 9 rules

From the table to Gherkin test cases

The second example: an entity matrix

Common misconceptions

Practice Questions

Conclusion: the gap between BABOK and real decision tables

Related topics

FAQ

What is a decision table in business analysis?

How many rows does a full decision table have?

What does a dash mean in a decision table?

How do you turn a decision table into test cases?

What is the difference between Decision Modelling and Decision Analysis?

Sources

Keep reading

Business Model Canvas BABOK Technique 10.8: A CBAP Deep Dive

Data Modelling in BABOK 10.15: Conceptual, Logical, Physical, ERD

Data Mining in BABOK: Descriptive, Diagnostic, Predictive Uses

Decision Tables for Business Analysts: BABOK 10.17 Worked Example

What a decision table is

Why it matters for the CBAP exam

How I used decision tables on a real project

Worked example: who can join an event (64 rows)

What the full table showed

How to collapse 64 rows into 9 rules

From the table to Gherkin test cases

The second example: an entity matrix

Common misconceptions

Practice Questions

Conclusion: the gap between BABOK and real decision tables

Related topics

FAQ

What is a decision table in business analysis?

How many rows does a full decision table have?

What does a dash mean in a decision table?

How do you turn a decision table into test cases?

What is the difference between Decision Modelling and Decision Analysis?

Sources

Keep reading

Business Model Canvas BABOK Technique 10.8: A CBAP Deep Dive

Data Modelling in BABOK 10.15: Conceptual, Logical, Physical, ERD

Data Mining in BABOK: Descriptive, Diagnostic, Predictive Uses