Structuring System
Process
Requirements
Process Modeling
Graphically represent the processes that capture,
manipulate, store, and distribute data between a
system and its environment and among system
components
Utilize information gathered during requirements
determination
Processes and data structures are modeled
Context Diagram
Data Flow Diagram (DFD)
A picture of the movement of data between
external entities and the processes and data
stores within a system
Imagine a traffic system
How do data flow ?
Process Modeling (cont.)
Deliverables and Outcomes
Context data flow diagram (DFD)
DFDs of current physical and logical system
Enables analysts to understand current system
DFDs of new logical system
Scope of system
Technology independent - why ?
Show data flows, structure, and functional requirements of
new system
Thorough description of each DFD component
Data Flow Diagram (DFD)
A picture of the movement of data between
external entities and the processes and data
stores within a system
Difference from system flowcharts:
DFDs depict logical data flow independent of
technology
Flowcharts depict details of physical systems
DFD Symbols
DFD Symbols (cont.)
Process: work or actions performed on data (inside
the system)
Data store: data at rest (inside the system)
Source/sink: external entity that is origin or
destination of data (outside the system)
Data flow: arrows depicting movement of data
Fundamentals
The inputs to a process are different from the
outputs of that process.
Objects on a DFD have unique names
DFD Diagramming Rules
Process
No process can have
only outputs or only
inputsprocesses
must have both
outputs and inputs.
Process labels should be verb phrases.
DFD Diagramming Rules
Data Store
All flows to or from a data store must
move through a process.
Data flow and data store labels should be noun phrases.
DFD Diagramming Rules
Source/Sink
No data moves directly between external entities
without going through a process.
Interactions between external entities without
intervening processes are outside the system and
therefore not represented in the DFD.
Source and sink labels should be noun phrases.
DFD Diagramming Rules
Data Flow
Bidirectional flow
between process
and data store is
represented by two
separate arrows.
Forked data flow
must refer to exact
same data item (not
different data items)
from a common
location to multiple
destinations.
DFD Diagramming Rules
Data Flow (cont.)
Joined data flow
must refer to exact
same data item (not
different data items)
from multiple
sources to a
common location.
Data flow cannot
go directly from a
process to itself,
must go through
intervening
processes.
DFD Diagramming Rules
Data Flow (cont.)
Data flow from a process to a data store means
update (insert, delete or change).
Data flow from a data store to a process means
retrieve or use.
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.
Functional Decomposition
An iterative process of breaking a system
description down into finer and finer detail
High-level processes described in terms of lowerlevel sub-processes
DFD charts created for each level of detail
Until the point at which
no subprocess can logically be broken down further
it is clear enough to the reader
Refer to guidelines presently later
DFD Levels
Context DFD
Level-0 DFD
Representation of systems major processes at high level of
abstraction
Level-1 DFD
Overview of the organizational system
Results from decomposition of Level 0 diagram
Level-n DFD
Results from decomposition of Level n-1 diagram
Context Diagram
Context diagram
shows the
system
boundaries,
external entities
that interact with
the system, and
major
information flows
between entities
and the system.
NOTE: only one process symbol, and no
data stores shown.
Level-0 DFD
Level-0 DFD
shows the
systems major
processes, data
flows, and data
stores at a high
level of
abstraction.
Processes are labeled 1.0, 2.0, etc. These will be decomposed into
more primitive (lower-level) DFDs.
Level-1 DFD
Level-1 DFD shows
the sub-processes
of one of the
processes in the
Level-0 DFD.
This is a Level-1
DFD for Process
4.0.
Processes are labeled 4.1, 4.2, etc. These can be further
decomposed in more primitive (lower-level) DFDs if necessary.
Level-1 DFD
Level-n DFD
Level-n DFD shows
the sub-processes
of one of the
processes in the
Level n-1 DFD.
This is a Level-2
DFD for Process
4.3.
Processes are labeled 4.3.1, 4.3.2, etc. If this is the
lowest level of the hierarchy, it is called a primitive DFD.
DFD Balancing
The conservation of inputs and outputs to a data
flow process when that process is decomposed to a
lower level
Balanced means:
Number of inputs to lower level DFD equals number of
inputs to associated process of higher-level DFD
Number of outputs to lower level DFD equals number of
outputs to associated process of higher-level DFD
Unbalanced DFD
1 input
1 output
2 inputs
1 output
This is
unbalanced
because the
process of the
context diagram
has only one
input but the
Level-0 diagram
has two inputs.
Balanced DFD?
1 input
2 outputs
Balanced DFD (cont.)?
Data Flow Splitting
A composite data flow at
a higher level may be
split if different parts go
to different processes in
the lower level DFD.
This remains balanced because the same data is involved, but
split into two parts.
More DFD Rules
Four Different Types of DFD
Current Physical
Process labels identify technology (people or systems)
used to process the data.
Data flows and data stores identify actual name of the
physical media.
Current Logical
Physical aspects of system are removed as much as
possible.
Current system is reduced to data and processes that
transform them.
Four Different Types of DFD
(cont.)
New Logical
Includes additional functions
Obsolete functions are removed
Inefficient data flows are reorganized
New Physical
Represents the physical implementation of the
new system
Context Diagram
Current Physical
Current Logical
New Logical
Examples
Figure 7-13, 15, 16
New function
Shipment data to be entered into the system (1.0)
Automatic generation of orders (3.0)
Instant query on inventory level (5.0)
In Practice,
Create DFDs for the current physical system
Only enough to get a good overview
They will mostly be replaced by the new physical
DFDs
Create logical DFDs for the current system
Create logical DFDs for the new system
Go to this stage as quickly as possible
Guidelines for Drawing DFDs
Completeness
DFD must include all components necessary for
system.
Each component must be fully described in the
project dictionary or CASE repository.
Consistency
The extent to which information contained on one
level of a set of nested DFDs is also included on
other levels.
Guidelines for Drawing DFDs
(cont.)
Timing
Time is not represented well on DFDs.
Best to draw DFDs as if the system has never
started and will never stop.
Iterative Development
Analyst should expect to redraw diagram several
times before reaching the closest approximation
to the system being modeled.
Guidelines for Drawing DFDs
(cont.)
Primitive DFDs
Lowest logical level of decomposition
Decision has to be made when to stop
decomposition
Guidelines for Drawing DFDs
(cont.)
Rules for stopping decomposition
When each process has been reduced to a single
decision, calculation or database operation
When each data store represents data about a
single entity
When the system user does not care to see any
more detail
Using DFDs as Analysis Tools
Gap Analysis
The process of discovering discrepancies between two or
more sets of data flow diagrams or discrepancies within a
single DFD
Inefficiencies in a system can often be identified
through DFDs.
Redundant data flows
Unused data
Data that are update identically in more than one location
Excessive processing steps
Using DFDs in Business
Process Reengineering
Before: Credit approval process
required six days
After: process 100 times as many
transactions in the same time
