ITEC 3010

Analysis - Data Flow Diagrams

1
 Chapter 6 (Traditional Approach to
Requirements) -- Data Flow Diagrams (DFD)

• Data Flow Diagram (DFD)

– A graphical system model that shows all of the main
requirements for an information system: inputs,
outputs, processes and data storage
– Everyone working on the project (and end users) can
see all the aspects of the project in the diagram with
minimal training (simple – only 5 symbols)

2
3
 Example of a Data Flow Diagram – fig. 6-4
• The square is an external agent
– A person or organization, outside the boundary of a
system that provides data inputs or accepts data outputs
• The rectangle with rounded edges is a process
– A symbol that represents an algorithm or procedure by
which data inputs are transformed into data outputs
• The lines are data flows
– Represents movement of data
• The flat three-sided rectangle are data stores (a file
or part of a database)
– A place where data is held
• Fig. 6-4 corresponds to event “Customer wants to
check item available” (see last lecture) 4
5
 Data Flow Diagrams and Levels of
Abstraction
• Levels of abstraction
– Particular to any modeling technique that breaks the
system into a hierarchical set of increasingly more
detailed models
– Example above – a DFD fragment – showing one
process in response to one event
– Other diagrams show the processing at a higher level
(more general) or lower level (a more detailed view of
one process)
– Higher level processes in a DFD can be decomposed
into separate lower level DFD (or some other diagram)

6
 Context Diagrams

• Context Diagram: A DFD that summarizes all

processing activity within the system in single
process symbol
– Describes highest level view of a system
– All external agents and all data flows into and out of a
system are shown in the diagram
– The whole system is represented as one process
• Example – fig. 6-5 shows a context diagram for a
university course registration system that interacts
with 3 agents: academic dept., student, and faculty
member
7
8
 Notes on Context Diagram

• Useful for showing system boundaries

• External agents are outside the software scope
(which is represented by the single process). But
not from System Analysis
• Data stores are not shown in the context diagram
since they are considered to be in the software
scope (i.e. the single process)
• It is the highest level DFD
• Context diagram does not show any details of
what takes place within the system (i.e. that single
process)
9
10
 DFD Fragments
• DFD fragment: A DFD that represents the system
response to one event within a single process
symbol
– A fragment is created for each event in the event list –
it is a self-contained model showing how the system
responds to a single event
– Created one at a time
– Fig. 6-7 shows 3 DFD fragments for a course
registration system
– Each fragment represents all processing for an event
within a single process symbols
– The data stores in the DFD fragment represent entities
in the ERD (Entity Relationship Diagram – see last
lecture) – Not Necessarily !
11
12
13
14
15
 The Event-Partitioned System Model
• Event-partitioned system model: a DFD that models
requirements using a single process for each event
– The entire set of DFD fragments can be combined into this single
DFD called the event-partitioned system model or diagram 0
– Diagram 0 shows the entire system on a single DFD
• Single DFD NOT a single Process
– The entire system in a single Process is the C0ntext Diagram

• Figure 6-10 (next slide) shows a set of four related DFDs

– The top diagram shows the Context diagram for course
registration (same as fig. 6-5 above)
– The diagram below that (Diagram 0) is the decomposition of the
one process in the context diagram AND consists of the a
combined version of the 3 DFD fragments in fig. 6-7 above (in fig.
6-10, DFD fragment 1 is shown below diagram 0)
– Finally, Diagram 1 is a decomposition of the process in DFD
fragment 1
16
 DFD Fragment 2

DFD Fragment 3

17
 Dividing the system into subsystems

• The RMO customer support system involves 20

events, therefore the event-partitioned system
model (diagram 0) would contain 20 processes
– This can get to be a crowded diagram!
– Solution is to divide the system into subsystems
– Events are grouped into related subsystems based on
similar:
• Interactions with external agents
• Interactions with data stores
• Required processing
• In the RMO example, we can break up the support
system into 4 subsystems (see next slide) 18
19
• Next Step: After the subsystems are
defined:
– A DFD is created to represent the division of
the system into subsystems – the subsystem
DFD
– This subsystem DFD shows how the four RMO
subsystems are connected (i.e. how they are
related to all the outside sources and
destinations of data)
• Note that there is a process in the diagram for each
of the four subsystems that were defined for RMO
– See figure 6-13 for an example based on the 4
subsystems in the RMO example
– Note - even with only 4 subsystems (rather than
one process for each of the 20 events) the
diagram gets cluttered 20
21
• Next Step: can decompose a subsystem
DFD into event-partitioned models - one for
each subsystem:
– In the RMO example can expand the subsystem
in fig. 6-13 called “Order entry subsystem” into
an event-partitioned model
• this model has 5 processes within it – see next slide
– The analyst would also create an event-
partitioned model for the other 3 subsystems in
the RMO example

22
23
Summary - Relationship of all these diagrams

• Figure 6-6 starts off with the context diagram,

which breaks down to the subsystem diagram (one
for each subsystem)
• The subsystem diagram is turn broken down into
the event-partitioned subsystem diagrams in
Figure 6-11
• Figure 6-14 shows the decomposition of the Order
Entry Subsystem. This is the Diagram Level 0 of
the Order-Entry Subsystem.
24
Decomposing Processes to see Details of One
Activity
• Using this same principle of breaking down the
model to more detailed level, we can take a DFD
fragment (e.g. create new order fragment from the
RMO example) and decompose it into sub-
processes
• In figure 6-15 this is shown
– Since fragment “create new order” was the second
DFD fragment defined for the RMO example (see fig.
6-8) we will label processes inside of it as processes
2.1, 2.2, 2.3 etc.
– The diagram decomposes “create new order” into 4
sub-processes (see fig. 6-15) – labeled sub-processes
2.1-2.4
25
26
 Evaluating DFD Quality

• A quality set of DFDs is

– Readable
– Internally consistent
– Accurately represents system requirements
• Minimizing complexity
– Want to avoid information overload
• Occurs when too much information is presented to a user at
one time
• Two ways to avoid information overload use 7 + or – 2 rule
(which limits the number of components) and interface
minimization (which minimizes the number of interfaces and
connections between components)
– A single DFD should have no more than 7 + or – 2 processes
– No more than 7 + or – 2 data flows into or out of a process 27
• Data Flow Consistency
– Want consistency in DFDs
– Common errors:
• Differences in data flow for a process and its decomposition
(want to have balancing: equivalence of data content between
data flows entering and leaving a process or its decomposition)
• Black hole
– A process with data input that is never used to produce a
data output
• Miracle
– A process with a data output that is created out of nothing
(I.e. “miraculously appears”)
• Black hole and miracle problems apply to both processes and
data stores
• Most CASE tools perform data flow consistency checking
28
29
30
 Documenting Data Flow Diagram (DFD)
Components
• Process Descriptions
– Each process on a DFD needs to be defined
– Can keep breaking down DFD to more detailed DFD
but at some point have to describe the process in
structured English
• Uses instructions, repetition and if-then-else logic
• Note that this is not necessarily a computer program
(its an algorithm that describes the process)

31
32
• Limitations of structured English
– Good for representing processes such as those in
previous slide
– Not so good for showing complex decision logic – as
shown in next slide
– Not so good if there are few or no sequential steps

• Decision Table
– A tabular representation of processing logic containing
decision variables, decision variable values and actions
(or formulas)

• Decision Tree
– A graphical description of process logic that uses lines
organized like branches of a tree
33
34
 Making a Decision Table (from the logic on
previous slide)
• Step 1
– Identify the decision variables
• Year to date purchases (YTD)
• Number of items ordered
• Delivery date

• Step 2
– Put variable with fewest possible value ranges in the
first row of the table
• In this example could put either YTD or number of items
35
• Table so far is just one row:

YTD Purchases > $250 YES NO

• Step 3 – put variable with next fewest possible

value ranges as next row in the table, to now get:

YTD Purchases > $250 YES NO

Number of Items (N) N <=3 N>=4 N<=3 N>=4

• Step 4 – keep inserting rows as in step 3 until all

decision variables are included in the table
36
• Table now looks like:

YTD Purchases > $250 YES NO

Number of Items (N) N <=3 N>=4 N<=3 N>=4

Delivery Day Next 2nd 7th Next 2nd 7th Next 2nd 7th Next 2nd 7th

• Step 5 – Finally put as bottom row of the table the

actions for each of the possible conditions – see next
slide (fig. 6-22) from the text for the complete table

37
38
 Decision Tree

• A graphical description of process logic that uses

lines organized like branches of a tree
• Decision table is more compact but decision tree
is easier to read
• Decision tree can be developed in essentially
same way as a decision table (only difference is
that it runs horizontally – i.e. Rows in a decision
table are columns in the tree – just flip the table
sideways and you get the tree)
39
40
• there may be several actions associated with a set
of conditions in a Decision Table
– Figure 6-24 shows a table where if the customer is new
and if an item is on backorder for >= 25 days then two
things are done:
• (a) include detailed return instructions
• (b) expedite delivery
• See next slide for this example

41
42
 Data Flow Definitions
• Data flow – a collection of data elements
• Data flow definition – a textual description of a data
flow’s content and internal structure
– Lists all the elements- e.g. a “New Order” data flow consists of
• Customer –Name
• Customer-Address
• Credit-Card-Information
• Item-Number
• Quantity
– Most of these are stored and correspond to the attributes of data
entities
– In addition to just listing elements can use algebraic notation
• Data flow “equals” one element followed by another (repeating groups
43
can be shown in curly brackets)
44
45
46
47
 Data Element Definitions

• Describe a data type

– E.g. String, integer, floating point, or Boolean
– Lengths are usually defined for strings
– Numeric values usually have a minimum and maximum
value (a valid range)
– Might define special codes (e.g. code A means ship
immediately etc.)

48
 +int

9(4)

+9(6).99

String[50]

49
 Data Store Definitions

• Usually, a data store on the DFD represents a data

entity on the ERD
• Should look at the ERD for details on this
• If no ERD exists one can define the data store as a
collection of elements (like did for data flows)

50