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.
Which is More Promising: Data Science or Software Engineering? | Data Driven Investor
About a month back, while I was sitting at a café and working on developing a website for a client, I found this woman…
Decision tables and decision trees are two effective techniques for representing how a system should behave when complex logic and decisions come into play.
A decision table lists the various values for all the factors that influence some aspect of a system’s behavior and indicates the expected system actions in response to each combination of factors. These factors can be shown either as statements with possible answers of true or false, as questions with possible answers of yes or no, or as conditions that can have two or more possible values.
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:
- Whether the user who is creating the request is authorized to request the chemical.
- Whether the chemical is available either in the chemical stockroom or from a vendor.
- Whether the chemical is on the list of hazardous chemicals that require special training in safe handling.
- 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.
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.
A decision tree is a visual way to represent the same information that appears in a decision table. Figure 2 shows a decision tree that represents this same logic for the chemical tracking system. This example looks much like a flowchart. Some people use other drawing conventions, but I like to use different symbols for the conditions and the resulting system behaviors.
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
Besides the benefits of efficiently showing how multiple decisions lead to a set of functional requirements, a decision table or tree is a great aid to testers. You want to make sure to test all combinations of inputs and conditions and see that they stimulate the proper system behavior. These tools quickly show just what combinations the tester needs to consider for both success and failure paths. Using the decision table ensures that testers do not overlook any requirements coming out of this logic. It is also prevents them from performing unnecessary tests that wouldn’t yield useful information.
My Decision: Yes!
I’ve always been a big fan of using alternative techniques for representing requirements knowledge beyond natural language. Decision tables and decision trees are effective ways to document requirements or business rules to avoid overlooking any combinations of conditions. Even a complex decision table or tree is easier to read than a mass of repetitious textual requirements. Every business analyst should have these valuable techniques in her tool kit.
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.