SlideShare a Scribd company logo
1 of 30
Chapter 11 
Describing Process 
Specifications 
and Structured Decisions 
Systems Analysis and Design 
Kendall and Kendall 
Fifth Edition
Major Topics 
Process specifications 
Business rules 
Structured English 
Decision tables 
Decision trees 
Horizontal balancing 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-2
Process Specifications 
The methods available for documenting 
and analyzing the logic of structured 
decisions include structured English, 
decision tables, and decision trees 
Process specifications are created for 
primitive processes and some higher 
level processes on a data flow diagram 
They are also called minispecs 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-3
Goal of Creating Process 
Specifications 
The goals of producing process 
specifications are 
Reduce process ambiguity 
Obtain a precise description of what is 
accomplished 
Validate the system design, including data 
flow diagrams and the data dictionary 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-4
Process Specifications 
Process specifications are not created 
for 
Physical input and/or output processes 
Processes that represent simple data 
validation 
Processes for which prewritten code 
already exists 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-5
Process Logic 
Process descriptions may exist on a form or 
within a CASE tool repository 
Process logic may be represented as 
Structured English 
A decision table 
A decision tree 
A formula 
Any combination of the above 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-6
Business Rules 
Business rules include the following: 
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 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-7
Process Specification Format 
Process specifications link the process 
to the DFD and the data dictionary 
The following information should be 
entered: 
The process number, which must match 
the process ID on the data flow diagram 
This allows an analyst to work or review 
any process and easily locate the data flow 
diagram containing the process 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-8
Process Specification Format 
The process name, the same as displays 
within the process symbol on the DFD 
A brief description of what the process 
accomplishes 
A list of input and output data flow, using 
the names found on the data flow diagram 
Data names used in the formulae or logic 
should match the data dictionary, for 
consistency and good communication 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-9
Process Specification Format 
An indication of the type of process, 
whether it is batch, online or manual 
All online processes require screen designs 
All 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 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-10
Process Specification Format 
A description of the process logic 
This should state policy and business rules, 
not computer language pseudocode 
A reference to further information, such as 
a structured English description, a decision 
table or tree depicting the logic 
List any unresolved issues 
These form the basis of the questions used 
for a follow-up interview 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-11
Process Specification Example 
Part 1 
Number 1 
Name Add Customer Order 
Description Key and add the Customer Order. 
The order should be edited for correct information. 
Customer and Item master files are updated. 
Input Data Flow 
Customer Order Form from the Customer 
Customer Record from data store D1, Customer Master File 
Item Record from data store D2, Item Master File 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-12
Process Specification Example 
Part 2 
Output Data Flow 
Pending Order to data store D3, Order File 
Backordered Item Record to the Inventory Control Department 
Updated Customer and Item records 
Type of process Online 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-13
Conditions and Actions 
Conditions, condition alternatives, 
actions, and action rules must be 
known in order to design systems for 
structured decisions 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-14
Structured English 
Structured English is based on 
structured logic 
Simple English statements such as add, 
multiply, move, and so on 
 It is an appropriate technique for 
analyzing the system when structured 
decisions are not complex 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-15
Steps to Use Structured 
English 
The following steps are needed: 
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 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-16
Steps to Use Structured 
English 
Underline words or phrases used have 
been defined in a data dictionary to 
signify that they have a specialized, 
reserved meaning 
Be careful when using "and" and "or" 
Avoid confusion when using logical 
comparisons such as "greater than" and 
"greater than or equal to” 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-17
Advantages of Structured 
English 
Clarifying the logic and relationships 
found in human languages 
An effective communication tool, and 
easy to teach and understand 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-18
Data Dictionary and Structured 
English 
The data dictionary is a starting point 
for creating structured English: 
Sequenced data dictionary entries become 
simple structured English statements 
Selection [] entries become 
IF..THEN...ELSE statements 
Iteration { } entries become DO WHILE, 
DO UNTIL, or PERFORM UNTIL structured 
English statements 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-19
Decision Tables 
Decision tables provide a way to 
examine, describe, and document 
decisions using a table 
They are used to 
Describe the conditions 
Identify possible decision alternatives 
Indicate actions should be performed, and 
Describe actions 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-20
Decision Tables 
Decision tables help analysts ensure 
completeness and accuracy 
Four main problems that can occur in 
developing decision tables 
Incompleteness 
Impossible situations 
Contradictions 
Redundancy 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-21
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 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-22
Drawing Decision Trees 
 First, identify all conditions and actions 
and the order and timing of these (if 
they are critical) 
Second, begin building the tree from 
left to right while making sure you are 
complete in listing all possible 
alternatives before moving over to the 
right 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-23
Decision Tree Advantages 
Three advantages over a decision table 
The order of checking conditions and 
executing actions is immediately noticeable 
Second, conditions and actions of decision 
trees are found on some branches but not 
on others 
Third, compared to decision tables, 
decision trees are more readily understood 
by others in the organization 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-24
Selecting a Structured Decision 
Analysis Technique 
Use these guidelines: 
Use structured English when there are 
many repetitious actions or when 
communication to end users is important 
Use decision tables when complex 
combination of conditions, actions, and 
rules are found or you require a method 
that effectively avoids impossible 
situations, redundancies, and 
contradictions 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-25
Selecting a Structured Decision 
Analysis Technique 
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) 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-26
Parent Process Specifications 
If a process explodes to a child 
diagram, the process becomes a control 
module when the computer program 
representing the process is written 
The logic of the process shows the 
sequence that the child diagram 
processes must be executed in 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-27
Program Process Specification 
All the process specifications are 
consolidated for a computer program 
and are included in the specification 
packet given to the computer 
programmer 
Since they are developed for one 
process, the logic is easier to 
understand 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-28
Horizontal Balancing 
Horizontal balancing means that all 
output data flow must be either on 
input data flow or described in the 
process logic 
It is used to verify that each process 
has the required data dictionary entries 
defined and the formulas and logic 
necessary to produce the output 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-29
Rules for Horizontal Balancing 
Rules for horizontal balancing are 
All base elements on an output data flow 
must be present on an input data flow 
All derived elements on an output data 
flow must be either 
Present on an input data flow, or 
Created by the process 
Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-30

More Related Content

What's hot

Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
Webx
 
Software Inspection And Defect Management
Software Inspection And Defect ManagementSoftware Inspection And Defect Management
Software Inspection And Defect Management
Ajay K
 

What's hot (20)

Sql(structured query language)
Sql(structured query language)Sql(structured query language)
Sql(structured query language)
 
Databases: Normalisation
Databases: NormalisationDatabases: Normalisation
Databases: Normalisation
 
Requirements Gathering Best Practice Pack
Requirements Gathering Best Practice PackRequirements Gathering Best Practice Pack
Requirements Gathering Best Practice Pack
 
Database systems - Chapter 2
Database systems - Chapter 2Database systems - Chapter 2
Database systems - Chapter 2
 
BUSINESS PROCESS ANALYSIS
BUSINESS PROCESS ANALYSISBUSINESS PROCESS ANALYSIS
BUSINESS PROCESS ANALYSIS
 
Dbms
DbmsDbms
Dbms
 
Databases
DatabasesDatabases
Databases
 
Unified process Model
Unified process ModelUnified process Model
Unified process Model
 
Database design
Database designDatabase design
Database design
 
Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
 
Software requirement engineering
Software requirement engineeringSoftware requirement engineering
Software requirement engineering
 
View of data DBMS
View of data DBMSView of data DBMS
View of data DBMS
 
Oracle Database Sequence
Oracle Database SequenceOracle Database Sequence
Oracle Database Sequence
 
Data mining
Data   miningData   mining
Data mining
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineering
 
Fundamentals of Database Design
Fundamentals of Database DesignFundamentals of Database Design
Fundamentals of Database Design
 
Software Inspection And Defect Management
Software Inspection And Defect ManagementSoftware Inspection And Defect Management
Software Inspection And Defect Management
 
Database abstraction
Database abstractionDatabase abstraction
Database abstraction
 
Database design process
Database design processDatabase design process
Database design process
 
8 Most Effective Requirements Gathering Techniques.
8 Most Effective Requirements Gathering Techniques.8 Most Effective Requirements Gathering Techniques.
8 Most Effective Requirements Gathering Techniques.
 

Similar to Chap11 (20)

Chap10
Chap10Chap10
Chap10
 
Chap01
Chap01Chap01
Chap01
 
Chap17
Chap17Chap17
Chap17
 
Chap01
Chap01Chap01
Chap01
 
Designing database week ix part 1
Designing database week ix part 1Designing database week ix part 1
Designing database week ix part 1
 
Final
FinalFinal
Final
 
Data dictionary
Data dictionaryData dictionary
Data dictionary
 
Chap20
Chap20Chap20
Chap20
 
ORACLE EBS R12 UPGRADE
ORACLE EBS R12 UPGRADEORACLE EBS R12 UPGRADE
ORACLE EBS R12 UPGRADE
 
Chap02
Chap02Chap02
Chap02
 
Chap07
Chap07Chap07
Chap07
 
The Database Environment Chapter 11
The Database Environment Chapter 11The Database Environment Chapter 11
The Database Environment Chapter 11
 
Intro_toDB.ppt
Intro_toDB.pptIntro_toDB.ppt
Intro_toDB.ppt
 
Chapter 12
Chapter 12Chapter 12
Chapter 12
 
Chap09
Chap09Chap09
Chap09
 
Chap04
Chap04Chap04
Chap04
 
Creating Your Data Governance Dashboard
Creating Your Data Governance DashboardCreating Your Data Governance Dashboard
Creating Your Data Governance Dashboard
 
Lecture 18
Lecture 18Lecture 18
Lecture 18
 
Chapter09 logic modeling
Chapter09 logic modelingChapter09 logic modeling
Chapter09 logic modeling
 
The Database Environment Chapter 1
The Database Environment Chapter 1The Database Environment Chapter 1
The Database Environment Chapter 1
 

More from lolanyunyu (13)

Chap22
Chap22Chap22
Chap22
 
Chap21
Chap21Chap21
Chap21
 
Chap19
Chap19Chap19
Chap19
 
Chap18
Chap18Chap18
Chap18
 
Chap16
Chap16Chap16
Chap16
 
Chap15
Chap15Chap15
Chap15
 
Chap14
Chap14Chap14
Chap14
 
Chap13
Chap13Chap13
Chap13
 
Chap12
Chap12Chap12
Chap12
 
Chap08
Chap08Chap08
Chap08
 
Chap06
Chap06Chap06
Chap06
 
Chap05
Chap05Chap05
Chap05
 
Chap03
Chap03Chap03
Chap03
 

Chap11

  • 1. Chapter 11 Describing Process Specifications and Structured Decisions Systems Analysis and Design Kendall and Kendall Fifth Edition
  • 2. Major Topics Process specifications Business rules Structured English Decision tables Decision trees Horizontal balancing Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-2
  • 3. Process Specifications The methods available for documenting and analyzing the logic of structured decisions include structured English, decision tables, and decision trees Process specifications are created for primitive processes and some higher level processes on a data flow diagram They are also called minispecs Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-3
  • 4. Goal of Creating Process Specifications The goals of producing process specifications are Reduce process ambiguity Obtain a precise description of what is accomplished Validate the system design, including data flow diagrams and the data dictionary Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-4
  • 5. Process Specifications Process specifications are not created for Physical input and/or output processes Processes that represent simple data validation Processes for which prewritten code already exists Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-5
  • 6. Process Logic Process descriptions may exist on a form or within a CASE tool repository Process logic may be represented as Structured English A decision table A decision tree A formula Any combination of the above Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-6
  • 7. Business Rules Business rules include the following: 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-7
  • 8. Process Specification Format Process specifications link the process to the DFD and the data dictionary The following information should be entered: The process number, which must match the process ID on the data flow diagram This allows an analyst to work or review any process and easily locate the data flow diagram containing the process Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-8
  • 9. Process Specification Format The process name, the same as displays within the process symbol on the DFD A brief description of what the process accomplishes A list of input and output data flow, using the names found on the data flow diagram Data names used in the formulae or logic should match the data dictionary, for consistency and good communication Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-9
  • 10. Process Specification Format An indication of the type of process, whether it is batch, online or manual All online processes require screen designs All 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-10
  • 11. Process Specification Format A description of the process logic This should state policy and business rules, not computer language pseudocode A reference to further information, such as a structured English description, a decision table or tree depicting the logic List any unresolved issues These form the basis of the questions used for a follow-up interview Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-11
  • 12. Process Specification Example Part 1 Number 1 Name Add Customer Order Description Key and add the Customer Order. The order should be edited for correct information. Customer and Item master files are updated. Input Data Flow Customer Order Form from the Customer Customer Record from data store D1, Customer Master File Item Record from data store D2, Item Master File Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-12
  • 13. Process Specification Example Part 2 Output Data Flow Pending Order to data store D3, Order File Backordered Item Record to the Inventory Control Department Updated Customer and Item records Type of process Online Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-13
  • 14. Conditions and Actions Conditions, condition alternatives, actions, and action rules must be known in order to design systems for structured decisions Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-14
  • 15. Structured English Structured English is based on structured logic Simple English statements such as add, multiply, move, and so on  It is an appropriate technique for analyzing the system when structured decisions are not complex Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-15
  • 16. Steps to Use Structured English The following steps are needed: 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-16
  • 17. Steps to Use Structured English Underline words or phrases used have been defined in a data dictionary to signify that they have a specialized, reserved meaning Be careful when using "and" and "or" Avoid confusion when using logical comparisons such as "greater than" and "greater than or equal to” Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-17
  • 18. Advantages of Structured English Clarifying the logic and relationships found in human languages An effective communication tool, and easy to teach and understand Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-18
  • 19. Data Dictionary and Structured English The data dictionary is a starting point for creating structured English: Sequenced data dictionary entries become simple structured English statements Selection [] entries become IF..THEN...ELSE statements Iteration { } entries become DO WHILE, DO UNTIL, or PERFORM UNTIL structured English statements Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-19
  • 20. Decision Tables Decision tables provide a way to examine, describe, and document decisions using a table They are used to Describe the conditions Identify possible decision alternatives Indicate actions should be performed, and Describe actions Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-20
  • 21. Decision Tables Decision tables help analysts ensure completeness and accuracy Four main problems that can occur in developing decision tables Incompleteness Impossible situations Contradictions Redundancy Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-21
  • 22. 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 Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-22
  • 23. Drawing Decision Trees  First, identify all conditions and actions and the order and timing of these (if they are critical) Second, begin building the tree from left to right while making sure you are complete in listing all possible alternatives before moving over to the right Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-23
  • 24. Decision Tree Advantages Three advantages over a decision table The order of checking conditions and executing actions is immediately noticeable Second, conditions and actions of decision trees are found on some branches but not on others Third, compared to decision tables, decision trees are more readily understood by others in the organization Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-24
  • 25. Selecting a Structured Decision Analysis Technique Use these guidelines: Use structured English when there are many repetitious actions or when communication to end users is important Use decision tables when complex combination of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-25
  • 26. Selecting a Structured Decision Analysis Technique 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) Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-26
  • 27. Parent Process Specifications If a process explodes to a child diagram, the process becomes a control module when the computer program representing the process is written The logic of the process shows the sequence that the child diagram processes must be executed in Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-27
  • 28. Program Process Specification All the process specifications are consolidated for a computer program and are included in the specification packet given to the computer programmer Since they are developed for one process, the logic is easier to understand Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-28
  • 29. Horizontal Balancing Horizontal balancing means that all output data flow must be either on input data flow or described in the process logic It is used to verify that each process has the required data dictionary entries defined and the formulas and logic necessary to produce the output Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-29
  • 30. Rules for Horizontal Balancing Rules for horizontal balancing are All base elements on an output data flow must be present on an input data flow All derived elements on an output data flow must be either Present on an input data flow, or Created by the process Kendall & Kendall Copyright © 2002 by Prentice Hall, Inc. 11-30