Many people are familiar with the famous sketch Who’s on First?—a full 6 minutes of comedic genius of misunderstanding, confusion, and failure to communicate. While the exact premise may be absurd, the reason it leaves us in stiches is the experience is all too familiar. And although it’s delightful to watch this conversation unfold between others, it’s infuriating to experience it yourself—to genuinely try to get clear, concise answers to our questions, only to spin around in circles until you want to throw your figurative bat down in exasperation.
Sadly, sometimes requirements gathering can feel just as absurd, especially when complex logic is involved. The more questions we ask the more we end up with, and after hours of conversations with stakeholders, our business rules seem as clear as mud and as traceable as a cat’s favorite tangled ball of yarn. That’s where Decision Tables can save us.
If you want to experience first-hand the power of a table in communicating information, try this exercise: watch the full Who’s on First? sketch, then try to explain to someone else who all the players in the sketch are. Did you run into any trouble? Any confusion? Now try showing someone else the table below.
How much faster did that conversation go? I’d wager it was much faster, clearer, and less painful than the first one. This is the power of Decision Tables. They can look intimating at first, but they are an incredibly powerful and compact way to organize and convey information. Every table has 3 basic components:
- Conditions
- Choices
- Outcomes
Decision Table Structure
Conditions are criteria that will drive a decision. For example, imagine a company that sells home insurance is designing a system that will help determine which policies customers are eligible for. Some conditions that they might care about are the customer’s credit score, how long they’ve been a homeowner, and whether they have any other existing policies with the company. Whatever criteria the company uses to drive the decisions should be captured in the Conditions.
Next are the choices. These should be all the options available for the conditions, written in as simple a way as possible. These choices can be binary, such as Yes/No for “Does the customer have any existing policies with the company?”. Others can be a range, such as “How many years have they been a homeowner?” <1 yr, 1-5yrs, >5yrs.
Finally, there are the outcomes. These are the decisions that are implemented based on the criteria and choices above. With our insurance company example, the outcomes might be “Offer Policy A,” “Offer Policy B,” or “Decline coverage”.
Decision Table Format
Conditions, Choices, and Outcomes get combined into a table in the format below:
The easiest way to read this is in columns; each business rule can be described by the choices listed in each of the rows, and for those criteria, the outcome(s) that applies to those criteria are marked with X.
Let's Build One
Let’s look at an example. Sticking with the insurance company scenario, assume the business has landed on the below criteria:
- Policy A is available to existing customers who have been homeowners for more than a year, or new customers who have been homeowners for more than 5 years.
- Policy B is available to any existing customers, as well as new customers who have been homeowners for more than a year.
- Policy C is available to existing customers who have been homeowners for more than 5 years or less than 1 year, and new customers who have been homeowners for 5 years or less.
- All customers must pass a credit check.
Now based on the criteria above, try to figure out which policies would be available to a new customer with great credit who wants to insure their first home that they bought 18 months ago. Times up—did you get it? If you did, you probably spent at least a minute re-reading the criteria and comparing the customer description against each of the bullets to figure it out.
Now try the same question again, but find the answer in the table below:
Hopefully you were able to find the right answer in a matter of seconds. For a new customer who has passed the credit check and owned a home for 1.5 years, we can quickly see that Rule 6 applies, so that customer is eligible for Policies B and C.
Decision Table Benefits
In addition to being a much more effective communication tool, there are several other benefits of Decision Tables:
Defines requirements – First and foremost, a Decision Table is a very powerful tool in elicitation sessions. Even having a basic draft of a table during an elicitation session can save significant time. When rules are laid out in such a clear, consumable way, it’s easier to see which scenarios have been covered and which are still outstanding. It also helps identify criteria that don’t actually drive decisions and simplifies the scenarios that matter.
Drives completeness – Another benefit of a Decision Table is it helps identify any missing scenarios that have not yet been considered. Once the conditions and choices have been identified, it’s just some quick math to determine how many permutations of those choices exist. It’s a quick way to ensure all possible scenarios are covered and planned for.
Catches contradictions – I guarantee that when Abbott and Costello first wrote their Who’s on First sketch, at some point they mixed up which players were on which bases—it’s almost impossible not to, especially if you’re trying to keep all that complex info in your head. But seeing rules laid out in a table will quickly help you catch any rules that don’t make sense or conflict with others.
Easier testing – Last but not least, Decision Tables will quickly become the favorite tool of any software tester, because it basically lays out every scenario and use case that needs testing. It’s a pre-made, comprehensive, and easy-to-follow checklist to ensure the use cases are working the way they should.
To learn more about Decision Tables, check out our Visual Models for Software Requirements book on our website. And next time you feel yourself spinning your wheels trying to define complex decision outcomes, try a Decision Table, so you can leave the absurd miscommunications to the comedians.
