CS360

Business Information Systems

Analysis and Modeling
Process Modeling: Data Flow Diagrams

LJ Waguespack, Ph.D. 2017 Unit 04: 1

 Analysis, Modeling and Design
Modeling
the capture of a subset of system characteristics relevant to a
level or understanding or detail

People
Process
Procedures Model
Data Data
Model
Hardware System
Model
Software

LJ Waguespack, Ph.D. 2017 Unit 04: 2

 System Modeling

Data modeling
Entity-Relationship Diagrams (ER, EER)
Process modeling
Modeling how data flows bet ween and is transformed within
business processes
Data Flow Diagrams (DFDs)
Logic modeling
Modeling processing logic and timing of events within processes
Structured English, decision tables, decision trees, state-
transition diagrams and tables

LJ Waguespack, Ph.D. 2017 Unit 04: 3

 Data Flow Diagramming
Process Model Specification Tool by (Gane & Sarson)
focusing on: Data Flow Diagraming
sources of information
• Process Model Specification Tool by
destinations of information
(Gane & Sarson) focusing on:
paths•of sources
information flow
of information
• destinations of information
information
• pathstransforming processes
of information flow
• information
repositories of datatransforming
within theprocesses
system
• repositories of data within the system
INPUT Data
Input
OUTPUT
Output
Information

04: 4 CS360 Business Information Systems Analysis & Modeling Les Waguespack, Ph.D. 2008

LJ Waguespack, Ph.D. 2017 Unit 04: 4

 DFD Symbols Gane & Sarson
External Entity External
originator of data or receiver of information Entity

aka “sources” and “sinks”

Data Store
Data
a repository for data in the system Store

Process
procedure that operates on data Process
#
collecting, sorting, selecting, summarizing,
Process
analyzing, and reporting Name

abstraction level (general vs. detailed)

Data Flow
conduit of data/information bet ween
bet ween external entity and process
bet ween process and data store Data Flow Line

bet ween processes

LJ Waguespack, Ph.D. 2017 Unit 04: 5

 External Entity (sources and sinks)

External origins and

destinations of data
Every source and sink is a Clerk

“black box” from the Student

Internal
Revenue
perspective of the system Service

Cannot access data stores Faculty

Customer
Member
directly without processes General
Manager

They are often organizations,

organizational units,
individuals, or other systems
Name with nouns

LJ Waguespack, Ph.D. 2017 Unit 04: 6

 Processes
Describes the actions
that are taken to
transform, store, or
distribute data Retrieve
Account# Determine
Sale Price
Name with verbs
Can be either
computerized, Calculate Approve
Credit Order
manual, or both Sales
Tax Catalog
Item

For example, Receive

customer order,
Process customer
complaint, Distribute
daily sales order
report
LJ Waguespack, Ph.D. 2017 Unit 04: 7
 Identifying Processes

One way to do this: Analysis of Business Events

External events – an outside stakeholder interfacing with the
system (e.g., customer placing an order; arrival of supplier’s
shipment; sales rep calling customer)
Decision events – human decision is needed to evaluate input from
multiple sources (e.g., hiring decision)
Time-based (temporal) events (daily, weekly, monthly, etc.
actions)
State events (e.g., drop of inventory levels below a certain level
triggers action)

LJ Waguespack, Ph.D. 2017 Unit 04: 8

 Data-Flow

Data that is in motion

Data moving together
Data flow often
consists of several Customer
Payment

components Sell
Receipt
Merchandise
Name with nouns
Data can flow using
various media: paper
forms, conversation,
computer net work,
electronic media

LJ Waguespack, Ph.D. 2017 Unit 04: 9

 Data Stores
Data at rest
Data about people, things, or
events Inventory

E.g., customers, sales Current Stock

Updated Inventory

transactions, discount
percentages, etc. Customer
Payment

Sell

Name with nouns Receipt

Merchandise Customer ID

Various physical storage

media used: databases and Customer
Credit
files on computer disks, filing
Available Credit
Records

cabinets, desk drawers,

notebook (method
irrelevant for logical DFDs)
LJ Waguespack, Ph.D. 2017 Unit 04:10
 DFD’s Bottom Up

Develop system narrative

Identify system actions
List tasks in order
Keep only data
transformations
Identify cohesive tasks
Collect all actions under
these tasks
Draw an Input Process
Output chart for each
cohesive task

LJ Waguespack, Ph.D. 2017 Unit 04:11

 DFD’s Top Down

“What’s the primary task

of the system?”
“What tasks does that
break down into?”
Repeat the decomposition
until the tasks are “trivial”

LJ Waguespack, Ph.D. 2017 Unit 04:12

 Context Diagram
 Shows the entire system as a single process

“A” Data Flow Line Data Flow Line “C”

The
Whole
System
“B” “D”
Data Flow Line Data Flow Line

LJ Waguespack, Ph.D. 2017 Unit 04:13

 Context Diagram (Level zero)

“The context level diagram is intended to identify the

system boundary with regard to its relationship to any
source or sink entities that may interact with it. As
such, the context diagram contains only one process,
labeled with the name of the system and assigned a zero
as its identifier.” (Marakas, 2001, p. 127)
“An overview of an organizational system that shows
the system boundaries, external entities that interact
with the system, and the major information flows
bet ween the entities and the system.” (Hoffer & al, 2002, p. 243)

LJ Waguespack, Ph.D. 2017 Unit 04:14

 Context Diagram
The context diagram depicts the most general view
Overview of system connections to the “outside world”

“A” Data Flow Line Data Flow Line “C”

The ZERO
Whole
System

“B” “D”
Data Flow Line Data Flow Line

LJ Waguespack, Ph.D. 2017 Unit 04:15

 Decomposition “drilling down”

Dividing a system/process
into subsystems/processes Customer
Records
that all perform a well- Cust Inquiry
defined function Customer Cust Request

Mail List Entry Bulk Mail

Service
Several levels of
1
Account

decomposition in a large Level

One
Notification Entry

system (subsystems/ Cust ID Cust ID

Collect
Agency

processes can be further 2

Credit Report

divided into smaller units) Credit

Bureau Assign
Credit
Customer
Bureau Credit
Continues until no sub- Report
Store it
Records

process can logically be

broken any further

LJ Waguespack, Ph.D. 2017 Unit 04:16

 “Telescoping Levels of Abstraction”

LJ Waguespack, Ph.D. 2017 Unit 04:17

 “Balancing” DFD’s

Inputs to and outputs from a process in a data flow

diagram should remain the same when the process is
decomposed
A data flow can be split into component data flows that
are input for different subprocesses, but the content of
the data flow has to remain the same

LJ Waguespack, Ph.D. 2017 Unit 04:18

 Identifier in DFD’s

The context level diagram gets the number 0 (zero)

Level-0 diagram processes are numbered from 1.0 to n.0
(where n = the total number of processes)
In Level-1 diagrams, the processes are numbered with the
number of the Level-0 diagram process that is begin
decomposed and a running number for each of the
processes (E.g., 2.1, 2.2, etc., if the Level-1 represents the
process 2.0 from Level-0)
The data stores are identified with a letter-number
combination; most commonly used letters are S and D
(E.g., S1, S2, etc.)

LJ Waguespack, Ph.D. 2017 Unit 04:19

 DFD Tree

SYSTEM
“Context Diagram Level”

1 2 3 4 5
Process Process Process Process Process Level
Name Name Name Name Name
Zero

2.1 2.2 5.1 5.2 5.3

Level
Process Process Process Process Process
Name Name Name Name Name One

2.2.1 2.2.2 2.2.3

Process Process Process Level
Name Name Name
Two

LJ Waguespack, Ph.D. 2017 Unit 04:20

 DFD Syntax
A: No process can have only outputs

B: No process can have only inputs

C: Processes are named with verbs

D: Data cannot move directly from one data store to

another data store

E: Data cannot move directly from an external source to a

data store (a process is required)

F: Data cannot move directly from a data store to an

external sink (a process is required)

LJ Waguespack, Ph.D. 2017 Unit 04:21

 DFD Syntax . . .

G: A data store is named with a noun

H: Data cannot move directly bet ween t wo external

entities (e.g., from a source to a sink)

I: A source and a sink are named with a noun phrase

J: A data flow is unidirectional

K: A fork means that exactly the same data flow goes to

t wo different destinations

LJ Waguespack, Ph.D. 2017 Unit 04:22

 DFD Syntax . . .

L: A join means that exactly the same data comes from

t wo different locations to the same destination (very
rare)

M: Loops are not permitted

N: A data flow is named with a noun phrase. Several

nouns can be used as part of the same label if several
flows move together as a package

LJ Waguespack, Ph.D. 2017 Unit 04:23

 Shorthand DFD Syntax Rules

External Data Flow Line External

Entity Entity

External Data Flow Line Data

Entity Store

At Least One!!

Process
Data #
Store At Least One!!
Process At Least One!!
At Least One!! Name

LJ Waguespack, Ph.D. 2017 Unit 04:24

 “Logical” vs. “Physical” DFD’s
Logical DFD
Ignores implementation specifics
computer configuration
data storage technology
communication or message passing methods
Focuses on the functions performed by the system
data collection
data to information transformation
information reporting
Physical DFD
Reports/Prescribes implementation specifics
data entry devices
data storage capacities and technologies
net work and data transfer modes and protocols
Describes the information processing “hardware”
processing modes (batch, online, interactive)
user interface details (forms, report media)
connectivity of information processing to user “world”
LJ Waguespack, Ph.D. 2017 Unit 04:25
 Producing DFD’s
Start with “Top-Down” or “Bottom-Up”
Sketch some “system context” ideas
Identify “next level of detail” process steps below the
“previous level”
Define inputs from ones available at previous level
Define any data stores needed to hold “working” data
Define the processes feeding to the previous layer outputs

Repeat steps 2 thru 4 until process blocks are trivial to

describe
CASE and drawing tools can take a lot of the pain out of “reworking” and
polishing any DFD with more than a few processes and more than one level.
That’s why it’s worth learning a CASE tool like Visible Analyst or Enterprise Architect!!

LJ Waguespack, Ph.D. 2017 Unit 04:26

 Guidelines . . .

Identify external entities (source and sinks; sets system

boundary)
Identify inputs and outputs for each entity
Ignore timing considerations -- draw system as if it never
started or will never stop
Iterate and refine -- usually takes at least 3 drafts of
each DFD for each level
Decompose and balance processes until they are highly
cohesive
Try to keep diagrams to 7-12 symbols

LJ Waguespack, Ph.D. 2017 Unit 04:27

 Guidelines . . .

Completeness
Have all components been included and fully described?

Consistency
Bet ween levels

When to stop?
Once you have reached the level of details suitable for primitive
DFDs

LJ Waguespack, Ph.D. 2017 Unit 04:28

 Some Additional DFD Comments

DFDs tend to be relatively unstable

DFDs alone are not enough to describe the requirements at

a sufficient level

Logic modeling tools required to describe the internal logic

of the primitive level DFDs

Some authors have suggested that use cases (a

requirements analysis tool developed for object-oriented
analysis) can be used together with DFDs

For example, utilization of use cases to describe the behavior

within low-level processes

LJ Waguespack, Ph.D. 2017 Unit 04:29