Chapter 2: Modeling Tools for System Analyst
Data Flow Diagrams (DFDs)
DFD is a picture of the movement of data between external entities and the processes and data stores
within a system. It is s a process model used to depict the flow of data through a system and the work or
processing performed by the system. Synonyms are bubble chart, transformation graph, and process
model. Is a graphical tool that depicts the flow of data in an information systems, the relationship among
the data flows and how data come to be stored at specific location.DFD Represents the functions or
processes which capture, manipulate, store and distribute data between a system and its environment and
between components within a system.
Elements of a DFD

Process: An activity or function performed for a specific business reason. Manual or computerized

Data flow: A single piece of data or a logical collection of data. Always starts or ends at a process

Data Store: A collection of data that is stored in some way. Data flowing out is retrieved from the
data store. Data flowing in updates or is added to the data store

External entity: A person, organization, or system that is external to the system but interacts with
it.
DFD Symbols
(Gane & Sarson Sysmbol)
Rules for creating DFD
1 Information System Design
1
3
4
5
All processes should have unique names. If two data flow lines (or data stores) have the same label, they
should both refer to the exact same data flow (or data store).
The inputs to a process should differ from the outputs of a process.
Any single DFD should not have more than about seven processes.
No process can have only outputs. (This would imply that the process is making information from
nothing.) If an object has only outputs, then it must be a source.
Correct
Incorrect
No process can have only inputs. (This is referred to as a “black hole”.) If an object has only inputs, then it
must be a sink.
Incorrect
Correct
6
7
A process has a verb phrase label.
Data cannot move directly from one data store to another data store. Data must be moved by a process.
8
Correct
Incorrect
Data cannot move directly from an outside source to a data store. Data must be moved by a process that
receives data from the source and places the data in the data store.
9
Correct
Incorrect
Data cannot move directly to an outside sink from a data store. Data must be moved by a process.
Correct
Incorrect
10 A data store has a noun phrase label.
11 Data cannot move directly from a source to a sink. It must be moved by a process if the data are of any
concern to the system. If data flows directly from a source to a sink (and does not involved processing)
then it is outside the scope of the system and is not shown on the system data flow diagram DFD.
2 Information System Design
Correct
Incorrect
12 A source/sink has a noun phrase label.
13 A data flow has only one direction between symbols. It may flow in both directions between a process and
a data store to show a read before an update. To effectively show a read before an update, draw two
separate arrows because the two steps (reading and updating) occur at separate times.
Correct
Incorrect
14 A fork in a data flow means that exactly the same data goes from a common location to two or more
different processes, data stores, or sources/sinks. (This usually indicates different copies of the same data
going to different locations.)
Correct
Incorrect
15 A join in a data flow means that exactly the same data comes from any of two or more different processes,
data stores, or sources/sinks, to a common location.
Incorrect
Correct
16 A data flow cannot go directly back to the same process it leaves. There must be at least one other process
that handles the data flow, produces some other data flow, and returns the original data flow to the
originating process.
Incorrect
Correct
17 A data flow to a data store means update (i.e., delete, add, or change).
18 A data flow from a data store means retrieve or use.
19 A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single arrow as
long as all of the flows on the same arrow move together as one package.
3 Information System Design
Context Diagram
It represents the system with a single process and then shows the external agents with the system
interacts. It shows the top-level view of System. Context diagrams show the system boundaries, external
entities that interact with the system, and major information flows between entities and the system. It’s a
first DFD in every business process, which shows the context into which the business process fits. In
Context diagram the overall business process is shown as just one process (process 0), Shows all the
external entities that receive information from or contribute information to the system.
Context Diagram is an overview of an organizational system that shows:




The system boundaries;
External entities that interact with the system;
Major information flows between the entities and the system.
Note: only one process symbol, and no data stores shown.
Fig: Context Diagram for Food Ordering System in Restaurent
Level 1 diagram:
Level 1 Diagram is a data flow diagram that represents a system’s major processes, data flows, and data
stores at a high level of detail.¨Processes are labeled 1.0, 2.0, etc. These will be decomposed into more
primitive (lower level) DFDs
4 Information System Design
Fig: Level 1 Diagram for Food Ordering System
Level 2 Diagram:
Level 2 DFD shows the sub processes of one of the processes in the Level 1 DFD
Fig: Level 2 DFD diagram for process 4.0.
5 Information System Design
Processes are labeled 4.1, 4.2, etc. These can be further decomposed in more primitive (lower
level) DFDs if necessary.
Decomposition of DFD
Functional decomposition is an iterative process of breaking a system description down into
finer and finer detail.


Creates a set of charts in which one process on a given chart is explained in greater detail
on another chart.
Continues until no sub process can logically be broken down any further.
Primitive DFD is the lowest level of a DFD.


Level1 diagram results from decomposition of Level 0 diagram.
Level n diagram is a DFD diagram that is the result of a n nested decompositions from a
process on a level 0 diagram.
Balancing DFDs



Conservation Principle: conserve inputs and outputs to a process at the next level of
decomposition.
Balancing: conservation of inputs and outputs to a data flow diagram process when that
process is decomposed to a lower level.
Balanced means:
o Number of inputs to lower level DFD equals number of inputs to associated
process of higher level DFD
o Number of outputs to lower level DFD equals number of outputs to associated
process of higher level DFD
6 Information System Design
This is unbalanced because the process of the context diagram has only one input but the
Level 1 diagram has two inputs.
Four Different Types of DFDs
1. Current Physical
o Process labels identify technology (people or systems) used to process the data.
o Data flows and data stores identify actual name of the physical media.
2. Current Logical
o Physical aspects of system are removed as much as possible.
o Current system is reduced to data and processes that transform them.
3. New Logical
o Includes additional functions.
o Obsolete functions are removed.
o Inefficient data flows are reorganized.
4. New Physical
o Represents the physical implementation of the new system.
Guidelines for Drawing DFDs:
a. Completeness:
o DFD must include all components necessary for system.
o Each component must be fully described in the project dictionary or CASE
repository.
b. Consistency
o The extent to which information contained on one level of a set of nested DFDs is
also included on other levels.
7 Information System Design
c. Timing
o Time is not represented well on DFDs.
o Best to draw DFDs as if the system has never started and will never stop.
d. Iterative Development
o Analyst should expect to redraw diagram several times before reaching the closest
approximation to the system being modeled.
e. Primitive DFDs
o Lowest logical level of decomposition.
o Decision has to be made when to stop decomposition.
f. Rules for stopping decomposition
o When each process has been reduced to a single decision, calculation or database
operation.
o When each data store represents data about a single entity.
o When the system user does not care to see any more detail.
o When every data flow does not need to be split further to show that data are
handled in various ways.
o When you believe that you have shown each business form or transaction, online
display and report as a single data flow.
o When you believe that there is a separate process for each choice on all lowest
level menu options.
Hint for Drawing DFD
a.
b.
c.
d.
e.
f.
g.
Avoid details initially
Identify external entities which provides the boundary
Indentify main process ,then connecting data flows
Ensure enough dataflow goes into a process to perform transformation
You can Duplicate external entities and data store to improve clarity of diagrams
Use meaningful names
Be prepared to modify and redraw
Case study:
The existing system is any medical shop is entirely manual. The shop gets its products from dealer who in
turn may produce them from a higher level dealer or directly from the manufacturer. It keeps track of all
available medicines. When a customer approaches for a particular medicine, the stock is checked to verify
the availability of the product and it is available, then it is supplied to the who is billed for it.
8 Information System Design
The system suffers from all the drawbacks that a manual system suffers i.e it is highly employee
dependent. Right from the
products from the dealers to selling it to the customer and other
administrative functions are performed manually. Accounting and billing is also manual . Manual
inventory suffers from the drawbacks that the shopkeeper has to track of the status of the stock of many
products order It if stock diminished .
An automated system would eliminate the above drawbacks. Apart from computerizing all the manual
task that are performed in the shop, it can also keep a track of the inventories and when the stock of a
particular product reaches below a predetermined level. It can alert some person or even automatically
order it in a requisite quantity.
1.Construct Context Diagram and level 1 DFD
2.Construct level 2 DFD for one key process
1. Context Diagram(Whole System- Only One Process)
Level 1 DFD(Divided into High level Key Processes)
9 Information System Design
Level 2 DFD (Different DFD’s for different processes)
for Process no 2(Payment Process)
1. Customer Payment(Billing)
2. Dealer Payment(Billing)
3. Verification of Dealer Payment(Invoice Verification)
Note: In Level 2 or higher level DFD generally Entities and Data Store are not represented.
Two arrows with same name should consider one input or output while balancing DFD.
10 I n f o r m a t i o n S y s t e m D e s i g n
Case study 2:
Precision Tools sells a line of high-quality woodworking tools. When customers place orders on the
company’s Web site, the system checks to see if the items are in stock, issues a status message to the
customer, and generates a shipping order to the warehouse, which fills the order. When the order is
shipped, the customer is billed. The system also produces various reports.
1.
Draw a context diagram for the order system
2. Draw DFD diagram 1 for the order system
Ans:
Context Diagram:
11 I n f o r m a t i o n S y s t e m D e s i g n
Order
CUSTOMER
WAREHOUSE
In-Stock
Request
Payment
0
Status
Message
Shipping
Order
Order
System
Invoice
Shipping Confirmation
Inventory
Reports
ACCOUNTING
Level 1 DFD:
Order
In-Stock Request
CUSTOMER
WAREHOUSE
1.0
Status
Message
Order
Data
2.0
Shipping
Confirmation
Shipping
Order
Check
Status
Status Data
D1
Issue
Status
Messages
3.0
Pending
Orders
Generate
Shipping
Order
Order Data
Payment
4.0
Order Data
Invoice
Manage
Accounts
Receivable
5.0
Accounting Data
D2
Accounts Receivable Data
Produce
Reports
Accounts
Receivable
Inventory
Reports
ACCOUNTING
12 I n f o r m a t i o n S y s t e m D e s i g n
Modeling with Entity Relationship(E-R) Diagram
Conceptual data modeling:
A detailed model that captures the overall structure of data in an organization. Independent of any
database management system (DBMS) or other implementation considerations.
Outcome of Conceptual Data modeling
o
Primary deliverable of Conceptual data modeling is an entity relationship (ER) diagram
or class diagram.
o Second deliverable is a set of entries about data objects to be stored in repository or
project dictionary.
 Repository links data, process, and logic models of an information system.
 Data elements included in the DFD must appear in the data model and vice versa.
 Each data store in a process model must relate to business objects represented in
the data model.
The Conceptual Data Modeling Process
o
o
o
o
Develop a data model for the current system.
Develop a new conceptual data model that includes all requirements of the new system.
In the design stage, the conceptual data model is translated into a physical design.
Project repository links all design and data modeling steps performed during SDLC.
Introduction to Entity Relationship (ER) Modeling
Entity Relationship data model (ER model):
A detailed, logical representation of the entities, associations and data elements for an organization or
business area.
Entity Relationship diagram (ER diagram):
A graphical representation of an ER model. It is a detailed logical representation of data for an
organization and uses three main constructs.
The ER model is expressed in terms of:
o
o
o
Data entities in the business environment.
Relationships or associations among those entities.
Attributes or properties of both the entities and their relationships.
Entity:
13 I n f o r m a t i o n S y s t e m D e s i g n
A person, place, object, event or concept in the user environment about which data is to be maintained.
Entity is a fundamental thing about which data may be maintained. Each entity has its own identity.
Entity type: Is a collection of entities that share common properties or characteristics.
Entity instance: single occurrence of an entity type.
Consider an insurance company that offers both home and automobile insurance policies .These policies
are offered to individuals and businesses.
Attributes:
A named property or characteristic of an entity that is of interest to the organization. Naming an
attribute: e.g Vehicle_ID. Place its name inside the rectangle for associated entity in the ER diagram.
An attribute name is a noun and should be unique. To make an attribute name unique and for clarity,
each attribute name should follow a standard format.Similar attributes of different entity types should use
similar but distinguishing names.
Relationships:
An association between the instances of one or more entity types that is of interest to the organization.
A relationship is a reason for associating two entity types. Binary relationships involve two entity types.
Eg. A CUSTOMER is insured by a POLICY. A POLICY CLAIM is made against a POLICY.
Relationships are represented by diamond notation in a ER diagram.
14 I n f o r m a t i o n S y s t e m D e s i g n
Degree of Relationship: the number of entity types that participate in a relationship.
Unary relationship: a relationship between the instances of one entity type. Also called a recursive
relationship.
Binary relationship: a relationship between instances of two entity types. This is the most common type
of relationship encountered in data modeling.
Ternary relationship: a simultaneous relationship among instances of three entity types.
Cardinalities in Relationships :
Cardinality:
The number of instances of entity B that can (or must) be associated with each instance of entity A.
15 I n f o r m a t i o n S y s t e m D e s i g n
Minimum Cardinality : The minimum number of instances of entity B that may be associated with each
instance of entity A. Minimum no. of tapes available for a movie is zero. We say VIDEO TAPE is an
optional participant in the is-stocked-as relationship.
Maximum Cardinality : The maximum number of instances of entity B that may be associated with
each instance of entity A.
Mandatory vs. Optional Cardinalities: Specifies whether an instance must exist or can be absent in the
relationship. If we don’t have always any relationship from one entity to another , we need show as
optional relationship and denoted by (0) with one or many.
16 I n f o r m a t i o n S y s t e m D e s i g n
Subtype : A sub grouping of the entities in an entity type that is meaningful to the organization and that
shares common attributes or relationships distinct from other sub groupings.
Super type: generic entity type that has a relationship with one or more subtypes.
Example of ERD
Fig: E-R Diagram for Book Publisher and Library Member
17 I n f o r m a t i o n S y s t e m D e s i g n
Exercise: List out the possible errors in DFD given below
DF2
E1
1.0
P2
DF5
DF1
DS1
DF3
DF6
2.0
DF4
DF2
E1
18 I n f o r m a t i o n S y s t e m D e s i g n
P1