How To Draw Data Flow Diagram In Software Engineering

What is a data flow diagram?

A data flow diagram (DFD) is a graphical or visual representation using a standardized set of symbols and notations to describe a business's operations through data movement. They are often elements of a formal methodology such as Structured Systems Analysis and Design Method (SSADM). Superficially, DFDs can resemble flow charts or Unified Modeling Language (UML), but they are not meant to represent details of software logic.

How are data flow diagrams used?

DFDs make it easy to depict the business requirements of applications by representing the sequence of process steps and flow of information using a graphical representation or visual representation rather than a textual description. When used through an entire development process, they first document the results of business analysis. Then, they refine the representation to show how information moves through, and is changed by, application flows. Both automated and manual processes are represented.

What is the difference between a logical DFD and physical DFD?

Logical DFDs represent logical information flows in relatively abstract terms. This means that they will identify general processes, systems and activities but not provide technology detail. Physical DFDs show more physical information flow detail, particularly details of information systems, applications and databases. They will also often have more elements to better depict what information is flowing, what actions are taken on or with the data and the resources associated with those actions.

It's important to note that there are many interpretations of "logical" and "physical" with respect to DFDs. Enterprise architects and line organizations will tend toward logical DFDs and will often show fewer details on physical DFDs. Development teams have the opposite orientation and will tend to use physical over logical DFDs.

What symbols and notations are used in DFDs?

DFD notions and symbols vary according to the methodology model employed. Some organizations have adopted their own conventions, though this is not recommended.

Different DFD notations include:

Gane and Sarson
Yourdon and De Marco
SSADM
UML (commonly used to map software architecture, but can be used in DFDs)

All DFD notions will represent the following:

External entities: information enters from or exits to the system being described
Flows: define the movement of information to, from and within the system being described
Stores: places where information is maintained or held, most often databases or database tables
Processes: transform information

Different DFD methodologies use different symbol conventions. The differences and symbol rules are divergent enough to make it difficult for technologists to read the DFDs of methodologies they're not familiar with.

For example, in Gane and Sarson, entities are boxes with square corners and processes have rounded corners. However, in Yourdon and De Marco, entities have square corners, but processes are circles. SSADM almost reverses Gane and Sarson conventions. Stores in Yourdon and De Marco are shown as parallel lines, but all the other methodologies use a different representation. For this reason, it's important for a company to select a methodology and symbology and stay with it.

What are the different DFD levels and layers?

Levels or layers are used in DFDs to represent progressive degrees of detail about the system or process. These levels include:

Level 0: Also known as a "context diagram," this is the highest level and represents a very simple, top-level view of the system being represented.
Level 1: Still a relatively broad view of the system, but incorporates subprocesses and more detail.
Level 2: Provides even more detail and continues to break down subprocesses as needed.
Level 3: While this amount of detail is uncommon, complex systems can benefit from representation at this level.

In theory, more levels are possible, but they are rarely used and would likely represent more detail than a data flow diagram would normally convey.

How do you create a data flow diagram?

While it depends on the tool used to prepare a DFD, here is a basic breakdown of steps to follow when creating one:

Choose a process or system to diagram.
Select the interests involved and categorize them into external entities, flows, processes and stores.
Illustrate a Level 0 context diagram with basic connections.
Create more detailed Level 1 diagrams that branch off the processes of the context diagram, including connected flows, stores, additional processes and external entities.
Repeat as necessary and with a much detail as required.

It's important to continuously check the diagram at each level to make sure there are no missing or unnecessary processes or flows.

What tools can be used to create a DFD?

While it is possible to draw DFDs by hand, it's rarely done except as an ad hoc aid to discussion. DFDs can also be created using graphics or presentation tools, particularly those that support the creation of custom symbols. However, most DFD users find this is limiting because of the common requirement of such tools to set a specific page size.

Most DFDs are created using specialized DFD tools, which are sometimes bundled with other features that relate to the specific methodology being used. There are many tools available, including both proprietary and open source. It's also possible to use cloud-hosted tools to create DFDs. Because many such tools are associated with a specific methodology, it's important to select a tool that fits the methodology to be used. Import/export from one tool to another may be limited, so a standard tool should be considered for an enterprise.

Some DFD tools include:

Lucidchart
Visual Paradigm
Smartdraw
ConceptDraw
Creately

What are examples of DFDs?

The best examples of DFDs are provided in documents or tutorials relating to a singular methodology. Reviewing sample DFDs without the context of a methodology can make interpretation of the graphics and structure difficult.

Most DFD examples will depict a business or functional view of a process, which is what distinguishes them from flow charts or UML that depict software flows or software architecture.

The image below is an example of a school's culinary program using the Gane and Sarson method.

This was last updated in October 2021

Continue Reading About data flow diagram (DFD)

9 steps to a dynamic data architecture plan

Data management roles: Data architect vs. data engineer, others

Data architecture vs. information architecture: How they differ

Align enterprise data architecture, governance for 'quick wins'

A case for data flow diagrams

Dig Deeper on Data quality techniques and best practices

How to choose exactly the right data story for your audience

By: Technics Publications
network topology

By: Alexander Gillis
threat modeling

By: Michael Cobb
Diagrams.net vs. Lucidchart: A few things to consider

By: Kerry Doyle