Process Specifications

Section 0: Module Objectives or Competencies

Section 1: Definition

Process specifications are the methods available for documenting and analyzing the logic of structured decisions.

• Process specifications are created for primitive processes and some higher level processes on a data flow diagram.
• They are also created for class methods in object-oriented design and for the steps in a use case.
• Structured decision analysis methods promote completeness, accuracy, and communication.

The basic aspects of a process specification:

• Describe the logic of the process
  • decision making process, policy rules and procedures
  • procedure versus policy
  • action, rules, conditions, sequence structure, repetition
• Often help and lead to program specification
  • completeness checks and extreme cases
• Often found in repositories linked to data flow diagrams component
  • part of the process of documenting the DFD components
  • other tasks including defining data stores, defining data elements, etc.

Section 2: Justification

Process specifications reduce ambiguity by providing a precise description of the system in enough detail to guide programmers in developing the system, explaining exactly how each function is accomplished by defining what must be done in order to transform inputs into outputs, along with a detailed set of instructions outlining each business procedure.

Video: How To Write Data and Process Specifications

• Although the data dictionary defines details about the data in the system, and DFDs model the system, we have not fully specified the system in enough detail for programmers.
  • If we don’t take this next step of Process Specification and finish the analysis with just a set of DFDs, then our analysis of the system will be lacking in detail and it is likely that when we get to the implementation phase, the system will be developed in a way different to that intended.
  • The lack of a process specification will mean that there will be many possible valid interpretations of how a particular process should work.
• DFDs show functional primitives, with descriptive process names to indicate purpose of each function, but they do not indicate exactly how each function is accomplished.
• Process descriptions, also called mini-specs or transform descriptions, document procedures.

Section 3: Goals

• The goals of producing process specifications include:
  • To reduce the ambiguity of the process.
    • This compels the analyst 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 a follow-up interview with the user community.
  • To provide a precise description of what is accomplished.
    • Included in a packet of specifications for the programmer.
  • To validate the system design, including data flow diagrams and the data dictionary.
    • Includes ensuring that processes have all the input needed to produce the output.
    • All input and output must be represented on the data flow diagram.

Section 4: Scope

A process description is created for every functional primitive on a set of DFDs.

• Process specifications are not created for parent processes at the highest levels of a structure chart because the actual work occurs on the lowest level.
  • Parent processes allow the system to be partitioned in a top-down manner.
  • By specifying the functional primitives, the parents are specified indirectly since they are the sum of their subordinate primitives.
  • Note that if a parent process contains control logic then a process description is required.
• Process specifications are not created for
  • processes that represent physical input and/or output.
  • processes that represent simple data validation.
  • processes that use prewritten code provided in libraries or as part of the language.

Relationship Between Process Specifications and DFDs

Process specifications link the process to the DFD and the data dictionary.

Section 5: Process Specification Format Information

The following information should be entered:

• The process number
  • Must match the process ID on the data flow diagram.
  • Allows the analyst to work on or review any process, and to locate easily the data flow diagram containing the process.
• The process name
  • The process name, the same as that displayed within the process symbol on the DFD.
• A brief description of what the process accomplishes
  • Example: Determine if an item is available for sale. If it is not available, create a backordered item record. Determine the quantity available.
• A list of input data flows
  • Uses the names found on the data flow diagram.
  • Data names used in the formula or logic should match the data dictionary for consistency and good communication.
• A list of output data flows
  • Uses data flow diagram and data dictionary names
• An indication of the type of process, whether it is batch, online, or manual
  • online processes require screen designs (user interfaces)
  • manual processes should have well-defined procedures for employees performing the process tasks
• If the process has prewritten code for it, include the name of the subprogram or function
• A description of the process logic
  • This should state policy and business rules, not computer language pseudocode
  • Business rules are the procedures that allow a corporation to run its business.
    • Definitions of business terms
    • Business conditions and actions
    • Data integrity constraints
    • Mathematical and functional derivations
    • Logical inferences
    • Processing sequences
    • Relationships among facts about the business
• Logic method reference
  • If there is not enough room for a complete structured English description, include a reference to the structured English description, decision table, or decision tree depicting the logic.
• List any unresolved issues
  • Incomplete portions of logic
  • These issues form the basis for the questions used for follow-up interviews with users or business experts you have added to your project team

Section 6: Approaches

Approaches include

• structured English
• decision trees
• decision tables

Guidelines

• A single approach should be used for an individual functional primitive.
• A combination of approaches can be used to specify the overall system, mixing and matching approaches.
• Choose the best documentation tool for each functional primitive.

Section 7: Structured English

Structured English is a textual documentation tool that represents process specifications via simple English imperative verbs that give commands such as ADD, MULTIPLY, MOVE, and so on.

• Based on structured logic and natural English.
  • Similar to pseudocode used in structured programming.
• Used when the process logic involves formulas or iteration, or when structured decisions are not complex.

When to Use Structured English

• Structured English is well suited to lengthy sequential processes or simple control logic (describing procedures).
• Structured English is good for low complexity structured decisions.
• Use structured English when there are many repetitious actions or when communication to end users is important.

Creating Structured English

• Express all logic in terms of sequential structures, decision structures, case structures, or iterations.
• Use and capitalize accepted keywords such as IF, THEN, ELSE, DO, and PERFORM
• Indent blocks of statements to show their hierarchy (nesting) clearly.
• Underline words or phrases that have been defined in a data dictionary to signify that they have a specialized, reserved meaning.
• Clarify the logical statements – avoid confusion when using logical comparisons such as "greater than" and "greater than or equal to”.
• Be careful when using "and" and "or".
• Conditions, condition alternatives, actions, and action rules must be known in order to design systems for structured decisions.

Examples of Structured English Logic

• Note indentation of nested conditions and If-then-else.

Example

Problem Description: First, if the amount of the invoice is over $1,000, it cannot be paid until authorization is received from management, so the invoice appears on the cash requirements report. If the amount is less than $100, payment is authorized immediately, since it is costly to delay payment, only to process the invoice again in a few days. If the invoice amount is between $100 and $1,000, inclusive, payment is authorized unless it is 10 days old or less and there is no early payment discount. For the latter cases, payment is delayed since it will tie up capital without giving a return. Such invoices are set aside until the next time authorization is checked.

Advantages of Structured English

• Useful for clarifying the logic and relationships found in human languages.
• An effective communication tool, it can be taught to and understood by users in the organization.

Video: Structured English

Section 8: Decision Trees

A decision tree is a graphic documentation tool that represents conditions and their resulting action.

• A condition is
  • something that can vary,
  • something that determines what action will be taken,
  • or something that occurs as part of an "if" statement or is implied as part of an "else".

Example of Decision Tree

Video Explanation

Video: Decision Trees - Example 1

When to Use Decision Trees

• 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.
• Use decision trees when the sequence of conditions and actions is critical or when not every condition is relevant to every action (the branches are different).

Creating Decision Trees with Example

Problem Description: First, if the amount of the invoice is over $1,000, it cannot be paid until authorization is received from management, so the invoice appears on the cash requirements report. If the amount is less than $100, payment is authorized immediately, since it is costly to delay payment, only to process the invoice again in a few days. If the invoice amount is between $100 and $1,000, inclusive, payment is authorized unless it is 10 days old or less and there is no early payment discount. For the latter cases, payment is delayed since it will tie up capital without giving a return. Such invoices are set aside until the next time authorization is checked.

• Step 1: Identify all conditions and actions and their order and timing (if they are critical).
  

  Condition	Condition Values
  Total Invoice Amount	Less than $100 From 100 to $1000 inclusive Greater than $1000
  Invoice Age	Less than or equal to 10 days Greater than 10 days
  Early Payment Discount	Yes No

• Step 2: Apply First Condition
  • Begin with either the most important condition or the one that occurs first in the real world.
  • Begin building the tree from left to right, making sure you list all possible alternatives before moving to the right.
    • Begin at the left-hand side of the paper and draw radiating lines out to the right, one for each possible value for the condition we are depicting.
    • Example:
      
• Step 3: Apply Second Condition
  • Next consider each of the possible values of the first condition in light of the second most important condition (in the problem, invoice age) and its possible values.
    • For amount smaller than 100, is invoice age important? No, payment is authorized automatically, so the line is extended to the right.
    • For amounts between $100 and $1000, inclusive, is invoice age important? Yes, so the line is split to indicate two possible paths: "less than or equal to 10 days" and "greater than 10 days."
    • Invoice age is not relevant for amounts over $1000, so the line is extended.
    
• Step 4: Evaluate Remaining Conditions
  • Consider the remaining conditions. The process is continued, extending to the right, until all conditions have been exhausted.
    • The early payment discount is the only remaining condition. The only time that a discount makes a difference is for invoice amounts of "$100 to $1000, inclusive" and invoice ages "less than or equal to 10 days." The line is split accordingly.
    
• Step 5: Enter Actions
  • When all conditions have been entered into the decision tree, the actions must be entered.
    • If the conditions and values serve as the "if" part of the logic, then the actions are what would follow a "then."
  • There may be one action per line, or there may be multiple actions.
  • Example:
    
• Step 6: Create Key and Titles
  • Create a key for abbreviations used and add titles across the top for clarity. If constructed properly, the decision tree should cover all possible circumstances.
    • These were entered as the tree was constructed.

How to Use a Decision Tree

• To use a decision tree, begin at the left and work across, taking the appropriate path for each condition.
• When the rightmost column is reached, the appropriate action for the combination of conditions is specified.

Decision Tree Advantages

• The order of checking conditions and executing actions is immediately noticeable.
• Conditions and actions of decision trees are found on some branches but not on others.
• Compared to decision tables, decision trees are more readily understood by others in the organization.

Another Example

Video: Decision Tree 1: how it works

Video: Decision Trees & Decision Tables

Section 9: Decision Tables

A decision table is a two-dimensional matrix representation of the logic of a decision that specifies the possible conditions for the decision and the resulting actions.

• The table includes one horizontal row for each condition and each action, and
• one vertical column for each combination of values and resulting actions.

Decision tables provide a way to examine, describe, and document conditions and their resulting actions. They are used to

• Describe the conditions
• Identify possible decision alternatives
• Indicate actions should be performed
• Describe actions

Decision tables are best used for complicated decision logic.

Video Explanations

Video: Decision Tables

Video: Decision Table Testing tutorial with examples

When to Use Decision Tables

• Use decision tables when a complex combination of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions.

Creating Decision Tables with Example

The text provides a pretty decent approach for creating decision tables (starting on page 267). The following approach is quite similar.

Example

Problem Description: First, if the amount of the invoice is over $1,000, it cannot be paid until authorization is received from management, so the invoice appears on the cash requirements report. If the amount is less than $100, payment is authorized immediately, since it is costly to delay payment, only to process the invoice again in a few days. If the invoice amount is between $100 and $1,000, inclusive, payment is authorized unless it is 10 days old or less and there is no early payment discount. For the latter cases, payment is delayed since it will tie up capital without giving a return. Such invoices are set aside until the next time authorization is checked.

• Step 1: Create the Empty Matrix
  • Start with a column header row plus a horizontal row for each of the columns that has been identified.
    • There are three conditions, so the table must include a header row plus three condition rows for the empty matrix.
  • The number of vertical columns that are needed must be determined next.
    • There are 3 (values for the total invoice amount) times 2 (values for invoice age) times 2 (values for early payment discount), for a total of 12 value columns with an additional column for the labels.
    
• Step 2: Enter First Row
  • The repetition factor for each value for the first condition is calculated by subtracting 1 from the total number of columns (in order to remove the label column from the calculations) and divide the result by the number of values possible for the first condition.
    • In this problem 12 is divided by 3 (possible values for invoice amount) to get 4 as the repetition factor.
    
• Step 3: Entering Remaining Rows
  • To find the repetition factor for the second row, divide the repetition factor for the first row by the number of values possible for the second condition.
    • The repetition factor for the first row (4) is divided by 2 (the number of values possible for the invoice age) giving 2 as the repetition factor for the second row. Therefore, each value is repeated two times across the second row.
  • For each successive row of the decision table, calculate the repetition factor by dividing the repetition factor for the preceding row by the number of values possible for the current condition.
    • The repetition factor for the third row of this problem is 2 divided by 2.
    
• Step 4: Identify Actions
  • Next, add as many rows as there are possible actions.
    • In the example there are three actions – authorize payment, set invoice aside, put invoice on cash requirements report – so three rows are added.
    
• Step 4b: Convert to Extended Entry Format
  • A more concise way of showing correct actions combines mutually exclusive actions into one row and uses a code to indicate which one applies for each column. This is called extended entry format.
    
• Step 5: Create a Key
  • Performed as the table was under development.
• Step 6: Condense the Decision Table
  • Eliminate redundant columns.
    • Rules 1 through 4 are indifferent to the values of invoice age and payment discount, since those conditions do not affect the outcome. Therefore, they are candidates to be condensed into one column.
    • Rules 5 and 6 remain unchanged.
    • Rules 7 and 8 can be condensed.
    • Rules 9-12 can also be condensed.
    

Video: Simplifying Decision Tables

How to Use Decision Tables

• A decision table is a table of rows and columns, separated into four quadrants.
  • The upper left quadrant contains the condition(s).
  • The upper right quadrant contains the condition alternatives.
  • The lower left quadrant contains the actions to be taken.
  • The lower right quadrant contains the rules for executing the actions.
• When a decision table is used to determine which action needs to be taken, the logic moves clockwise beginning from the upper left.

Advantages of Decision Tables

• Decision tables help analysts ensure completeness and accuracy.
• They make it easy to check for possible errors like
  • Impossible situations
  • Contradictions
  • Redundancy

Section 10: Flow Charts

Flow charts can also be used to specify the logic of processes.

• For more details, see the supplemental flow chart notes .
• You can also view a portion of a PowerPoint presentation developed by another professor.

Section 11: Practice Exercises

• Exercise 1 (solution)

Section 12: Supplemental Materials

Supplemental Notes

Useful Recap

Video: Process Specs and Structure Charts