Information System Analysis and

Design

Using Dataflow Diagrams

Learning Objectives
• Comprehend the importance of using logical and physical data
flow diagrams (DFDs) to graphically depict movement for
humans and systems in an organization.
• Create, use, and explode logical DFDs to capture and analyze
the current system through parent and child levels.
• Develop and explode logical DFDs that illustrate the proposed
system.
• Produce physical DFDs based on logical DFDs you have
developed.
• Understand and apply the concept of partitioning of physical
DFDs.

Kendall & Kendall

Copyright © 2014 7-2
Pearson Education
Major Topics
• Data flow diagram symbols
• Data flow diagram levels
• Creating data flow diagrams
• Physical and logical data flow diagrams
• Partitioning
• Event driven modeling
• Communicating using data flow diagrams
Data Flow Diagrams

• DFDs are one of the main methods available

for analyzing data-oriented systems.
• DFDs emphasize the logic underlying the
system.
• The systems analysts can put together a
graphical representation of data movement
through the organization.
Data Flow Diagrams

• Graphically characterize data processes and

flows in a business system
• Depict:
– System inputs
– Processes
– Outputs
Advantages of the Data Flow Diagram
Approach
Four advantages over narrative explanations of
data movement:
– Freedom from committing to the technical
implementation too early.
– Understanding of the interrelationships of systems
and subsystems.
– Communicating current system knowledge to
users.
– Analysis of the proposed system.
Basic Symbols

Four basic symbols are:

– A double square for an external entity--a source or
destination of data.
– An arrow for movement of data from one point to
another.
– A rectangle with rounded corners for the
occurrence of transforming process.
– An open-ended rectangle for a data store.
The Four Basic Symbols Used in Data Flow Diagrams, Their
Meanings, and Examples
(Figure 7.1)
External Entities
• Represent another department, people,
machine or organizations outside of the system
being studied
• A source or destination of data, outside the
boundaries of the system
• Shows the initial source and final recipient of
data and information
• Should be named with a noun, describingCustomer
that
entity
External Entities (Continued)

• External entities may be:

– A person, such as CUSTOMER or STUDENT.
– A company or organization, such as BANK or
SUPPLIER.
– Another department within the company, such as
ORDER FULFILLMENT.
– Another system or subsystem, such as the
INVENTORY CONTROL SYSTEM.
Data Flow
• Shows movement of data from one point to
another
• Data flow shows the data about a person, place, or
thing that moves through the system.
• Names should be a noun that describes the data
moving through the system.
• Arrowhead indicates the flow direction.
New Customer
Process
• Denotes a change in or transformation of data
• Represents work being performed in the system
• Naming convention:
– Assign the name of the whole system when naming a high-
level process
– To name a major subsystem attach the word subsystem to
the name
– Use the form verb for detailed processes
Processes (Continued)

• Represent either: 1
Add New
– A whole system Customer
– A subsystem
– Work being done, an activity
• Names should be in the form verb.
– The exception is a process that represents an
entire system or subsystem.
Data Stores

• Name with a noun, describing the data

• Data stores are usually given a unique
reference number, such as D1, D2, D3.
• Include any data stored, such as:
– A computer file or database.
– A transaction file .
– A set of tables .
– A manual file of records. D1 Customer
Master
Data Store (Continued)
• A depository for data that allows examination,
addition, and retrieval of data
• Represents a:
– Database
– Computerized file
– Filing cabinet
Steps in Developing Data Flow Diagrams

(Figure 7.2)
Developing Data Flow Diagrams

Use the following guidelines:

– Create the context level diagram, including all external
entities and the major data flow to or from them.
– Create Diagram 0 by analyzing the major activities within
the context process.
• Include the external entities and major data stores.
– Create a child diagram for each complex process on
Diagram 0.
Context-Level Data Flow Diagram

• The highest level in a data flow diagram

• It contains only one process, representing the
entire system.
• The process is given the number zero.
• All external entities are shown on the context
diagram as well as major data flow to and
from them.
• The diagram does not contain any data stores.
Basic Rules
• The data flow diagram must have one process
• Must not be any freestanding objects
• A process must have both an input and output data
flow
• A data store must be connected to at least one
process
• External entities should not be connected to one
another
Context Diagram
A context level diagram for an Airline Reservation System

The context level has only

one process representing the
entire system
Drawing level 0

• The explosion of the context diagram.

• May include up to nine processes.
• Each process is numbered.
• Major data stores and all external entities
are included.
Drawing level 0 (Continued)

• Start with the data flow from an entity on

the input side.
• Work backwards from an output data flow.
• Examine the data flow to or from a data
store.
• Analyze a well-defined process.
Note Greater Detail in Diagram 0
(Figure 7.3)
Creating Data Flow Diagrams

Detailed data flow diagrams may be developed

by:
– Making a list of business activities.
– Analyzing what happens to an input data flow
from an external entity.
– Analyzing what is necessary to create an output
data flow to an external entity.
Creating Data Flow Diagrams
Detailed data flow diagrams may be developed
by (continue):
– Examining the data flow to or from a data
store.
– Analyzing a well-defined process for data
requirements and the nature of the
information produced.
– Noting and investigating unclear areas.
Data Flow Diagram Levels

• Data flow diagrams are built in layers.

• The top level is the context level.
• Each process may explode to a lower level.
• The lower level diagram number is the
same as the parent process number.
• Processes that do not create a child
diagram are called primitive/leaf function.
Creating Child Diagrams
• Each process on diagram zero may be exploded to create a
child diagram.
• A child diagram cannot produce output or receive
input that the parent process does not also produce or
receive

• Each process on a lower-level diagram may be exploded to

create another child diagram.
• These diagrams found below Diagram 0 are given the same
number as the parent process.
– Process 3 would explode to Diagram 3.
 3.2 5.2.7
Child Diagrams (Continued) Edit Calculate
Customer Customer
Discount

• Each process is numbered with the parent

diagram number, a period, and a unique child
diagram number.
• Examples are:
– 3.2 on Diagram 3, the child of process 3.
– 5.2.7 on Diagram 5.2, child of process 5.2.
– On Diagram 3, the processes would be numbered
3.1, 3.2, 3.3 and so on.
Child Diagrams (Continued)

• If the parent process has data flow connecting

to a data store, the child diagram may include
the data store as well.
Child Diagrams (Continued)

• An interface data flow is data that are input or

output from a child diagram that matches the
parent diagram data flow.
• Processes that do not create a child diagram
are called primitive processes.
• Logic is written for these processes.
Differences between the Parent Diagram (above) and
the Child Diagram (below) (Figure 7.4)
Data Flow Diagram Errors

• The following conditions are errors that occur

when drawing a data flow diagram:
• A process with only input data flow or only
output data flow from it.
1 2
Add Add
New New
Customer Customer
Checking the Diagrams for Errors (Figure
7.5)
• Forgetting to include a data flow or pointing
an arrow in the wrong direction
Data Flow Diagram Errors (Continued)
• Data stores or external entities are
connected directly to each other, in any
combination.
Customer D1 Customer

Vendor D2 Vendor Master

Data Flow Diagram Errors (Continued)

• Incorrectly labeling data flow or objects

– Examples are:
• Labels omitted from data flow or objects.
• Data flow labeled with a verb.
• Processes labeled with a noun.
Data Flow Diagram Errors (Continued)

• Including more than nine processes on a data

flow diagram
• Omitting data flow from the diagram
• Unbalanced decomposition between a parent
process and a child diagram
– The data flow in and out of a parent process must
be present on the child diagram.
Data Flow Diagrams Error Summary
• Forgetting to include a data flow or pointing
an arrow in the wrong direction
• Connecting data stores and external entities
directly to each other
• Incorrectly labeling processes or data flow
Differences between the Parent Diagram (above) and
the Child Diagram (below) (Figure 7.4)
Logical and Physical Data Flow Diagrams
• Logical
– Focuses on the business and how the business
operates
– Not concerned with how the system will be
constructed
– Describes the business events that take place and the
data required and produced by each event
• Physical
– Shows how the system will be implemented
– Depicts the system
Features Common of Logical and Physical Data
Flow Diagrams (Figure 7.7)
Data Flow Diagram Progression

The progression of creating data flow

diagrams is:
– Create a logical DFD of the current system.
– Next add all the data and processes not in the
current system that must be present in the new
system.
– Finally derive the physical data flow diagram
for the new system.
The Progression of Models from Logical to
Physical
Physical Data Flow Diagram Example
(Figure 7.9)
Logical Data Flow Diagram Example
(Figure 7.9)
Logical Data Flow Diagrams Advantages

Advantages of logical DFDs are:

– Better communication with users.
– More stable systems, since the design is based on
a business framework.
– Better understanding of the business by analysts
– The system will have increased flexibility and be
easier to maintain.
– Elimination of redundancy and easier creation of
the physical model
Developing Physical Data Flow Diagrams
• Clarifying which processes are performed by humans
and which are automated
• Describing processes in more detail
• Sequencing processes that have to be done in a
particular order
• Identifying temporary data stores
• Specifying actual names of files and printouts
• Adding controls to ensure the processes are
done properly
Physical Data Flow Diagrams Contain Many Items Not
Found in Logical Data Flow Diagrams (Figure 7.10)
Logical Data Flow Diagrams

• Logical data flow diagrams show how the

business operates.
• They have processes that would exist
regardless of the type of system implemented.
Physical Data Flow Diagrams

Physical data flow diagrams show how the system

operates or how the new system will be
implemented.
• Physical data flow diagrams include:
– Clarifying which processes are manual and which are
automated.
– Describing processes in greater detail.
– Sequencing processes in the order they must be executed.
Physical Data Flow Diagrams

Physical data flow diagrams include

(continued):
– Temporary data stores and transaction files.
– Specifying actual document and file names.
– Controls to ensure accuracy and completeness.
Event Modeling and Data Flow Diagrams

• An input flow from an external entity is sometimes

called a trigger because it starts the activities of a
process
• Events cause the system to do something and act as
a trigger to the system
• An approach to creating physical data flow diagrams
is to create a data flow diagram fragment for each
unique system event
Event Response Tables

• An event table is used to create a data flow

diagram by analyzing each event and the
data used and produced by the event.
• Every row in an event table represents a
data flow diagram fragment and is used to
create a single process on a data flow
diagram.
An Event Response Table for an Internet
Storefront (Figure 7.12)
Data Flow Diagrams for the First Three Rows of the Internet
Storefront Event Response Table (Figure 7.13)
Use Cases and Data Flow Diagrams

• Each use case defines one activity and its

trigger, input, and output
• Allows the analyst to work with users to
understand the nature of the processes and
activities and then create a single data flow
diagram fragment
Partitioning Data Flow Diagrams

• Partitioning is the process of examining a data

flow diagram and determining how it should be
divided into collections of manual procedures and
computer programs.
• A dashed line is drawn around a process or group
of processes that should be placed in a single
computer program.
Reasons for Partitioning

• Different user groups

• Timing
• Processes may be separated into different
programs for security
• Similar tasks
• Efficiency
• Consistency of data
• Security
Partitioning Websites

• Improves the way humans use the site

• Improves speed of processing
• Ease of maintaining the site
• Keep the transaction secure
Communicating Using Data Flow Diagrams

• Use unexploded data flow diagrams early

when ascertaining information
requirements
• Meaningful labels for all data components
CRUD Matrix
• The acronym CRUD is often used for
– Create
– Read
– Update
– Delete
• These are the activities that must be present in a
system for each master file
• A CRUD matrix is a tool to represent where each of
these processes occurs in a system
CRUD Matrix (Figure 7.11)
CRUD

• Physical data flow diagrams include processes

for adding, reading, updating, and deleting
records.
• CRUD is an acronym for Create, Read, Update,
Delete.
• A CRUD matrix shows which programs or
processes add, read, update, or delete master
file records.
Transaction Files

• Master or transaction database tables or files

are used to link all processes that operate at
different times.
• They are required to store the data from the
process that creates the data to the process
that uses the data.
Summary
• Data flow diagrams
• DFD symbols
• Creating the logical DFD
– Context-level data flow diagram
– Level 0 logical data flow diagram
– Child diagrams
• Creating the physical DFD
– Create from the logical data flow diagram
– Partitioned to facilitate programming
Summary (Continued)

• Partitioning data flow diagrams

– Whether processes are performed by different user
groups
– Processes execute at the same time
– Processes perform similar tasks
– Batch processes can be combined for efficiency of
data
– Processes may be partitioned into different
programs for security reasons