MIS 374

Data Process Modeling:

Context Diagrams & Data Flow Diagrams (DFDs)
Introduction
When designing/building an information system for an organization, you should consider the following
questions regarding the information processed by the system:
• Who (i.e. which stakeholder(s)) needs this information?
• What information is needed?
• Where is that information stored?
• How is the information transformed as it enters the system, flows through it, and is outputted?
As a systems analyst, programming analyst, or IT auditor you are likely to need a graphical technique to
help investigate and document how data is inputted into the system either manually or automatically.
You’ll also need to see how data flows through the system, is changed, and stored. Lastly you should
consider what the output is and how data is retrieved from the system (e.g. reports, exports to external
systems). Graphics that are “data focused” will greatly assist you in your ERD creation and overall
database design. Since the database is a foundation of your system, it’s important to model it thoroughly.
Graphics also simplify complex components of a system. By creating a simpler depiction of the system
we can better communicate with our non-technical client or future users how the system works.

The Story-Telling Power of DFDs

DFDs tell stories. They do not capture the business process (i.e. how you do your job function), but
instead focus on where the data comes from, where it goes, and how it changes. DFDs help depict the
data flowing through a system in a visual way that enables you to better communicate with other IT
professionals and stakeholders. Therefore, another trained person (i.e.: a 374 classmate, the TAs, and
the professors) should be able to read your DFDs without ever reading the supporting case materials.
Your DFDs should be self-explanatory and thoroughly explain the system’s data transformation
processes.

Description
A data flow diagram (DFD) is a drawing that shows how a system's environmental entities, processes,
and data are interconnected. Developers or users can depict their current system processes or desired
system process using the four simple symbols shown in Table A below.
Table A. Data Flow Diagram Symbols

Environmental Entity (EE)—a source of, or destination for, data outside the
system.

Data flow—each data flow must have a unique identifier or label describing
the data.

Process bubble—a process that changes data. Process bubbles should

be numbered in the top section of the bubble. The Process Label should be
in a verb – object format, and placed in the middle section of the bubble. The
bottom section of the bubble should identify the actor or system component
performing the process

Data store—where the data is stored (e.g. database, file, file cabinet).

©Eleanor Jordan 2011. All rights reserved. (Update Fall 2017 by Clint Tuttle and Caryn Conley)
Page 1 of 7
 MIS 374

DFD Symbols and Rules

As stated on page 1, DFDs consist of four basic symbols that represent (1) environmental entities, (2)
data flows, (3) processes, and (4) data stores.
External Entity (EE) Symbols. Systems interface with persons, organizations, locations, and other
systems. Each of these entities in the environment is represented by a square and includes the name of
the entity. Sometimes drawings become cluttered if data flow arrows are needed from several different
processes to the same EE. In this case, consider repeating an EE square, and remember to include the
EEn label to make sure that it’s clear that two EE squares with the same names are identical and not
different entities.
Process Symbols. A process is a transformation of data. Data flows into a process, is transformed,
and then flows out. In order for something to be a process, the output must be different from the input in
some way. Process symbols are labeled with a verb and object, such as Verify User Name and Edit
Date. The context diagram is an exception: the central oval is labeled with the system name, and is not a
particular process.
Data Flow Symbols. A good way to think of a data flow is "data on the move.” The data moves from an
environmental entity to a process, from one process to another, from a data store to a process, and so
on. In most cases the data flow is a single line going in one direction; two-headed (or forked) arrows can
be used to show the same data flows from one process, data store, or entity to more than one
destination. Each data flow in a DFD is labeled with a unique name in the same diagram. However, when
the same flow appears on more than one level the same name is used for each appearance.
Data Store Symbols. Whereas data flows represent data on the move, data stores represent data that is
maintained in fixed locations. Think of a data store as "data at rest." Examples of data stores are master
files, such as inventory and personnel data that are kept current, and history files that are held in archival
storage.
Data stores are depicted with open-ended rectangles and have a unique label, such as D1, D2, etc.

Rules for Creating DFDs

Be sure to adhere to the following rules when creating your DFDs. This will ensure consistency across
your diagrams, and help you clearly communicate the story to your reader:
1. Input to a process should be different than the output
2. Processes must have both and input and an output
3. Objects (e.g. environmental entities, data stores) should have unique names
a. Remember, you may repeat an object in order to unclutter your diagram
4. Each diagram should have 7 or fewer processes
5. Each process should have a verb phrase label to describe the process
6. Data flows labels should be noun phrases
7. Data only flows in one direction at a time
8. Data must be transformed by a process (i.e. it cannot move directly between environmental
entities or data stores)
9. Data store labels should be noun phrases
10. It may be okay if Figure 0 has no actors on a process

The Context Diagram

DFDs exist in a hierarchy, beginning with the simplest, highest, system level diagram, called the context
diagram. This system level diagram illustrates the context, that is, the circumstances of the system
environment. This diagram contains only a single, unnumbered process bubble in the shape of a circle to

©Eleanor Jordan 2011. All rights reserved. (Update 2015 by Clint Tuttle)
Page 2 of 7
 MIS 374
represent the entire system and ending with the lowest level diagrams that contain the most detailed data
transformation processes.
Figure A illustrates the context diagram for the existing Latinitas “system” with a single process bubble in
the middle. The five environmental entities are represented by squares surrounding the single system
process bubble. The system is connected to its environmental entities by arrows that represent data
flows. Notice how many data flows surfaced in the team’s discussions with Angie about her work with
Latinitas donors, volunteers, and interns. When Angie posted her request for an MIS 374 “Volunteer
Database,” she had not thought through her real needs. White-boarding with her MIS 374 development
team was a learning experience for Angie as well as the team.
Figure A - Context Diagram for Existing Latinitas System

The Figure 0 Diagram

The next level in the DFD hierarchy is referred to as the Figure 0 Diagram. This diagram provides the first
level of detail of the high-level processes contained in the system bubble of the context diagram. Each
process of the Figure 0 diagram is numbered from left to right and then top to bottom. In order to prevent
a DFD from becoming cluttered, the general rule is to keep the number of processes depicted in a
diagram to seven or less. This rule applies to the Figure 0 diagram as well as DFDs on lower levels as
well.
Figure B shows the Figure 0 diagram of the existing Latinitas system. The system contains four high-
level (or main) processes: Manage Interns, Manage Volunteers, Organize Fund Raising Events, and
Determine Needs for Funds.

©Eleanor Jordan 2011. All rights reserved. (Update Fall 2017 by Clint Tuttle and Caryn Conley)
Page 3 of 7
 MIS 374
Figure B - Level 0 (Figure 0) DFD for the Latinitas System

Because the Figure 0 diagram contains more detail than the context diagram, it is important to ensure
that the data flows to and from each environmental entity must match between each level. In the Figure 0
diagram above, the same five environmental entities and their labeled data flows from the context
diagram are included and now connect to more specific processes in the Latinitas system. are included.
For example, the Fundraising Donor at the bottom right of Figure 0 above has exactly two data flows with
the same names as the two data flows for the Fundraising Donor in the Context Diagram.
Also note that the Job Duties dataflow splits from Process 3 when flowing into Process 1 and 2. Since
some processes can create data that is then used by multiple subsequent processes, you’re allowed to
do this when it makes sense. This will reduce duplicate dataflows and over-crowding in your model.

Figure n Diagrams
In the next level of the hierarchy, the individual processes identified in the Figure 0 diagram are detailed
in their own diagrams, called Level 1 diagrams. For example, you would create a Figure 1 diagram to
provide detail about the first process (Manage Interns in the above example). You would create a Figure
2 diagram to provide detail about the second process (Manage Volunteers in the above example). We
refer to these DFDs as Figure n diagrams.
Figure C below illustrates a Level 1 diagram for Process 3 of the Latinitas system—Organize Fundraising
Event. This Figure 3 DFD consists of five detailed processes numbered 3.1, 3.2, etc. Process 3.1 is the
initial process of obtaining and processing donations needed to hold an event. The second detailed
process of Figure 3 is process 3.2, the determination of when to hold fundraising events.

©Eleanor Jordan 2011. All rights reserved. (Update Fall 2017 by Clint Tuttle and Caryn Conley)
Page 4 of 7
 MIS 374

Figure C Level 1 (Figure 3) DFD for Organizing Fundraising Events

If additional detail is needed for any of the processes in a Level 1 diagram, you would create a Level 2
diagram. The logic for creating a Level 2 diagram is similar to creating a Level 1 diagram:
• You should have 7 or fewer detailed processes
• The data flows to and from each relevant environmental entity should match the data flows in the
Level 1 diagram for that environmental entity.
• The numbering of each process should follow the numbering of the process in the Level 1
diagram. For example, to provide more detail about process 3.1 from the Figure 3 diagram, each
process would be numbered 3.1.n. Please see below for an example.

©Eleanor Jordan 2011. All rights reserved. (Update Fall 2017 by Clint Tuttle and Caryn Conley)
Page 5 of 7
 MIS 374

Figure D - Level 2 (Figure 3.1) DFD for Obtaining Donations

Now that the diagrams have reached a sufficient level of detail, the data store symbol has been
introduced in Figure 3.2 above. In this example, “Donor Information” is a manila folder that Angie
keeps; the “Donor Database” and “Donations Per Event” are spreadsheets. All data store
symbols should have identifiers, such as D1, D2 and D3, depending on how many data stores are
used in the system being modeled. NOTE: You may introduce data stores in any diagram (except
for the context diagram) – you can include them in Figure 0, Level 1 diagrams, Level 2s, etc
The same top-down decomposition of the system processes can be continued for more detailed levels.
However, it is not necessary to document the same level of detail for all processes. Some processes can
be adequately documented at a higher level in the hierarchy. The top-down process of documenting a
system with DFDs continues until you reach a level of detail where the focus is on individual data flows
that are important to determining functional requirements for the scope of a project.

Tip when Creating DFDs

©Eleanor Jordan 2011. All rights reserved. (Update Fall 2017 by Clint Tuttle and Caryn Conley)
Page 6 of 7
 MIS 374
Our example figures for Latinitas are the result of considerable time spent by the team with Angie, their
client. A good way to start is to create the simple context diagram with an in the middle to represent the
entire system. Then ask your client about what data the system must produce and what data is required
for the system’s functionality. If you do your work on a white-board, photograph the board at the end of
your discussion. If you think your initial work is fairly accurate, then create an electronic version of the
context diagram in Visio or LucidCharts that will allow you to add Environmental Entities and data flows
as you talk with stakeholders to learn more details and create lower level DFDs.
Few clients will be able to provide all of the necessary answers, so you will need to talk with key
stakeholders that understand the existing system to analyze the processes for an existing system.
Individuals are likely to be able to only describe processes they perform. You will likely perform several
iterations, collecting information from several stakeholders, and then analyzing the data you collected to
consolidate into the DFDs to accurately describe the existing system

FAQs
Q1: How do I make my DFDs pretty? All the lines are crisscrossed.
Answer: Try to organize your external entities (EEs) around the outside edges of the document. Then,
put your process bubbles between these entities. If any process uses multiple EEs, try to put the EEs
close to each other. Also try to use right-angle connectors; they make the diagrams more legible, as well
as, help you group in-bound and out-bound data flows together.

Q2: How do I even begin to make my DFDs? I’m totally stuck.

Answer: The Group Project case lists steps for major processes. Start with each process separately
using the interview data. The Group Project 1 specification requires you to “collect these” (or roll up these
details) into a summary level DFD (Figure 0) to just show major processes at the summary level. The
instructions only require that you turn in a few Level 1 DFDs—so you only have to create a few “clean”
Level 1 DFDs that follow all the rules (e.g. a Figure 1, Figure 2, Figure 3). Before creating a Figure 0
diagram, make a list of all the data flows that go to and from the external entities in your Level 1
diagrams, so you know what needs to show up on the Figure 0 diagram and Context diagram. Some
analysts find it easier to work on paper or whiteboard before using Visio or Lucidcharts. For your client
project you may want to white board processes and then take photos to use for Visio or Lucidcharts
graphics.

Q3: What are some general hints when making DFDs?

Answer: Label your external entities (ex: EE1 and EE2). If you use the same external entity multiple
times, make sure each has the same EE number. Also, make sure external entities don’t “talk” with each
other. That is, don’t draw data flows between external entities – instead, these data flows must be
connected through some process bubble in the System.
Remember that every process must transform data. Printing doesn’t transform data. A data flow arrow,
not a process bubble, shows sending or delivering data.
Use the Gane-Sarson process symbols if you are using Visio. This stencil has all the symbols you need
for DFDs but you can also just find symbols that match the ones list above. Just make them consistent to
the symbols above so we don’t have to interpret your DFD.
NOTE: Gane-Sarson process symbols are the process bubbles above with three parts – process ID # on
top, verb – object process label in the middle, and who/what performs the process on the bottom.

©Eleanor Jordan 2011. All rights reserved. (Update Fall 2017 by Clint Tuttle and Caryn Conley)
Page 7 of 7