This is post number two in my continuing series of requirements model discussions. You can view my first post here. This time around, I’d like to discuss decision tree diagrams. These simple flowcharts can make your life much easier when writing a software requirements document.
A decision tree diagram really only has three parts – decision points (diamonds), end points (rectangles), and connections between these points (arrows).
These diagrams only really come in handy when you have a large group of nested ‘if’ statements in your requirements. If you ever find yourself writing something like this:
If option A is true, set option B to true. If
option A is false, see if option C is false. If option
C is false, check option D…
you might want to try showing it in a decision tree. Start by drawing a diamond for the first ‘if’ statement. Next, think about all of the possible outcomes of that statement. In the example above, option A can either be true or false.
If option A is true, you don’t have to make any more decisions. You should draw an end point (rectangle) to indicate that you’ve reached the end of the decision pathway. If option A is false, however, you have to go through another layer of decisions before you can reach a resolution. This is represented by another decision point (diamond) connected to the first.
The number of connections coming out of a decision point is dependent on the type of decision being made. For ‘true/false’ decisions or ‘yes/no’ decisions, you will always have two connections for each decision point. For more complex decisions, you may end up with more.
The key to creating a useful decision tree diagram is to identify all of the decision points in the system and the number of connections coming out of each point. If you know these two key pieces of information, you can be very confident that you’ll catch most of the requirements related to this decision tree.
How does knowing these things give you confidence that nothing was missed? If you put your diagram together with all of the decision points and connections for each, you can quickly see where the end points belong. Any connection that doesn’t end in a diamond has to end in a rectangle. Now all you have to do is go back through, fill in the rectangles, and figure out the requirements that each diamond and rectangle represent.
The value provided by these diagrams stems from their structure. Without this structure, it is very difficult to look at a bunch of nested if statements and know whether or not you have captured every possible decision pathway through the system. The diagram lets you see this at a glance.
You can also identify usability problems in the system by looking at a decision tree diagram. If you have to go through too many decision points before you arrive at a commonly-used end point, you can bet your users will be frustrated with the system.
We’ve all used automated phone systems where you have to choose 14 options before talking to a person and you risk getting your call dropped with every keypress. These systems are perfect candidates for improvement via decision tree analysis. We used this technique on a call center application to help improve the customer experience. First, we documented the ‘as-is’ system with a decision tree. This quickly surfaced many dead-ends and complex pathways that we were able to eliminate. By rearranging the decision and end points, the new system cut call times and measurably improved customer satisfaction. We were also able to ensure there were no end points that did not allow some way out.
Decision trees are quick to draw up and, when used on the right type of problem, can greatly simplify your software requirements gathering process.
