• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Software Requirements Model 2 – The Decision Tree

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.

5 Responses to Software Requirements Model 2 – The Decision Tree

  1. Philippine Outsourcing February 10, 2010 at 7:43 am #

    Thanks for posting this very interesting post.

  2. Anonymous February 22, 2010 at 2:45 pm #

    Are you going to be continuing these intersting articles? I really enjoyed reading them.

  3. Joy March 1, 2010 at 11:17 pm #

    Great idea – we'll make sure someone at Seilevel works on posting these! Thanks for the comment


  1. Happy New Year, it’s time to set your vision - Seilevel Blog - Software Requirements - May 16, 2016

    […] it (or ignore it and notice how that played out!). For example, I could think through a detailed decision tree for a conversation with a customer or co-worker, consider all the paths it could take and be ready […]

  2. Software Requirements Models that Work Well Together - May 16, 2016

    […] about decision tress or choosing the right […]

Leave a Reply

Your email address will not be published. Required fields are marked *