Is a DFD the same as a flowchart?

No. A DFD emphasizes information movement and transformation; a flowchart commonly emphasizes steps, decisions and control sequence.

Does a data store have to be a database?

No. Depending on scope, a file collection or another place where information is retained may be represented as a store.

Does every DFD need trust boundaries?

No. They are particularly useful in security modeling, but the basic information-flow model can serve other purposes without them.

AI Glossary / Data engineering and architecture / Beginner

Data-flow diagram

Definition

A data-flow diagram, or DFD, is a visual model of how information enters a system, moves through processes, reaches data stores and leaves for other people or systems. It emphasizes information movement and transformation rather than execution sequence.

What it means

A DFD helps different participants agree on a system's information exchanges. A customer submits order details, a process checks them, a store holds accepted orders and another process produces a confirmation. Naming those exchanges makes assumptions visible before someone writes code or purchases a service.

The diagram can describe a business activity or a technical implementation. In AI projects, mapping prompts, retrieved documents, generated answers and logs can expose an overlooked information transfer.

How it works

Common DFD elements are external entities, processes, data stores and directed data flows. External entities supply or receive information outside the chosen scope. Processes do something with information. Stores retain it. Arrows indicate transfers and should name the information being transferred.

Start by deciding the boundary and purpose of the model. Draw a context view showing the system's external exchanges, then expand selected processes into more detailed views. Keep the inputs and outputs consistent between a parent process and its expanded view; unexplained new external exchanges suggest that the model needs revision.

Different notations use different shapes, so provide a legend. A security-focused DFD may also mark trust boundaries. These identify changes in assumptions or control, helping reviewers ask how information is protected when it crosses them. The drawing supports that investigation but does not perform it automatically.

Three practical examples

1. A retailer maps an order service. It distinguishes order details received from the customer, inventory data read from a store and fulfillment instructions sent to a warehouse.

2. A team maps an AI document assistant. It shows document retrieval, the context supplied to a model service, the returned answer and the separate conversation log.

3. A community organization maps a registration process. The diagram shows where submitted details are checked, where accepted registrations are retained and which information appears in a coordinator's report.

Think of it this way

Think of a map showing packages moving between workrooms, storage areas and outside recipients. Labels say what each package contains and rooms indicate transformations. The limitation is that a DFD is not a timetable: arrow placement does not establish exact execution order, duration, concurrency or a delivery guarantee. Those questions may require other models.

Worked example

Consider a fictional expense service with one employee entity, two processes and one store. The employee sends a claim to Validate Claim. That process sends accepted claim details to the Claims Store and sends rejection details back to the employee when appropriate. Create Report reads accepted claims from the store and sends a report to the employee.

This model has five named flows: submitted claim, accepted claim, rejection details, stored claims and expense report. It does not require five network connections; several flows could share a technical connection.

Now expand Validate Claim into Check Required Fields and Check Allowed Categories. The expanded view should still explain the submitted claim input and accepted or rejected outputs. If it introduces an exchange-rate service, that external dependency must also be accounted for at the relevant higher level. The exercise checks consistency of information exchanges, not numerical conservation of bytes.

Illustrative case study

Fictional case: DiagramMeadow designs a chatbot that answers questions from an internal handbook. Its first diagram shows a user, a chatbot and the handbook store. During review, an engineer identifies a separate monitoring service that receives full prompts and answers.

The team adds the logging flow and examines which information that service receives, who can access it and whether full content is necessary. The revised picture also separates retrieval from answer generation so reviewers can see what crosses the model service boundary.

No symbol alone establishes that these transfers are acceptable. The improvement is that the team can now discuss an actual information route that was previously missing from its shared model.

Common misconceptions and mistakes

Do not use unlabeled arrows and assume readers know their meaning. A line called data says little about whether it contains a customer identifier, a document or a status response. Similarly, a process should describe an activity rather than merely repeat a department name.

Avoid mixing a high-level business model with selected low-level technical details without explanation. Do not interpret DFD arrows as control-flow branches or the chronological steps of a flowchart. Finally, check stores that appear only to receive data: this may be intentional within scope, but an omitted reader or retention process can hide a relevant requirement.

Business use

DFDs are useful in requirements workshops, integration planning, data governance and security review. They help business owners and engineers discuss the same exchanges without requiring everyone to read source code.

Keep the model detailed enough to answer its intended questions and small enough to review. Give flows meaningful names, record important assumptions and assign responsibility for updates when integrations change. A dated, accurate model of one consequential workflow can be more useful than an elaborate enterprise picture whose arrows nobody has checked against reality.

Check your understanding

A diagram shows a customer writing directly into a database, but an application actually validates the submission first. What should change?

Answer: Represent the validation process and its incoming and outgoing data flows. Otherwise the diagram hides the component that transforms or rejects the submission and misrepresents how stored information is produced.

Related terms

Data store
Data flow
process modeling
context diagram
system boundary
threat modeling
data lineage
flowchart
entity-relationship diagram
interface

Learn next

Choose a familiar form submission. Draw its external participants, processing activities, stores and named flows. Ask someone who operates the service to trace a successful submission and a rejected one. Then compare the model with a flowchart to see which timing and decision details the DFD intentionally leaves unspecified.

Sources

Microsoft, Create a Gane-Sarson data flow model diagram, describes top-down decomposition and diagram elements: https://support.microsoft.com/en-us/visio/create-a-gane-sarson-data-flow-model-diagram

Hernan, Lambert, Ostwald and Shostack, Uncover Security Design Flaws Using the STRIDE Approach, explains DFD elements and trust boundaries in security modeling: https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach

The primary descriptions were read. The examples and case are original; notation choices and the level numbering used for expanded diagrams should be stated by each project.

Previous: Data farming Next: Data fusion