1. IMS9001 - Systems Analysis and Design
Topic 4
PROCESS MODELLING USING DATA FLOW DIAGRAMS;
DETAILED PROCESS DEFINITIONS;
THE DATA DICTIONAARY

2. Logical and physical DFDs
Data flow diagrams may focus on either:
the “physical” view of the system’s processing OR
the “logical” view of the system’s processing

3. Physical DFDs
represent a particular way of implementing the processes and data in a system
they are technology dependent
they show how the processing takes place and how the data is implemented

4. Logical DFDs
represent what a system must do regardless of how it is implemented
they are technology independent
they show what processing, data movements and data storage must occur in a system
they show the essential aspects of a system
physical DFDs help systems analysts become familiar with how a business or system operates
physical DFDs help systems analysts understand and document problems with existing systems
users can relate to physical DFDs more readily because they contain implementation details:
landmarks e.g. people or roles, locations
implementation details can be removed from physical DFDs
logical DFDs allow systems analysts to gain a clear understanding of what a system must achieve
logical DFDs allow systems analysts to concentrate on problem solutions without being influenced by the limitations of particular technologies
constraints on how problem solutions might be implemented can then be considered: alternative implementations can be evaluated
use physical DFDs early in systems analysis to understand how current systems work and the problems associated with them
convert physical DFDs to logical DFDs later in systems analysis to represent the essence of the system: the essential processes and data
add physical implementation details to the logical DFDs towards the end of systems analysis to reflect early design and implementation considerations

5. Using Logical and Physical DFDs
physical DFDs help systems analysts become familiar
with how a business or system operates
physical DFDs help systems analysts understand and
document problems with existing systems
users can relate to physical DFDs more readily because
they contain implementation details:
landmarks e.g. people or roles, actual locations
implementation details can be removed
from physical DFDs

6. Physical to Logical DFDs
use names for data flows and data stores which indicate their content, not their physical form or location
use names for processes that indicate what, not how

7. Physical to Logical DFDs
2.1
checked AZ104 form
AZ104 form
Bill
checks
form
Master File
valid sales order
2.1
sales order
Validate
sales
order
Sales orders

8. received customer order
Physical to Logical
eliminate physical processes that refer to physical activities only and do not transform data
1.1.1
1.1.2
daily mail
delivery
opened mail
1.1.3
mail orders
Retrieve
mail
orders
Open
mail
Register
mail
orders
registered
mail orders
1.1.1
customer order
received customer order
Record
customer
order

9. Physical to Logical
remove any data stores that are implementation dependent
1.1.2
1.1.1
Update
master
file
Validate
trans-
actions
transactions
Transaction file
Master file
1.1.1
Validate
employee
details
employee details
Employees

10. Physical to Logical
avoid arbitrary sequencing
2.1.2
2.1.3 A B
only show this sequence if process B requires data produced by process A

11. consider the implications for processing cycles of
Physical to Logical
consider the implications for processing cycles of
showing data stores
1.1.2
1.1.1
customer invoice
Produce
customer
invoice
Validate
sales
order
sales order
Sales orders OR
1.1.2
1.1.1
Produce
customer
invoice
valid sales order
customer invoice
sales order
Validate
sales
order

12. Example Physical DFD and Logical DFD
an example physical DFD for part of an order processing system
AZ4-order
form
2..1.1
Sorted orders file
2.1.3
checked
order forms
2..1.2
Run the
orders
program
Orders
clerk
Sort into
order
number
reject
Stock file
processed
orders
a logical DFD derived from the physical DFD above
Products
2..1.3
2..1.1
sales orders
valid sales
orders
2..1.2
Complete
sales
orders
Check
sales
orders
Check
stock
available
accepted sales orders
reject
filled sales orders

13. Logical and Physical DFDs
Physical DFDs Logical DFDs
View How processing is What the system does
implemented
Processes Actual sequence Essential sequence
Naming Forms, locations, Underlying data and people/roles activities
Data flows Excess/duplicated data Only essential inputs for implementation and outputs of the needs processes

14. Building a Set of Data Flow Diagrams
originally there were four different types of DFDs
used in a four stage modelling process:
current physical model
build a set of physical DFDs representing
the current system
current logical model
derive a logical equivalent
new logical model
incorporate new system requirements identified
new physical model
add physical implementation details to reflect the
selected implementation option

15. Building a Set of Data Flow Diagrams
disadvantages of the four stage modelling approach:
unnecessary emphasis on detailed modelling
of existing system
inhibits creative problem solving and redesign
preferred approach:
create a set of physical DFDs for the current system
which are detailed enough to understand and grasp
any problems
focus on the essential model of the system, i.e. the
new logical model which identifies what the new
system must do

16. Data Dictionary (Repository)
the data dictionary is a database or repository of information about objects identified during systems development
every object (and each of its components) must have a definition in the data dictionary
the data dictionary is a major source of documentation about the information system

17. Data Dictionary Entries for Components of DFDs
the data dictionary must contain precise definitions of all components of all data flow diagrams:
to fully explain the meaning of the DFDs
to describe the contents of all data flows and data stores
to describe the processing that occurs in primitive processes
to ensure that names and meanings of components are used consistently (a common vocabulary)

18. Data Dictionary Entries
a data dictionary entry must be included for each
data flow
data store
higher level process
primitive process
external agent (source/sink)

19. Data elements each data flow consists of a series of data elements
a data element is a unit of data that cannot be further broken down into meaningful units of data
each data element should also have an entry in the data dictionary
data flows and data stores are made up of data elements

20. Data Elements
a data dictionary entry for a data element should include any aliases (alternative names), a brief description of its meaning, the kinds of values it can take, and the range of values it can have (if appropriate)
E.g. Data element: product code
Alias: product number
Description: identifies a product held in the warehouse
Values: must be a positive integer
Range: between 1000 and 5000

21. Data Flows
a data dictionary entry for a data flow describes the sequence of data elements and data structures in the data flow using the following connectors:
= is equivalent to
+ and
[ ] select one of
{ } iterations of
( ) optional
* comments

22. Example Data Flow Entry
sales order = sales order no. +
sales order date +
customer number +
[account customer
cash customer] +
customer name +
customer address +
(customer telephone no) +
{item no + item desc + item price +
item qty} +
sales order total amount

23. Data Stores a data store is made up of data flows and data elements
where a data store consists of a collection of data flows it is described as repetitions of that data flow
e.g. Data Store: {customer invoice}
data stores may also be described by listing their data elements
e.g customer deposit = account no +
deposit date +
deposit amount +
account balance

24. Describing Processes
each process in higher level DFDs is defined by the DFD that decomposes the process at the next level down:
these are parent processes
each such process should have a data dictionary entry which includes a brief description of the overall nature and purpose of the process

25. Describing Processes example data dictionary entry for a process
Treat patients: Patient consultations are carried out to determine the causes of patients’ illnesses/ medical problems. Further treatment/ follow up is recommended if appropriate. Details of consultations are recorded.
specific process description (minispecs)

26. Describing External Agents
each external agent (source or sink) should have a data dictionary entry which describes its relationship with the system
e.g.
Referring Doctors:
These are doctors who refer their patients to a specialist medical practitioner for treatment. They are usually general practitioners.

27. Building and Maintaining the Data Dictionary
determine standard formats and information content for all types of data dictionary entries
have a standard means of organising and storing the entries in the data dictionary
ensure that all components of the DFDs have entries in the data dictionary and that they are kept up-to-date
cross-referencing of entries in the data dictionary can help to check the completeness and consistency of the DFDs and other types of models

28. Detailed Process Definitions
the processing that occurs within the bottom level (primitive) processes in DFDs needs to be defined
detailed process descriptions are also known as minispecs
detailed process descriptions form part of the data dictionary: they define the contents of primitive processes

29. Detailed Process Definitions
many techniques can be used to define the details of processing:
e.g. narrative text
Structured English
decision tables
decision trees
flow charts

30. Detailed Process Definitions
detailed process descriptions should:
express what the process does (i.e. policy), not how the process is carried out (i.e. procedure)
be in a form that can be easily understood and verified by both users and systems analysts
be in a form that can be easily communicated to all potential stakeholders:
e.g. end-users, systems analysts, managers, system designers, project leaders, programmers

31. Structured English
Structured English is a modified form of English with some major restrictions on vocabulary and structure:
only action (imperative) verbs such as get, put, add, calculate, find, delete are used
only nouns/noun phrases which refer to components of the DFDs should be used, i.e. data flows, data stores, data elements

32. Structured English
sentences consist of action verbs and DFD components
sentences are combined to form process descriptions using the control structures of sequence, condition, and repetition

33. Control Structures Condition uses If... Then...Else or
Select Case Case 1...Case 2...End Case
E.g.
If qty-in-stock is less than minimum-order-qty
Then update stock-reorder indicator
Else do nothing

34. Control Structures e.g. Select Case
CASE 1 qty-in-stock is less than minimum-order-qty
Do update stock-reorder indicator
CASE 2 qty-in-stock is equal to minimum- order-qty
Do nothing
CASE 3 qty-in-stock is greater than minimum- order-qty
End Case

35. Control Structures
Sequence is represented with one sentence following another in sequence:
Add student to class list
Decrease available-places
Calculate class-fee

36. Control Structures Repetition uses Do-Until or Do-While loops: Do
Accept customer-account-details
Calculate daily-interest = daily balance * daily interest rate
Add daily-interest to monthly-interest-due
Until
no more customer-accounts

37. Example Structured English
Accept sales-order
Find customer-details
If customer-details not found
Then reject sales-order
Else
Create sales-order-header
Do while more sales-order-items
find item-details
calculate sales-order-item price =
item price *order-qty
Enddo
Authorise sales-order
Endif

38. Guidelines for Structured English
use indentation to indicate control structures and their scope: assists readability and understanding
avoid more than three levels of nesting: complicated logic can be represented using other techniques
Stuctured English descriptions should illustrate the logic of the processing, not the implementation of the processing

39. Decision Tables
decision tables are useful for describing processes where several different conditions apply and the particular actions that are taken are determined by combinations of the values of the conditions
decision tables are useful where the process logic is complex
decision tables show all the possible choices and the conditions they depend on in a tabular form

40. Decision Tables decision tables have three stubs (four quadrants):
combinations of condition values
conditions
rules
outcomes
for each set
of condition
values
actions

41. Example Decision Table
avg account bal >
$1,000 Y Y Y Y
N N N N
overdraft amount
< $50,000
Y Y N N Y
Y N N
previous paid-out
loan
Y N Y N Y
N Y N
approve
X X
conditional
approval X X
reject X
X X X

42. Decision Trees 15% 10% 12% 7% Determine Customer Discount
decision trees are an alternative graphical representation of a decision situation as a connected series of nodes and branches
local item
15%
wholesale
customer
imported item
10%
local item
12%
retail
customer
imported item 7%
Determine Customer Discount

43. Selecting Techniques for Process Descriptions
Structured English is useful where a process has a sequence of activities and there is no more than three levels of nesting of decisions
decision trees and decision tables are useful where a process involves a decision based on combinations of values of several conditions

44. Selecting Techniques for Process Descriptions
decision trees visually distinguish the decision conditions and their values from the actions:
they show the paths that decisions can follow but soon become cluttered if each condition has several possible values
decision tables are able to show decisions involving many conditions each with many possible values

45. Overview of Process Modelling
several techniques are available for representing the processing within systems
the aim of process modelling in systems analysis is to define the processing that occurs within a system

46. Process Modelling Techniques
models representing:
an overview of the system processing
the structure of the system processing
the flow of data into and out of the processes
the detailed logic of the processes
can be constructed

47. References
HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) Modern Systems Analysis and Design, (4th edition), Pearson Education Inc., Upper Saddle River, New Jersey, USA. Chapters 7, 8
WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapter 8