A DECISION TABLE APPROACH
TO SYSTEM ANALYSIS
by Solomon L. Pollack • Harry Hicks • William Harrison
Decision Tables and System Analysis
Before the programming step, which is meant to define a
solution to a problem, the problem itself must be defined.
The total problem must be separated from other related, or
u n r e l a t e d , problems and broken down into manageable
units. Often, problems must be combined rather than di-
vided, or the viewpoint taken of the problem must be
completely altered.
This entire discipline, undertaken before any program-
ming is even started, is known as System Analysis. The sys-
tem analyst must study, analyze, understand, and organize
the system in which the probelm areas reside. Decision
tables can be extremely useful in the analysis of systems.
Logical Organization
As in programming applications, decision tables are used
in system analysis for handling the logical aspects of the sit-
uation. It is the relationship of cause (Conditions) to effect
(Actions) that forms the logical structure of a system.
Causes, as for example a man's pay rate and his hours
worked during the week, lead to an effect, which in this
case might be calculation of his weekly gross pay. The com-
bination of these two causes that lead to the effect consti-
t u t e s a particular logical relationship, even though the
specific calculation required to get from rate and hours to
gross pay may vary from analyst to analyst. This might
be likened to a high-speed expressway. A road may go from
C h i c a g o to New York, but whether you travel in a sports
car, limousine, or ten-ton truck is immaterial from the
logical point of view.
In data processing systems, the logical structure is the
r o u t e between the source of data and the final production
of information. How these routes are ultimately traveled is
a matter of processing method and not of the logical struc-
ture with which the system analyst is concerned.
6 DATA BASE, VOL. 2, No. 1, Spring 1970
Interfaces
An interface might be defined as "where things meet."
From the system analyst's point of view, an interface is
where data meet and enter the system and where infor-
mation leaves the system as output. Data are used here to,
mean the raw input, unprocessed by the particular system
into which they are being entered; information is defined
here as that which the system has extracted from the data.
Breaking down a system into parts means adding new
interfaces between these parts. Combining separate systems
means eliminating common interfaces. Redefining a system
means finding entirely new interfaces.
Role of the System Analysis Table
Decision tables for system analysis purposes are designed
primarily to help the analyst study the structure of his sys-
tem. Using the system analysis table, the input data are asso-
ciated with the output information in the system to enable
the analyst to recognize the natural divisions of the system
and logical similarities between systems. Helping the pro-
grammer develop programs to handle the details of that
system is a secondary benefit of these tables. Thus the lan-
guage used is nearer to a natural rather than a programming
language.
T h e system analysis table can be analyzed in various
ways, and these will be discussed here largely by example.
Objectives of such analysis include determining:
A. Which input data are really required and which
are redundant.
B. How a system might be divided.
C. How systems may be combined.
A d m i t t e d l y , this whole area is far more of an art than
a science - - few algorithmic guidelines exist. However, in
the list above, " A " is somewhat similar to redundancy and
contradiction checking for decision tables, " B " to the split-
ting of tables, and " C " to the combination of programming
types of decision tables - - all topics that are discussed
elsewhere in the book from which this chapter is extracted.
Interfaces are represented in a system analyst's decision
table as conditions for input data and as actions for output
information. As a description of the previously mentioned
gross pay problem, a system analyst's table might be as
shown in Figure 1.
STUBS RULES
C Pay-Rate N N Y University.
C Hour-Work N Y N ment Incorporated, North American Rockwell Space Division, the
A Gross-Pay
A Error X X X ment o f the specification for D E T A B - X (Decision Tables, Experi-
Figure 1
DECISION TABLE FOR
DESCRIPTION OF GROSS PAY PROBLEM
Here, two input data interfaces (Pay Rate and Hours
Worked) are expressed as conditions, while the information
interfaces (Gross Pay a n d Error) are expressed as actions.
Every combination of the conditions is included within
the rules. Notice that " Y ' " and " N " are used (other condition
rule entries will be discussed later) to express presence or
absence of the condition. Only one of these combinations
leads to calculation of a gross pay figure. How that figure is
calculated is unimportant at present.
The other three rules define errors and an action is pre-
scribed for this. The presence of a logical error in the input
data is always a valid item of information, and thus an
a c t i o n in the system analysis table and an output of a
system.
Setting Up The System Analysis Table
The system analysis table may be set up as a binary ma-
trix form of table where every combination of truth and
falsity of every condition is included. Where many types of
data are being inputted such tables would become very
large, so that other entries such as don't-cares and extended
e n t r i e s may be desirable. Dependencies may also exist.
Where these dependencies are apparent it may be advanta-
geous to use * and $ to improve the readability of the table.
Our examples will utilize only " Y " , " N " , and " - " (don't-
care).
DATA BASE, VOL. 2, No. 1, Spring 1970
SOLOMON L. P O L L A C K is Director o f the Computer-Based Sys-
tems Design Group o f S. D. Leidesdorf & Co. "s Management Services
Division and received his MS degree at the George Washington
Previous to his present position he was with Information Manage-
Rand Corporation and the National Bureau o f Standards. Mr. Pollack
has been active in the decision table field since 1959. As a member
o f the CODASYL Systems Group, he participated in the develop-
mental). He has also published articles on the analysis o f decision
rules o f decision tables and conversion o f decision tables to com-
puter code. Mr. Pollack was the Chairman o f the 1969 National
ACM Conference held in San Francisco in August 1969 and a
member o f the Data Processing Management Association Long-
Range Advisory Committee. He is also Past Chairman o f the ACM's
National Special Interest Group for Data Processing and Past Chair-
man o f the Los Angeles Chapter o f ACM. Effective July 1, 1970, he
will serve as a member o f the DPMA Certification Council.
W I L L I A M J. H A R R I S O N is with Fireman's Fund Insurance and is
working in generalized on-line applications systems. He obtained his
BS in physics from the University o f Louisville, Ky., in 1961, and
currently is enrolled in the graduate program, Department o f Elec-
trical Engineering and Computer Sciences (EECS) at the University
o f California at Berkeley. Until recently he was staff consultant
with Autologic Inc. Previous to Autologic, Mr. Harrison was with
Information Management (1967-69) as a consultant implementing
DETAP (Decision Table Processors), M A G I C COBOL syntax check-
ing package, COBOL compiler validation system (USAF's standards
enforcing system), etc.; with IBM (from 1963-67) in New York City
and Westwood, Calif., as a compiler-writer with 0S/360 COBOL-F,
COBOL-D and E maintenance, and as acting manager, 7090/94
COBOL; with Librascope Inc. (from 1961-63) o f Glendale, Calif.,
on logic design automation.
Mr. Harrison has been in data processing since 1952 and large
scale programming since 1961. He is the author o f "'Constructing
Crosswords," 1961, a h o w - t o - d o - i t manual on the process o f puzzle
construction that is sold through bookstores and contest magazines.
He is coauthor o f "'Crossword Puzzles in the Classroom, the First
Grade,'" to appear shortly in The Instructor, a journal for teachers.
He is a/so the author o f a paper, "'Out-of-Focus Images," Some
Properties, Uses, and a Geometrical Explanation,'" in Applied Optics,
Op. Society o f America Journal, Sept. 1967. He is puzzle editor for
the "Bit Dropper, "'a news periodical o f the Bay Area Chapter, A CM.
7
 Figure 2 is an expansion of our earlier gross pay example Figure 2 its conditions are grouped as shown in Figure 2.5:
into a simple payroll system for purposes of illustration:
Input Data Output Information
Input Data Output Information Gross-affected by (Time-cards, Gross-adjustments,
Time-cards Pay-checks Pay-rate)
Gross-adjustments Labor-Distribution Year-to-Date by (YTD-earnings)
Pay-rate Payroll-Register Taxes by (The three Tax Tables)
YTD-earnings YTD-Earnings Deductions by (Deduction-master, Insurance,
Tax-Table (Federal) Bond-Register Garnishees)
Tax-Table (State) Stock-Register Figure 2.5
Tax-Table (City) Garnishee-Checks SIMPLE P A Y R O L L S Y S T E M WITH C O N D I T I O N S G R O U P E D
Deduction-Master
Insurance These four conditions groups may be used to form a
Garnishees table of only 2 4 = 16 rules, as shown in Figure 3.
The "X'" is placed in each appropriate entry when an
Figure 2
affirmative answer applies to the question " w h i c h actions
I N P U T / O U T P U T D E S C R I P T I O N FOR
A SIMPLE P A Y R O L L S Y S T E M
result from this particular combination of conditions?"
Analyzing the System Analysis Table
Reduction of Table Size The system analysis table may be used to analyze the
There are ten data inputs in this example. To form a order in which the input data is required within the system
binary table - - one that includes every possible combi- and the order in which the output information is to be pro-
nation of these ten conditions - - would require 210 or duced. One general approach is to repeat the table's condi-
1,024 rules. tions, each with its group of like action row(s).
A table of 1,024 rules, as required for the rules to be This is illustrated in the upper portions of Figures 4, 5, 6,
generated from Figure 2, is unwieldly and difficult to man- and 7, which are derived from Figure 3 by repeating the
age. Two techniques are available for reducing this table - - conditions of the table shown in Figure 3, but each with its
and any large table - - to manageable size. The first is by own unique series of actions. Those rules that have no
use of the don't-care condition, and the second is by group- actions in any particular table are assumed directed to the
ing of conditions. We shall utilize both methods, grouping "Else" rule and, in effect, dropped from that table.
conditions first and then introducing don't cares by the I n each of these new tables, redundancy exists among
process of rule combination. the set of rules, since each has the same action. These re-
Grouping of conditions requires some knowledge of how dundant rules may be combined. Combination procedures
these conditions will be used. In the payroll example of are discussed in the book in detail, but here it suffices to

RULES
STUB 1 2 4 S 6 7 8 9 10 11 12 13 14 15 16
I
Gross-affecting Y Y Y Y Y Y Y N N N N i N N ! N N

Year-to-date Y Y Y N N N N Y Y Y Y N N N N

Taxes Y Y N Y Y N N Y Y N N Y Y N N
Figure 3
Deductions Y N N Y N Y N Y N Y N Y N Y N
DECISION T A B L E FOR
SIMPLE P A Y R O L L S Y S T E M Pay-checks X
WITH X X X X X X X X
Labor-distribution
GROUPED CONDITIONS
Payroll-register X
YTO-earnings X X
Bond-register X X X X X X X X
Stock-register X X X X X ~ X X X

Garnishee-checks X X X X X i X X X - -

8 D A T A BASE, VOL. 2, No. 1, Spring 1970

s a y t h a t if t w o rules have the same actions and d i f f e r in Th e final result o f full rule c o m b i n a t i o n o f t he f o u r new
o n l y one c o n d i t i o n e n t r y - - a "Y" and an " N " -- then tables is s h o w n u n d e r t h e heavy a r r o w s in Figures 4, 5, 6,
the t w o rules m a y be c o m b i n e d . The d i f f e r i n g e n t r y b e - and 7. I t should be n o t e d t h a t in o u r e x a m p l e all rules were
comes a d o n ' t - c a r e ( " - " ) . able t o be c o m b i n e d ; this w i l l n o t always o c c u r .

RULE RULES
STUB 1 STUB 1 2
Gross-affecting Y Gross-affecting Y Y
Year-to-date Y Year-to-date Y Y
Taxes y Taxes Y Y
Deductions Y Deductions Y N

Pay-checks X YTD-earnings X X
Payroll-register X

-g. STUB RULES

Gross-affecting Y
STUB RULES
Year-to-date Y
Gross-affecting Y
Taxes Y
Year-to-date Y
Deductions
Taxes Y
YTD-earnings X
Oeductions Y
Pay-checks X Figure 6
Payroll-register X TRANSFORMATION OF RULES 1 AND 2 OF FIGURE 3

Figure 4
RULES
TRANSFORMATION OF RULE 1 OF FIGURE 3 STUB 1 3 7 9 11 13 15
Gross-affecting Y Y Y N N N N
Year-to-date Y Y N Y Y N N
Taxes Y N N Y N Y N
RULES
STUB 1 2 3 4 5 6 7 Deductions Y Y Y Y Y Y Y
Gross-affecting Y Y Y Y Y Y Y Bond-register X X X X X X X
Year-to-date Y Y Y Y N N N
Stock-register X X X X X X X
Taxes Y Y N N Y Y N
Garnishee-checks X X X X X X X
Deductions Y N Y N Y N Y

Labor-distribution X X X X X X X
STUB RULES
-IF Gross-affecting
Year-to-date
STUB RULES
Taxes
Gross-affecting Y Deductions Y
Year-to-date
Bond-register X
Taxes
Stock-register X
Deductions I -
Garnishee-checks X
Labor-distribution X

Figure 7
Figure 5 TRANSFORMATION OF RULES 1, 3, 5, 7, 11, 13, AND 15
TRANSFORMATION OF RULES 1-8 OF FIGURE 3 OF FIGURE 3

D A T A BASE, VOL. 2, No. 1, Spring 1970 9

 By combining rules in each of these tables, the order in
which input data is needed and the order in which output
information is produced within the system may be deduced.
This demand for data (order in which input is needed) can
be considered a major criterion in system design.
Application of the Analysis to Program Flow
The program flow for the simple payroll system used as
our example can be shown based upon the original decision
table of Figure 3. The resultant block diagram (Figure 8),
however, is gross and unwieldy and serves little more than
to show the basic data-to-information relationship.
PAYROLL
SYSTEm
Figure 8
BLOCK DIAGRAM OF P A Y R O L L
10
The advantage of analyzing the system using the system
analysisdecision tables becomes apparent in Figure 9. Based
on the results of analysis presented in the lower portions of
Figures 4, 5, 6, and 7, Figure 9 reveals that the payroll
system can also be divided into as many as four parts. The
system is now "open" for definitive analysis.
Before leaving the payroll example, it should be pointed
out that it has been highly simplified in order to illustrate
the t e c h n i q u e involved. Mainly, deductions have been as-
sumed completely independent of gross, a situation that
is seldom true in real systems. However, this does not in-
validate the technique; the groupings assumed in Figure 2.5
PAY-CHECK
PAYROLL-
REGISTER
LABOR-
DISTRIBUTION
_I ..':,O;o, ]
BOND-
REGISTERS
STOCK-
REGISTERS
E-
c•GARHISHE l
S Y S T E M B A S E D ON F I G U R E 4
D A T A BASE, V O L . 2, No. 1, Spring 1970
could be changed to match the correct assumptions.
Use of the Don't-Care and Other Condition Types
Don't-care entries ( " - " ) were introduced during the pre-
ceding payroll example only in the final step of rule com-
binations (Figures 4, 5, 6, and 7). In more practical cases,
the approach just outlined will result in large unwieldy
tables. Their size may be reduced initially by determining
what relationships the various data inputs have to one
another. Primarily, certain ones will have an effect that
obviously doesn't depend on the others. An example is the
"Deductions" group of entries in Figure 3.
Given the restrictions stated in that example, deductions
may be used to produce the three deduction registers re-
gardless of the other three inputs, leading us directly to the
table shown below the heavy arrow of Figure 7.
The same is true of the Labor-distributions, assumed
here to be in terms of man-hours only and thus obtainable
from only the gross-affecting input. This leads us to the
bottom table in Figure 5, containing don't-cares.
Only less obvious cases may not need the full analysis,
such as that in Figure 6. Once the simplified one-rule tables
are obtained for each action, the relationship of one to
another, in terms of data demand, becomes visible.

/ YTD-
P1 P3

D i S TLABOR"
Ri~
1
~BOHD-
1 "

I GARNISHEE- I Note: The four system parts above correspondto the four final tables as follows:
P 1 : Figure S P 2: Figure 7 P 3 : Figure6 P 4: Figure 4

Figure 9
BLOCK D I A G R A M OF PAYROLL SYSTEM ON FIGURES 4, 5, 6, AND 7

DATA BASE, VOL. 2, No. 1, Spring 1970 11

 BIBLIOGRAPHY FOR
"'A Decision Table Approach to System Analysis"
by POLLACK, HICKS, and HARRISON
BROWN, Lynn M., "Decision Table Experience on a File
Maintenance System," Proceedings of the Decision Table
Symposium, NYC, September 1962.
CANNING, Richard G., "Time to Consider Structure Tables
and EDP System Design Sessions," EDP Analyzer, Vol. 1,
No. 4, (May 1963).
, "How to Use Decision Tables," EDP Analyzer,
Vol. 4, No. 5, (May 1966).
DIXON, Paul, "Decision Tables and Their Applications,"
Computers and Automation, Volo 13, No. 4, (April 1962).
FISKE, Fred H., " A Case History: Accounting Use of De-
cision Tables for Definition of Computer Program Logic,"
One Day Technical Symposium of Los Angeles Chapter
of ACM, March 1967.
GRAD, Burton, "Decision Tables in System Design," Digest
of Technical Papers, ACM National Conference, Sep-
tember 1962.
HUGHES, M. L., Shank, R. M., Stein, E. S., Decision Tables,
MDI Publications, 1968.
IBM, Decision Tables - A Systems Analysis and Documenta-
tion Technique, IBM Technical Publication, F20-8102,
1962.
POLLACK, S. L., "Decision Tables for Systems Design,"
Data Processing, Vol. 7, DPMA, 1965.
12
PUZZLE CORNER
Problem: The following are the pertinent data and pro-
cedural statements of COBOL program (any machine or
level):
77 Item D usage display picture 9.
Start. Move 9 to item D.
Loop. Subtract 1 from item D. Display item D. If
item D is not less than 0, go to loop. Stop run.
Will this program:
a. Print 9 lines and stop?
b. Print once and stop?
c. Go into an endless print loop?
Answer to Winter Issue Puzzle.
C O M P U T A T I O N A L (binary), C O M P U T A T I O N A L - 3
(packed decimal) and DISPLAY (BCD) items were to be
initialized by either the literal + 1 or the COMPUTA-
TIQNAL VALUE 1 item called ONE. The most and least
efficient methods in terms of time were requested. Data
conversions were the key here, with the most efficient being
MOVE + 1 TO all three items, taking advantage of the
compiler's optimization of literals in MOVEs. The least
efficient was moving ONE (binary) to the DISPLAY item
(2 conversions) and to the COMPUTATIONAL-3 item
(1 conversion) and then moving the DISPLAY item back
into the COMPUTATIONAL item (2 conversions).
DATA BASE, VOL. 2, No. 1, Spring 1970