This document describes data flow diagrams (DFDs) as a tool for systems analysis, focusing on the logical representation of a system's data flows rather than physical details. It outlines various components such as processes, data stores, and external entities, while providing guidelines on how to construct and balance different types of DFDs. The document emphasizes the importance of clarity, labeling, and iterative refinement in creating effective diagrams.

1. DATA FLOW DIAGRAMS

2. Systems Analysis
• Focus is the logical view of the
system, not the physical
• “What” the system is to accomplish,
not how
• Tools:
–data flow diagrams
–data dictionary
–process specification
–entity-relationship diagrams

3. Data Flow Diagram:
"a network representation of a system.
The system may be automated, manual, or
mixed. The DFD portrays the system in
terms of its component pieces, with all
interfaces among the components
indicated."
- Tom DeMarco
hence DFDs:
focus on the movement of data between
external entities and processes, and
between processes and data stores

4. Example Data Flow
Diagram
data store
process
external
entity
data flow

5. Data Flow Diagrams are:
• Used to perform structured analysis
to determine logical requirements
• A graphical tool, useful for
communicating with users,
managers, and other IS personnel
• Useful for analyzing existing as well
as proposed systems
• A relatively simple technique to learn
and use

6. Why Conduct Process
Modeling?
• Understand components of
current logical or physical
system for purpose of rebuilding
in a different physical
form/technology, possibly with
some changed functionality
• Find inefficiencies in current
system
• Re-engineer current system

7. Sources/Sinks
(external entities)
• Any class of people, an
organization, or another
system which exists
outside the system you are
studying.
• Form the boundaries of the
system.
• The system and external
entities exchange data in
the form of data flows.
• Must be named, titles
preferred to names of
individuals - use a noun
source
/
sink

8. Data Flows
• data in motion
• marks movement of data through the
system - a pipeline to carry data
• connects the processes, external entities
and data stores
• Unidirectional
• originate OR end at a process (or both)
• name as specifically as possible - reflect
the composition of the data - a noun
• do not show control flow! Control flow is
easy to identify- a signal with only one
byte - (on/off).
• HINT: if you can't name it: either it's
control flow, doesn't exist or you need to
get more information!

9. Processes
• transform incoming data
flows into outgoing data
flows
• represent with a bubble or
rounded square
• name with a strong
VERB/OBJECT
combination; examples:
create_exception_report
validate_input_characters
calculate_discount
process

10. Data Stores
• data at rest
• represents holding areas for
collection of data, processes
add or retrieve data from
these stores
• name using a noun (do not
use ‘file’)
• only processes are connected
to data stores
• show net flow of data between
data store and process. For
instance, when access a
DBMS, show only the result
flow, not the request
data store

11. Data Flow Diagram Don’ts
1. BLACK HOLES
2. MIRACLES
3. Let it get too COMPLEX: 7 ± 2 processes
4. Leave things UNLABELED
(corollary: labels should have meaning)
5. Data stores that are “SOURCES” or
“SINKS”
6. Data flows that are UNASSOCIATED with
a PROCESS
7. Expect your diagram to be “perfect” the
first time!

12. Data Flow Diagram Don’ts
process
stuff
1. ‘Black Hole’
process
stuff
2. ‘It’s a Miracle’

13. Data Flow Diagram Don’ts
A.2
A.1
ds-1
data
4. Leave Things Unlabeled
Corollary: Labels Should

14. Data Flow Diagram Don’ts
data store 5. Miracle data
source
data store
5. Black hole data
source

15. Data Flow Diagram Don’ts
6. Data Flows Unassociated With a Process
entity to
entity
data store
to entity -
or reverse
data store
to data
store

16. Diagramming A System
• multiple DFDs are required to
represent a system
• DFDs are created at increasing
levels of detail

17. Different Types of DFDs
• Context diagram
• Level-0 diagram (system diagram)
• Level-n diagram
• Primitive diagram

18. Context Diagram
• defines the scope of the system by
identifying the system boundary
• contains:
–one process (which represents the
entire system)
–all sources/sinks (external
entities)
–data flows linking the process to
the sources and sinks (external
entities)

19. Example Context Diagram
Registration
System
student
course
selections
business
office
Registration details
schedule

20. Constructing a Context
Diagram
• identify and list sources/sinks
(external entities)
• identify and list inputs to and
outputs from sources/sinks
(external entities)
• create context diagram

21. Level-0 Diagram
• describes the overall processing of the
system
• show one process for each major
processing step or functional
requirement
• data flows from the context appear on
system diagram also (level balancing)
• can show a single data store to represent
all data in aggregate at this level
• can draw duplicate sources, sinks and
data stores to increase legibility

22. Drawing a Level-0 Diagram
• list the major data stores
• list major business steps
• draw a segment for each business
step
• assemble into single DFD
• re-organize until satisfied
• number processes

23. Functional Decomposition
• similar to a series of more detailed maps
• iterative process of breaking the
description of a system into finer and
finer detail to create a set of charts in
which one process on a given chart is
explained in greater detail on another
chart
• referred to as exploding, partitioning, or
leveling
• must use your judgment to decide what
goes on each level
• show error and exception handling on
lower levels (if at all)

24. Lower Level Diagrams
• explode the processes shown on the
level-0 diagram
• each process is represented by its own
DFD
• balance data
– data flows on upper level appear on lower
level, or
– data flows on upper level are broken into
component pieces with components
shown on lower level
• each lower level shows greater and
greater detail
• follow numbering convention

25. Balancing DFDs
• conserve data from level to level -
inputs and outputs on the higher
level must appears somewhere on
the lower level

26. Advanced Rules
• Composite data flow on one level can be
split into its component data flows on the
next level - but new data cannot be added
and all data in the composite must be
included in the sub-flows
• The inputs to a process must be sufficient
to produce the outputs.
• Lowest level DFDs may add new data
flows to represent exception handling,
i.e., error messages
• May repeat data stores or sources/sink to
avoid crossing lines

27. Additional Guidelines
• the inputs to a process are different
from the outputs of that process
• objects in a set of DFDs have unique
names
• do not change data flow names on lower
levels unless you are decomposing a
data flow into component pieces.
• never explode a single process into
another single process. If you cannot
partition the process, then the lower
level DFD is not needed.
• expect to iterate, put down the DFD and
go back to it a few times to create
something satisfactory.

28. Other Questions about Lower
level diagrams
1. How deep? (how many levels?)
– if the process has only one input or one
output, probably cannot partition further;
– can you describe the process in English in
about 1/2 page?
2. How broad? (how many processes on a
level?)
– 7 ± two is a reasonable heuristic
– may temporarily place much of the system
on a single diagram then re-draw into
separate levels

29. Quality Guidelines
• Completeness
– all components included & in project
dictionary
• Consistency
– between levels: balancing, leveling
• Timing considerations
– assume system never starts and never stops
• Iterative nature
– revisions are common
• Drawing primitives (lowest level)
– when to stop?