SOOAD, Unit-II, DFD

Page 1 of 29

USING DATA FLOW DIAGRAMS

STRUCTURED ANALYSIS (SA) is a development method for the analysis of
existing system (manual or automatic) leading to the development of
specifications for a PROPOSED SYSTEM (new or modified system).

DFD, ERD are models prepared in Structured Analysis and Structured Design
(SA/SD) Approach of System Development.

WHAT IS DFD?
It is a graphic tool used to describe and analyze the movement of data through a
system (manual or automated) including the:
o Processes, stores of data and source and destination of data in the system.

DFD graphically characterize data processes and flows in a business system.

Data flow diagrams represent - possible overview of system inputs, processes,

and outputs.

A series of layered data flow diagrams HIGH LEVEL (CONTEXT) to LOW

LEVEL DETAIL (LEVEL-1, LEVEL-2) - to represent and analyze detailed
procedures in the larger system.

DATA

FLOW

APPROACH

TO

HUMAN

REQUIREMENTS

DETERMINATION

SYSTEMS ANALYSTS
attempt to understand the information requirements of users,
conceptualize how data move through the organization,
the processes or transformation that the data undergo, and what the outputs
are.

DFDs provide a graphical representation of data flows and data processes

throughout the organization.

SOOAD, Unit-II, DFD

Page 2 of 29

ADVANTAGES OF THE DATA FLOW APPROACH (or DFD)

4 chief advantages over narrative explanations of the way data move through the
system:
1. Simple notations make it easier for users and business persons to understand
the processes.
2. Communicating current system knowledge to users through data flow
diagram;
3. Freedom from committing to the technical implementation of the system too
early.
4. Context-Level DFD - Helps in understanding of the relationships of
subsystems. Overview of the overall system can be obtained.
5. It permits analysts to isolate areas of interest in the organization so that they
can go deeper and deeper into one area as they gather more and more
information.
DFD SYMBOLS
DFD uses 4 symbols to model the process and data flows in the organization.
DFDs emphasize the processing of data or the transforming of data as they
move through a variety of processes.
Process can be manual or automated processes.

CONVENTIONS USED IN DATA FLOW DIAGRAMS

1. 2 alternative graphical notations are used to draw DFD(both are equally
acceptable)
Yourdon notation and Gane and Sarson notation
Textbook uses Yourdon notation, MS-Visio uses Gane and Sarson notation
2. 4 basic symbols are used

SOOAD, Unit-II, DFD

Page 3 of 29

3. An entire system and numerous subsystems can be depicted graphically with

these four symbols in combination.

Symbol

Meaning

Example

Entity
Customer

(End

user,

external

system, external database)

Sales executive, Manager,
Admin.

Data flow
Order info

Process

Data store

Add
Order

Order Master

SOOAD, Unit-II, DFD

Page 4 of 29

Example: DFD for Student Registration in University

DFD Naming Guidelines

External Entity Noun
E.g. Customer, Employee, PaymentGateway, Admin, Manager

Data Flow Names of data

Process verb phrase
a system name (Context Level DFD)
a subsystem name (First Level DFD)
Data Store Noun

ENTITY is used to depict an external entity or entity (another department, a

business, a person, or a machine) that can send data to or receive data from the system.
Although it interacts with the system, it is considered as outside the
boundaries of the system.

SOOAD, Unit-II, DFD

Page 5 of 29

DATA-FLOW (THE ARROW)

shows movement of data from one point to another, with the head of the arrow
pointing toward the data's destination.

Naming convention: Because an arrow represents data about a person, place,

or thing, it too should be described with a noun.

E.g. new order information data flowing from Customer to the Online
Shopping System.

PROCESS (RECTANGLE WITH ROUNDED CORNERS)

Process denotes a change in or transformation of data (processing of data) in

the system.

Processes represent work being performed in the system and should be named
using one of the following formats.

Naming convention:
1. Context level DFD: Assign the name of the whole system when naming a highlevel process. An example is INVENTORY MGT. SYSTEM.
2. First level DFD: To name a major subsystem, use a name such as
COPIS system Manage Login, Manage Customer, Manage Order, Generate
Invoice, Manage Shipping, Generate MIS Report
Email Application Manage Login, View Email, Send Email, Manage
Address Book, Manage Emails in Folders
3. Detailed processes: Process name must be a verb.
The verb describes the type of activity, such as ADD ORDER, PRINT ORDER,
or UPDATE ORDER, GENERATE INVOICE, LIST INVOICES, VIEW
CUSTOMER REPORT, PRINT SALES REPORT

SOOAD, Unit-II, DFD

Every process should have Unique Number

Page 6 of 29

A process must also be given a unique identifying number indicating its level in
the diagram.
DATA STORE (open-ended rectangle)

Represents a repository of data that allows examination, addition, and retrieval

of data

The data store may represent a manual store, such as a filing cabinet, or a computerized file or database.

Naming convention: data store name must be NOUN

E.g. StudentFile, OrderInfo, BillingData, EmployeeTimeInFile

STEPS FOR DEVELOPING DATA FLOW DIAGRAMS

Following steps are involved in developing data flow diagrams using a topdown approach.
1. Identify the activities, flow OR business processes. From the business process
description, create a list with the 4 categories of:
1. external entity,
2. data flow,
3. processes, and
4. Data store
2. Create a CONTEXT DIAGRAM that shows external entities and data flow to
and from the system.

SOOAD, Unit-II, DFD

Page 7 of 29

3. Draw the first level DFD (Level-1 DFD) showing all the subsystems of the
proposed system as processes.
4. Create a child diagram (DFD level 2) for each of the processes in first level
DFD.
CREATING THE CONTEXT DIAGRAM (DFD LEVEL 0)

The highest level view of a system. This only has one process which
represents the overall system and has no data stores as all the data is
stored within the process.

Context diagram specifies the systems boundary, scope and interaction with
external systems and all end-users.

External entities (end users: who are source of data and destination of data) and
the data flow to and from them are shown.

Context Level DFD for Restaurant Food Ordering System

Level 0 Context diagram

CUSTOMER

KITCHEN

0
Customer Order

Food
ordering
system

Receipt
Management
Reports
RESTAURANT
MANAGER

Food Order

SOOAD, Unit-II, DFD

Page 8 of 29

Exercise 1: Draw the Context DFD for Email Application

Exercise 2: Draw the Context DFD for Online Exam System
Student, Faculty, Admin users
Data Flows from Faculty to System: Course Detail, Questions and their marks
Data Flows from System to Faculty: Student Result Report of Exam
Data Flows from System to Student: Exam, Question, Exam Result
Data Flows from Student to System: Answers

Data Flows from Admin to System: Exam Details, Exam Students info
Data Flows from System to Admin: Exam Result Report
Exercise 2: Draw the Context DFD for Library Mgt. System
Student, Faculty, Librarian

SOOAD, Unit-II, DFD

Page 9 of 29

CONTEXT LEVEL DFD (VIDEO RENTAL SYSTEM)

SOOAD, Unit-II, DFD

Page 10 of 29

DRAWING DFD LEVEL-1 DIAGRAM

System is exploded into all the subsystems of the system (shown as
processes in Level 1 DFD).
Inputs and outputs specified in the first diagram remain constant in all
subsequent diagrams.
In DFD high level processes are exploded into sub-processes,
hence DFD is called as functional decomposition diagram.
Each process is numbered with an integer like 1, 2, 3, 4 upto 9. The major
data stores of the system (representing master files) and all external entities
are included on Level 1 DFD.
DFD for Customer Order Processing and Invoicing System

New customer

Order

Customer

Invoice

Order
System

Ship
Statement

LEVEL-1 DFD OF COPIS

Picking Slip
Order

Warehouse

SOOAD, Unit-II, DFD

Page 11 of 29

Order System

New
info

New customer

D Customer
1 Master

Add
Customer

Customer

Order

Cust Info
Process
Customer
Order

Pending
Order

Backorder

D Back
3 Order

Proc
Info
D Inventory
2 Master

3
Warehouse
Picking
Slip
Produced

Packing
slip

Warehouse

Order
Picked

4
Ship statement
Ship N/A

D Customer
1 Master
Bill N/A
Bill Info

Shipping
Prepare

Customer

Shipping B/O info

5

Cust Bill

Customer
Bill
Produce

CREATING CHILD DIAGRAMS (MORE DETAILED LEVELS)

(LEVEL-2, LEVEL-3)
Each process on Level-1 may in turn be exploded to create a more detailed
child diagram.
The process on Level-1 DFD that is exploded is called the parent process,
and the diagram that results is called the child diagram.
RULE: The primary rule for creating child diagrams (vertical balancing)
dictates that:
Child diagram cannot produce output or receive input that the parent process
does not also produce or receive. All data flow into or out of the parent
process must be shown flowing into or out of the child diagram.

SOOAD, Unit-II, DFD

Page 12 of 29

LEVEL-2 DFD for 2.0 Process Customer Order

Order System
2.1
Customer

D Customer
1 Master

Order
Need to
establish

Verify
Customer

Valid
2.2
Customer

Order
Notify

Verify
Item

D Inventory
2 Master

Update
2.4

Avail

Valid
Item

Update
Commit

2.3
Check
Available

Back
Order
D Back
3 Order

D Shipping
4 Taxes
Tax
2.5
Create
Order

Ord D Inventory
2 Master
Pending Order

WHAT LEVEL OF DETAILS TO EXPLODE PROCESSES?

Generally, upto level-2 DFD is sufficient.
Processes may or may not be exploded, depending on their level of complexity.
When a process is not exploded, it is said to be functionally primitive and is
called a primitive process.
Logic is written to describe these processes (PSPECS and structured decisions).

SOOAD, Unit-II, DFD

Page 13 of 29

CONTEXT LEVEL DFD (VIDEO LIBRARY SYSTEM)

SOOAD, Unit-II, DFD

Page 14 of 29

LEVEL 1 DFD (DIAGRAM 0) OF VIDEO RENTAL SYSTEM

SOOAD, Unit-II, DFD

Page 15 of 29

TYPES OF DFD - LOGICAL AND PHYSICAL DATA FLOW DIAGRAMS

LOGICAL DFD
The transformation of data from input to output may be described logically and
independently of the physical components (like computers, file cabinets, disk
units and people, departments). They are termed logical data flow diagrams.
PHYSICAL DFD
There are physical data flow diagrams which show the actual implementation
and the movement of data between people, departments and work stations.
E.g. they use actual device names, dept. names and people names.
Physical DFDs are the implementation-dependent view of the current system
showing MANUAL PROCESSES, what tasks are carried out,
who carries them out , where and how.
E.g. Customer Master file, VideoRentalTransactionFile,
E.g. In Video CD Rental System
Identify CD (Logical Process)
Scanned CD ID by bar code reader (Physical Manual process)
E.g. Who prepares invoice in which department, how is it done, in how many
copies and where does he / she send it or in which file it is filed
Contents of Physical DFD:
Manual processes
actual file names used to store data (manual files in cabinets)
actual person names and department names
intermediate data storage.

SOOAD, Unit-II, DFD

Page 16 of 29

Example: Logical and Physical DFD for Billing

DIFFERENCE BETWEEN LOGICAL DFD AND PHYSICAL DFD

LOGICAL DFD
More abstract view of system

PHYSICAL DFD
Less abstract (more detail) view of system

Represent logical features of a system Represents the actual physical business

E.g

applying

for

video

store process

with

actual

devices

and

membership card, checking out a procedures.

DVD, returning the DVD are logical E.g. applying for video store membership
process that would occur whether card, customer filling registration form
store had an manual, automated or on paper and giving to clerk for data

SOOAD, Unit-II, DFD

hybrid system.

Page 17 of 29

entry.

Data stores represent logical data Data stores contain physical files and
names (collections of data)

manual files.

Do not specify master file or E.g. Customer Master file,

transaction file

VideoRentalTransaction File,

E.g. Customer Info.

Video CD Rented Details.
Does not clarifies which processes Clarifying the same
are manual and which are automated

E.g. Collect money and give receipt

E.g. Settle transaction and issue (Manual)

receipt
Does not include temporary data Includes them
stores

E.g. Temp. Trans file

Does not specify actual names of Specifies them

files, printouts and actual devices
used

SOOAD, Unit-II, DFD

Page 18 of 29

DATA DICTIONARY
After successive levels of data flow diagrams are complete, systems analysts
use them to help catalog the data processes, flows and data stores.
Of particular importance are data items in data-oriented applications.
THE DATA DICTIONARY
It is a catalog metadata (storage area) of the elements (data flows,
data stores, processes) in a system.
Definitions of all elements in the system data flows, data
stores,processes are described in detail in a data dictionary.
DATA DICTIONARY = entities + data stores + data flow + processes

MAIN USE:
1) helps in centralized and consistent storage of data (with cross-referencing) used
in different places like ERD, DFD and screen design.
CASE tools enforce cross-referencing and consistency.
E.g CASE tools like WinA&D, Visible Analyst help in automated data dictionary
creation from ERD and DFD.
WHY IS A DATA DICTIONARY IMPORTANT? (OR WHAT ARE ITS
USES?)

1) To manage data details in large systems. Clearly, automated data

dictionaries (CASE tools) become important for large systems that produce
several thousand data elements.
2) To maintain the cross-referencing and consistency of the data. Same
common meaning of data which is used at multiple places. (ERD, DFD,
screen layouts)

SOOAD, Unit-II, DFD

Page 19 of 29

3) To communicate a common meaning for all system elements (used at

different places)
4) Determine the contents of data stored in files.
5) Provide a starting point for developing screens and reports.

EXAMPLE:
To illustrate how data dictionary entries are created, we use an example for
Shopping Store (World's Trend Catalog Division).
This company sells clothing and other items by mail order or using a toll-free
phone order system (or faxing the mail order form), and via the Internet using
customized Web forms.

First, you need to capture and store the name, address, and telephone
number of the person placing the order.

SOOAD, Unit-II, DFD

Page 20 of 29

Then you need to address the details of the order: the item description, size,
color, price, quantity, and so on.
The customer's method of payment must also be determined.

DATA FLOW DESCRIPTION FOR ADD CUSTOMER ORDER FORM

ID: 2.1
Name: Customer Order
Description: contains customer order information and is used to update the
customer master and item files and to produce an order record.
Source: Customer

Destination: Process Order

Type of Data Flow

File

Screen

Report

Form

Internal
Data structure traveling with the flow: Order Information
Volume/Time: 10/hour
Comments: Order may be received by mail, FAX, or by customer telephoning the
order directly.
DESCRIBING DATA STRUCTURES
Examples of data structure: Order (for adding customer order at Shopping
Store):
Customer Order = customer number + customer name + address + telephone +
catalog no + order date + (available order items) + merchandise total + (tax) +
shipping and handling + order total + method of payment + (credit card type) +
(credit card number) + (expiry date)
structural records = collection of data elements

SOOAD, Unit-II, DFD

Page 21 of 29

Customer Name = first name + (middle name) + last name

address = street + (apartment) + city + state + zip + (country)
Telephone = area code + local number
Method of payment = [Cheque | cash | credit card]
Credit card type = [Master | visa | American Express]

Table Name : AccountMaster Name : ACCOUNT_MASTER

Purpose: Account Master will store the basic information of any supplier.
SR.NO.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

FIELD NAME

DATA TYPE
(SIZE)
ID
Integer
NAME
Varchar(30)
CONTACT_PERSON Varchar(30)
PHONE1
Varchar(12)
PHONE2
Varchar(12)
FAX
Varchar(12)
EMAIL
Varchar(50)
WEBSITE
Varchar(35)
ADDRESS1
Varchar(50)
ADDRESS2
Varchar(50)
CITY_ID
Integer
STATE_ID
Integer
COUNTRY_ID
Integer

CONSTRAINTS

DESCRIPTION

P.K.
Not Null, Unique

Not Null
F.K., Not Null
F.K., Not Null
F.K., Not Null

References City_Master
References State_Master
References
Country_Master

SOOAD, Unit-II, DFD

DESCRIBING

Page 22 of 29

PROCESS

SPECIFICATIONS

AND

STRUCTURED

DECISIONS
o Low level DFD processes such as ADD CUSTOMER and RENT VIDEO DVD
but you did not explain the logic necessary to execute these tasks.
o These specifications explain the decision-making logic and formulas that will
transform process input data into output.
o 3 ways to create PSPECS
o The methods available for documenting and analyzing the logic of decisions
include
1) Structured English, 2) Decision tables, and 3) Decision trees
o It is important to be able to recognize logic and structured decisions that occur
in a business

PROCESS SPECIFICATION FORMAT

Process specifications link the process to the data flow diagram, and hence
the data dictionary.

SOOAD, Unit-II, DFD

Page 23 of 29

STRUCTURED ENGLISH (PSEUDO CODE)

It is the Pseudo code explaining logic of the actual C Program

Structured English aims at getting the benefits of both the

programming logic and natural language.
It is used when structured decisions are not complex.
As the name implies, structured English is based on
(1) structured logic, or instructions organized into nested and grouped proce
dures, and
(2) Simple English statements such as add, multiply, and move.

Structured English or "pseudocode" consists of the following elements:

1. Operation statements written as English phrases executed from the
top down
2. Conditional blocks indicated by keywords such as IF, THEN, and
ELSE
3. Repetition blocks indicated by keywords such as DO, WHILE, and
UNTIL

Example of Structured English

IF customer has a Bank Account THEN
IF Customer has no dues from previous account THEN
Allow loan facility
ELSE
IF Management Approval is obtained THEN
Allow loan facility
ELSE
Reject
ENDIF
ENDIF
ELSE
Reject
ENDIF

SOOAD, Unit-II, DFD

Page 24 of 29

DECISION TABLES
A decision table is a matrix of rows and columns that shows CONDITIONS
AND ACTIONS. Decision tables have decision rules. They state what
procedure to follow when certain conditions exist.
WHEN TO USE: When there are large number of conditions and actions to be
taken (based on different permutation and combinations of conditions)
Decision Rules
Conditions

Condition Alternatives

Actions

Action Entries

Example: Departmental store policy on non-cash customer purchases,

Decision table shows the non-cash purchase approval actions for
department store

RULES
Conditions and Actions

Under $50

Pays by check with 2 forms of ID

Uses credit card

Complete the sale after verifying signature X

Complete the sale. No signature needed.
Call supervisor for approval.
Communicate electronically with bank for
credit card transaction.

X
X
X

SOOAD, Unit-II, DFD

Page 25 of 29

A Decision Table Example (to give Discount to Customers by Company)

In this example a company is trying to maintain a meaningful mailing list of
customers. The objective is to send out only the catalogs from which customers
will buy merchandise.
Condition:
Time : in which customer pays,
Business volume means Amt. of purchase done by the Customer
Conditions

Decision Rules
1

Time

<10 days <10 days

<10 days >10 days >10 days

>10 days

Business

>10000

<5000

<5000

Volume

Between

>10000

5 & 10K

Between
5 & 10K

ACTION
3 % Disc

2 % Disc
No Disc

X
X

DECISION TREES
a) Decision trees are used when complex branching occurs in a structured
decision process and multiple decisions in a particular sequence.
b) Decision Tree is a diagram that presents conditions and actions
sequentially thus shows which condition to consider first , which
second and so on.
c) Decision trees are most often drawn on their side, with the root of the tree
on the left side of the paper; from there, the tree branches out to the right.
d) USE: trees are used mainly for identifying and organizing conditions and
actions in a completely structured decision process.

SOOAD, Unit-II, DFD

Page 26 of 29

Example:
Sales payment approval Logic

cheque

under $50

Complete sale after verifying signature

Credit card
Complete sale. No signature needed

cheque

Call supervisor for approval

>= $50

Credit card

Communicate with bank for electronic transaction

SOOAD, Unit-II, DFD

Page 27 of 29

CHOOSING A STRUCTURED DECISION ANALYSIS TECHNIQUE

The following guidelines provide you with a way to choose one of the three
techniques for a particular case:
a. Use structured English when
1. There are many repetitious actions,
OR
2. Communication to end users is important.
b. Use decision tables when
1. Complex combinations of conditions, actions, and rules are found,
OR
2. You require a method that effectively avoids impossible situations,
redundancies, and contradictions.
5. Use decision trees when
a. The sequence of conditions and sub-conditions goes to N levels,

SOOAD, Unit-II, DFD

Page 28 of 29

DFD Example
Hospital Management System

Context Level DFD

Admin

User Info.,
Access Info.,
Floor,Ward,Room,Bed - Status Info.,
Patient Info.,
MIS Reports

Entry User Details,

Entry Floor,Ward,Room,Bed Details,
System Access Details,

Login Details,
Message Details

Doctor

Patients Info.,
Reply Message Info.

Bed Approval Status,

Message Info.

ADT Module of
Hospital
Management
System

Nurse

Message (Bed Transfer Request) Details,

Login Details
Patient Registration Details,
Case(AS or IPD) Details,
Patient Bed-Allotment Details,
Discharge Details,
Bed Approval Status ,
Login Details

Patient Registration Info.,

Message Info.
Floor,Ward,Room,Bed - Status Info.

Operator

SOOAD, Unit-II, DFD

Page 29 of 29

First Level DFD

User
Admin

Login Details

Login Login
Details Info.

Verification Status
Login Details

Operator

Verification
Status
Role Info.
Role Details

Verification Status

1.0
Authenticate
User

Login Details

Employee,
Doctor Details

Nurse

Verification
Status
Role Details

2.0
Manage Role

Role
Role Info.

Doctor

Doctor Info.
Employee,
Doctor Info.

Doctor

Login Details

3.0
Manage Staff

Doctor Details
Employee Details

Employee

Employee Info.
Ward Info.
Ward Details
Ward Info.

Floor

4.0
Manage Ward

Ward Details

Patient
Registration
Details

5.0
Register &
Discharge
Patient

Floor No.

Message

6.0
Manage
Bed-Allotment

Room

Bed Allocation
Status.

Bed No.

Approval Reply

Message Info.
Request for Reports
Reports

Message

Ward No.

Message Details

Message Info.
Approval Request

Patient

Patients Details
Patients Info.

Room No.

Patient Bed Allocation

Status
(Floor,Ward,Room) No..

Ward

Ward Info.

Floor Info.

Patient Info.

Request
Approval
Message

Bed
Allocation
Bed
Approval
Details

7.0
Communicate
Users

8.0
Generate
Reports

Message

Bed Allocation Info.

Patients Info.
Ward Info.