PROCESS SPECIFICATIONS & STRUCTURED DECISIONS

Process specifications are created for primitive/ simple processes on a

DFD as well as for some higher-level processes that explode to a child
diagram. These specifications explain the decision-making logic and
formulas that will transform process input data into output.
Goals of producing process specifications are:
1. To reduce the ambiguity of the process. This goal compels the S.A.
to learn details about how the process works. Any vague areas
should be noted, written down, and consolidated for all process
specifications. These observations form a basis and provide the
questions for follow-up interviews with the users.
1. To obtain a precise description of what is accomplished,
which is usually included in specifications for the
programmer.
2. To validate the system design to ensure that a process has
all the input data flow necessary for producing the output.
Also, all input and output must be represented on the DFD.
3. Categories of processes that do not require specifications
are:
4. Processes that represent physical input or output, such as
read and write. These processes usually require simple
logic.
5. Processes that represent simple data validation, which is
fairly easy to accomplish.
3. To validate the system design to ensure that a process has
all the input data flow necessary for producing the output.
Also, all input and output must be represented on the DFD.
Categories of processes that do not require specifications are:
1. Processes that represent physical input or output, such as
read and write. These processes usually require simple
logic.
2. Processes that represent simple data validation, which is
fairly easy to accomplish.
The edit criteria are included in the DD and incorporated into
the computer source code. Process specifications may be
produced for complex editing.
3. Processes that use pre-written code. These processes are
included in a system as sub-programs and functions.
Sub-programs are computer programs that are written,
tested and stored on the computer system.
Sub-programs usually perform a general system function, such
as validating a date or a check digit and are written and
documented only once but form a series of building blocks
that may be used in many systems throughout the
organization. Thus, sub-programs appear as processes on
many DFDs. Functions are similar to sub-programs but are
coded differently.
 Process Specification Format
Process Specifications link the process to the DFD
and hence the DD. Each process specification
should be entered on a separate form or into a
CASE tool screen. The following information
should be entered:
1. The process number, which must match the
process ID on the DFD. This specification
allows S.A. to work on or review any process,
and to locate the DFD containing the process
easily.
2. The process name, which must be the same as
the name displayed in the process symbol on the
DFD.
3. A brief description of what the process
accomplishes/does.
4. A list of input data flows, using the names
found on the DFD. Data names used in the
formula or logic should match those in the DD
to ensure consistency and good
communication.
5.The output data flows, using DFD and DD
names.
 6.An indication of the type of process: batch,
online, or manual. All online processes require
screen designs, and all manual processes should
have well-defined procedures for employees
performing the process tasks.
7. If the process uses pre-written code, include
the name of the sub-program or function
containing that code.
8. A description of the process logic that states
policy and business rules in everyday language,
not computer language pseudo-code. Business
rules are the procedures or a set of conditions
or formulas, that allow a corporation to run its
business. Common business rule
formats include:
(i) Definitions of business terms; (ii) Business
conditions and actions; (iii) Data integrity
constraints; (iv) Mathematical and functional
derivations; (v) Logical inferences; (vi)
Processing sequences; (vii) Relationships
among facts about the business.
9. If there is not enough room on the form for
a complete structured English description,
or if there is a decision table or tree depicting the
logic, include the corresponding table or tree
name.
10. List any unresolved issues, incomplete
portions of logic, or other concerns. These issues
form the basis of the questions used for follow-
up interviews.
STRUCTURED ENGLISH
When the process logic involves formulas or
iteration, or when structured decisions are not
complex, a technique for analyzing the decision
process is the use of structured English.
 Structured English is based on (1) structured
logic, or instructions organized into nested and
grouped procedures, and (2) simple English
statements such as add, multiply, and move.
A word problem can be transformed into
structured English, by putting the decision rules
into their proper sequence and using the
convention of IF-THEN-ELSE statements
throughout. Structured English can be more
complex if blocks of instructions are nested
within other blocks of instructions.
 Writing Structured English
Following conventions/rules may be used:
1. Express all logic in terms of one of these four
types: sequential structures, decisions
structures, case structures, or iterations.
2. Use and capitalize accepted key words such
as IF, THEN, ELSE, DO, DO WHILE, DO UNTIL,
and PERFORM.
3. Indent blocks of state to show their hierarchy
(nesting) clearly.
4. When words or phrases have been defined in
a DD, underline those words or phrases to
signify that they have a specialized, reserved
meaning.
5. Be careful when using “and” and “or,” and
avoid confusion when distinguishing between
“greater than” and “greater than or equal to”
and similar relationships. “A and B” means both
A and B; “A or B” or means either A or B, but
not both. Clarify the logical statements now
rather than waiting until the program coding
stage.
 Examples of logic expressed in a sequential, a
decision, a case structures, and an iteration.
Structured English Type Example
Sequential Structure: Action 1
A block of instructions in which no Action 2
branching occurs. Action 3
Decision Structure: IF Condition A is True
Only IF a condition is true,THEN implement Action A
complete the following ELSE implement Action B
statements; otherwise, ENDIF
Jump to the ELSE
Case Structure: Example
A special type of decision IF Case1 implement
Action1
Structure in which the cases ELSE IF Case2
Are mutually exclusive implement Action2
(if one occurs, the others ELSE IF Case3
Cannot) implement Action3
ELSE IF Case4
implement Action4
ELSE print error
ENDIF
Iteration: Example
Blocks of statements that DO WHILE there
are repeated are customers
until done Action1
ENDDO
Data Dictionary and Process Specifications
All computer programs may be coded using the
three basic constructs: sequence selection
(IF….THEN…ELSE and the case structure), and
iteration or looping. The DD indicates which of these
constructs must be included in the process
specifications.
If the DD for the input and output DF contains fields
without any iteration,{ }, or selections, [ ], the
process specification will contain a simple sequence
of statements such as MOVE, ADD, and SUBTRACT.
E.g. the DD for the SHIPPING STATEMENT has the
ORDER NUMBER, ORDER DATE, and CUSTOMER
 The corresponding logic in the structured English
consists of simple MOVE statements.
A data structure with optional elements contained
in parentheses or either/or elements contained in
brackets will have a corresponding IF…THEN…ELSE
statement in the process specification.
Iteration, indicated by braces on a data structure,
must have a corresponding DO WHILE, DO UNTIL,
or PERFORM UNTIL, to control looping on the
process specification. The data structure for the
ORDER ITEM LINES allows up to five items in the
loop.
Data structure for World’s Trend shipping statement
Shipping Statement = Order Number +
Order Date +
Customer Number +
Customer Name +
Customer Address +
(Order Item {Lines} +
Number of Items +
Merchandize Total +
(Tax) +
Shipping and Handling +
Order Total
Customer Name = First Name +
(Middle Initial) +
Last Name
Address = Street +
(Apartment) +
City +
State +
Zip +
(Zip Expansion) +
(Country)
Order Item Lines = Item Number +
Quantity Ordered +
Quantity Backordered
+
Item Description +
Size Description +
Color Description +
Unit Price +
Extended Amount
Structured English to Calculate Supplier Net Bid
BEGIN CASE
IF the Supplier type is a charitable organization
THEN Commission Rate = 10%
ELSE IF the Supplier type is a government unit
THEN Commission Rate = 15%
ELSE IF the Supplier type is a bankruptcy
THEN Commission Rate = 18%
ELSE IF the Supplier type is an estate
THEN Commission Rate = 20%
ELSE Commission Rate = 25%
END CASE
 (Cont.)
Multiply Item Bid Amount by Commission Rate
giving Commission
Subtract Commission from Item Bid Amount
giving Net Bid
Move Net Bid to the Amount Paid in Supplier on
the Item Record
Rewrite the Item Record
Add Net Bid to Year-to-Date Net Bid on the
Supplier Record
Rewrite the Supplier Record
 Structured English to Print Bid Line
Move Item Description to Supplier Item Line
Move Date Sold to Supplier Item Line
Move Item Bid Amount to Supplier Item Line
Move Net Bid to the Supplier Item Line
Write Supplier Item Line
Add Net Bid to Total Net Bid Amount
 Structured English to Print Supplier Total Due
BEGIN CASE
Line
IF the Supplier Type is a charitable organization
THEN Auction Surcharge = $200
ELSE IF the Supplier Type is a governmental unit
THEN Auction Surcharge = $500
ELSE IF the Supplier Type is a bankruptcy
THEN Auction Surcharge = $400
ELSE IF the Supplier Type is an estate
THEN Auction Surcharge = $300
ELSE Auction Surcharge = $500
END CASE
 (Cont.)
Move Item Bid Amount to Statement Line
Write Statement Line
Move Auction Surcharge to Statement Line
Write Statement Line
Subtract Auction Surcharge from Total Net Bid
Amount giving Payment Total
Move Payment Total to Statement Line
Write Statement Line
 Decision Tables
Are tables of rows and columns, separated into
four quadrants as shown below:
Conditions and Actions Rules
Conditions Condition Alternatives
Actions Action Entries
The upper left quadrant contains the
condition(s); the upper right quadrant contains
the condition alternatives. The lower half of the
table contains the actions to be taken on the
left and the rules for executing the actions on
the right.
 When a decision table is used to determine
which action needs to be taken, the logic moves
clockwise beginning from the upper left.
Suppose a store wanted to illustrate its policy
on non-cash customer purchases. The company
could do so using a simple decision table below:
Rules
Conditions and Actions 1 2 3 4
Under $50 Y Y N N
Pays by check with 2 forms of ID Y N Y N
Uses credit card N Y N Y
 Each of the three conditions (sale under $50,
pays by check, and uses credit cards) has only 2
alternatives. The 2 alternatives are Y (yes, it is
true) or N (no, it is not true). Four actions are
possible:
1. Ring up the sale.
2. Look up the credit card number in a book
before ringing up the sale.
3. Call the supervisor for approval.
4. Call the bank for credit card authorization.
 The final ingredient that makes the decision table
worthwhile is the set of rules for each of the actions.
Rules are the combinations of the condition
alternatives that precipitate an action e.g Rule 3
says:
IF N (the total sale is NOT under $50.00)
AND
IF Y (the client paid by check and had 2 forms of ID)
AND
IF N (the client did not use a credit card)
THEN
DO X (call the supervisor for approval).
 Developing Decision Tables
The S.A. needs to determine the maximum size
of the table; eliminate any impossible
situations, inconsistencies, or redundancies;
and simplify the table as much as possible. The
steps for the S.A. to develop decision tables are:
1. Determine the number of conditions that
may affect the decision. Combine rows that
overlap, such as conditions that are mutually
exclusive. The number of conditions becomes
the number of rows in the top half of the
decision table.
2. Determine the number of possible actions that
can be taken. That number becomes the number
of rows in the lower half of the decision table.
3. Determine the number of condition
alternatives for each condition. In the simplest
form of decision table, there would be two
alternatives(Y or N) for each condition. In an
extended-entry table, there may be many
alternatives for each condition.
4. Calculate the maximum number of columns in
the decision table by multiplying the number of
alternatives for each condition.
 If there were four conditions and two
alternatives(Y or N) for each of the conditions,
there would be 16 possibilities as follows:
Condition 1: x 2 alternatives
Condition 2: x 2 alternatives
Condition 3: x 2 alternatives
Condition 4: x 2 alternatives
16 possibilities
5. Fill in the condition alternatives. Start with the
1st condition and divide the number of columns
by the number of alternatives for that condition.
In the example below: there are 16 columns and 2
alternatives (Y or N), so 16/2 = 8. Then choose one
of the alternatives, say Y, and write it in the 1st 8
columns. Finish by writing N in the remaining 8
columns as: Condition 1: YYYYYYYYNNNNNNNN
Repeat this step for each condition, using a subset
of the table,
Condition 1: YYYYYYYYNNNNNNNN
Condition 2: YYYYNNNN
Condition 3: YYNN
Condition 4: YN
and continue the pattern for each condition:
Condition 1: YYYYYYYYNNNNNNNN
Condition 2: YYYYNNNNYYYYNNNN
Condition 3: YYNNYYNNYYNNYYNN
Condition 4: YNYNYNYNYNYNYNYN
6. Complete the table by inserting an X where
rules suggest certain actions.
7. Combine rules where it is apparent that an
alternative does not make a difference in the
outcome e.g.
Condition 1: YY
Condition 2: YN
Action 1: XX
Can be expressed as:
Condition 1: Y
Condition 2: -
Action 1: X
The dash [-] signifies that Condition 2 can be
either Y or N, and the action will still be taken.
8. Check the table for any impossible
situations, contradictions, and redundancies.
9. Rearrange the conditions and actions (or
even rules) if it makes the decision table
more understandable.
 Decision Trees
Are used when complex branching occurs in a
structured decision process. Trees are also
useful when it is essential to keep a string of
decisions in a particular sequence.
Although the decision tree derives its name
from natural trees, decision trees are most
often drawn on their side, with the root of the
tree on the left side of the paper; from there,
the tree branches out to the right. This
orientation allows the S.A. to write on the
branches to describe conditions and actions.
 Unlike the decision tree in management
science, the S.A’s tree does not contain
probabilities and outcomes, because in SAAD,
trees are used mainly to identify and organize
conditions and actions in a completely
structured decision process.
Drawing Decision Trees
It is useful to distinguish between conditions
and actions when drawing decision trees. This
distinction is relevant when conditions and
actions take place over a period of time and
 their sequence is important. For this purpose,
use a square node to indicate an action and a
circle to represent a condition and number the
circles and squares sequentially. Think of a circle
as signifying IF, whereas the square means
THEN.
When decision tables were discussed above, a
point-of-sale example was used to determine
the purchase approval actions for a
supermarket. Conditions included the amount of
the sale (under $50) and whether the customer
paid by cheque or credit card.
The 4 actions possible were to ring up the sale,
look up the credit card in a book, call the
supervisor for approval, or call the bank for
credit card authorization. A decision tree to
illustrate this example is:
 In drawing the tree:
1. Identify all conditions and actions and their
order and timing (if they are critical).
2. Begin building the tree from left to right,
making sure you list all possible alternatives
before moving to the right.
This simple tree is symmetrical and the 4 actions
at the end are unique. A tree does not need to
be symmetrical. Most decision trees have
conditions that have a different no. of
branches. Also, identical actions may appear
more than once.
3 Adv.s of decision tree over decision table:
1. It takes adv. of the sequential structure of
decision tree branches so that the order of
checking conditions and executing actions
is immediately noticeable.
2. Conditions and actions of decision trees
are found on some branches but not on
others, which contrasts with decision
tables, in which they are all part of the
same table.
 Those conditions and actions that are critical
are connected directly to other conditions and
actions, whereas those conditions that do not
matter are absent (i.e the tree does not have to
be symmetrical).
3. Compared with decision tables, decision
trees are more readily understood by others in
the organization and consequently, they are
more appropriate as a communication tool.
Choosing a Structured Decision Analysis Technique
Guidelines for choosing amongst the three
techniques for analysis of structured decisions
(i.e structured English, decision tables, and
decision trees) are:
1. Use structured English when
(a)There are many repetitious actions, OR
(b) Communications to end users is important.
2. Use decision tables when
(b)Complex combinations of conditions, actions,
and rules are found,
 OR
(b) You require a method that effectively avoids
impossible situations, redundancies, and
contradictions.
3. Use decision trees when
(a)The sequence of conditions and actions is
critical,
OR
(b) Not every condition is relevant to every
action (the branches are different).