Decision tables

By -

Decision tables

58.1 Purpose

A decision table is a two-dimensional table that shows the action to be taken following a series of related decisions.

58.2 Strengths, weaknesses, and limitations

When an algorithm involves more than two or three nested decisions, a decision table gives a clear and concise picture of the logic. Such algorithms are difficult to describe using logic flowcharts (Chapter 55), Nassi-Shneiderman charts (Chapter 56), pseudocode (Chapter 59), or structured English (Chapter 60). Additionally, decision tables are relatively easy for non-technical users to follow.

Decision tables are not useful for describing non-decision algorithms. They were common in the 1970s and 1980s, but few modern analysts or programmers are familiar with them.

58.3 Inputs and related ideas

Before creating a decision table, the designer must understand the algorithm or procedure. The necessary information might be compiled from direct observation, extracted from existing documentation, or derived from the problem definition (Part II) and/or analysis (Part IV) stages of the system development life cycle.

Other tools for documenting or planning routines or processes include logic flowcharts (Chapter 55), Nassi-Shneiderman charts (Chapter 56), decision trees (Chapter 57), pseudocode (Chapter 59), structured English (Chapter 60), and input/process/output (IPO) charts (Chapter 64). A routine usually exists in the context of a larger program. Tools for documenting or planning program structure include structure charts (Chapter 63) and HIPO (Chapter 64).

58.4 Concepts

Assume that the men’s basketball coach wants to look through the student records and produce a list of all full-time male students who are at least 6 feet 5 inches (or 77 inches) tall and who weigh at least 180 pounds.

A decision table for an appropriate algorithm is shown as Figure 58.1. It is divided into four sections: a condition stub at the upper left, a condition entry at the upper right, an action stub at the lower left, and an action entry at the lower right. The questions are listed in the condition stub; note that each question requires a yes/no response. The associated actions are listed in the action stub. The responses (Y or N) are recorded in the condition entry, while the appropriate action is indicated in the action entry.

58-01
Figure 58.1  A decision table.

The easiest way to understand a decision table is to read one. Start with the first question: Is the student male? There are two possible answers: yes (Y) or no (N). If the answer is no, then the student is not male, is not a candidate for the men’s basketball team, and can be rejected. Move down the column containing the N and note the X on the action entry line following the action Reject the student. If the answer is yes, however, the coach cannot yet make a decision to add the student to the list because the student must first pass three more tests.

Move on to the second question: Is the student taking at least 12 credit hours? Again, there are two possible answers: yes or no. Note how the answers are recorded on Figure 58.1. The second Y is directly under the first one, implying that the answers to both questions (plus two more) must be yes before the action identified by an X in that column’s action entry can be taken. If the answer to the second question is no, however, the student can be rejected. Note that any single N, by itself, is enough to reject the student.

Read the rest of the table. It clearly shows that the student’s name and address will be listed only if the answers to all four questions are yes, but that the student will be rejected if the answer to any one question is no.

58.5 Key terms
Action entry —
The box at the lower right of a decision table where the appropriate action is indicated.
Action stub —
The box at the lower left of a decision table where the possible actions are listed.
Condition entry —
The box at the upper right of a decision table where the responses (Y or N) to the questions in the condition stub are listed.
Condition stub —
The box at the upper left of a decision table where the questions (or decisions) are listed.
Decision table —
A two-dimensional table that shows the action to be taken following a set of related decisions.
58.6 Software

Decision tables can conveniently be constructed using a spreadsheet program. The decision tables in this chapter were prepared using Visio. Other charting programs (such as Micrografx’s Flowcharter) can also be used.

58.7 References
1.  Brown, R. V., Kahr, A. S., and Peterson, C., Decision Analysis for the Manager, Holt, Rinehart & Winston, New York, 1974.
2.  Davis, W. S., Systems Analysis and Design: A Structured Approach, Addison-Wesley, Reading, MA, 1983.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout...
Read more