Business Use

Information technology (IT) groups need requirements.  When conditional logic comes into the picture, the requirements are usually wanted as flow charts, process flows or UML activity diagrams.  Requirements are supposed to answer "what" not "how".  However, flow charts, process flows and UML activity diagrams are "how" to do things.

Business users like to use spreadsheet programs to do everything from analysis to reporting. Why not use a spreadsheet to create "tables" (decision tables) to specify "what" is required? But decision tables need to be converted into the "how" IT needs.

The DTC creates procedure (the how) from a table-like description of decisions and conditions (the what). This is a tedious and thankless job. (Ask any analyst!)

Consider a simple example.  Imagine a traffic signal with the standard colors red, yellow and green having the usual meaning, red indicates stop and green go.  Yellow indicates a change to red will occur soon.  Given the only decision is to stop or go, yellow creates opportunity for panic.  To resolve the ambiguity a simple rule is added.  During the day, go on yellow and stop otherwise:

Converting this into a flow chart or text description (by visual inspection of the table) yields something like:

if Signal is Green then
  Go
if Signal is Yellow and Day is yes then
  Go
if Signal is Yellow and Day is no then
  Stop
if Signal is Red then
  Stop

Even though this implementation is easy to create, it requires, in the worse case, six decision points!  Perhaps using the "else" notion may cut the number in half:

if Signal is Green or (Signal is Yellow and Day is yes) then
  Go
else
  Stop



 

This case is much better, requiring in the worse case, only three tests.  Not so obvious is a version where the worse case is only two:

if Signal is Yellow then

  if Day is Yes then
    Go
  else
    Stop
else
  if Signal is Red then
    Stop
  else
    Go

The last implementation is not as understandable (humanly) as the second, but this simple example demonstrates a need for a better way to convert conditional decisions into procedure.  The DTC provides a better way.

The easiest way to construct a decision table is with a "spreadsheet" program.  Given all these tools can output a TAB delimited version of the sheet allows freedom of choice among the "spreadsheet" programs.

View this example as a spreadsheet.

The text in column A cells, except the first row, are the possible values for the sheet up to an optional @MAP text. The first row indicates if the sheet makes a decision (@OUT in the Action sheet) or depends on external input (@IN in the Signal and Day sheets).

The @MAP rows declare the sheet names where the text for the columns come from. The cells below that column are validated by the DTC against the text in the named sheet. Most spreadsheet programs can be configured to make the values in the columns a drop down (validated) against the values in the referred sheet, even though Google spreadsheet is unable at this time.

The rows below the first @MAP row can be interpreted as: "Go if Signal is Green OR Stop if Signal is Red". The rows below the second @MAP row can be interpreted as: "Go if Signal is Yellow AND Day is Yes OR Stop if Signal is Yellow AND Day is No". The technical term for this type of arrangement is disjunctive normal form.