Data Flow Diagram (DFD) Overview and Customer Service System Example

Data Flow Diagrams (DFD) provide a visual representation of information (data) flow within a system and are widely used in software engineering and information system modeling. This article uses a customer service system as an example to describe and illustrate DFD concepts.

CS System Example

A DFD is hierarchical and may include:

Context diagram (conceptual level 0)

Level‑1 processes

Possible level‑2 DFDs and further functional decomposition, depending on system complexity

Context

The context diagram for the railway company's customer service system shows a single process representing the system ("CS System") and two external entities that interact with it: the CS Assistant and the Passenger. Data flows (connectors) indicate information exchange between the system and these entities.

The context DFD contains only one process and does not display any data stores.

Level‑1 Process

The level‑1 DFD decomposes the CS System process shown in the context diagram. It includes four processes, two external entities, and four data stores. Although there are no strict layout rules, it is common to place processes centrally with data stores and external entities on the sides for clarity.

Key details from the diagram:

Passengers can receive transport details via the "Query Transport Details" process; the data is stored in the "Transport Details" data store (persistent data, labeled "D") and the "Railway Real‑Time Statistics" store (transient data, labeled "T").

The CS Assistant initiates the "Purchase Souvenir" process, storing order details in the "Order Data Store". Although the customer places the order, the CS Assistant records the details, so the data flow originates from the assistant.

The assistant can also start the purchase process by providing order details again, which are stored in the same order data store. Physical storage implementation is decided later.

The assistant can start the "Report Lost Item" process, storing information in the "Lost Items Database".

Data Flow Diagram Tips and Considerations

Use D, M, and T to Indicate Data Types

Each data store in a DFD is prefixed with a letter indicating the type of data it holds. By default, "D" denotes persistent computerized data. "T" represents transient data kept for a short time. "M" stands for manual (non‑computerized) data, and "T(M)" indicates manual transient data.

Pay Attention to Detail Hierarchy

The example uses the word "details" repeatedly (e.g., "transport details" and "order details"). Being more specific—such as "route information, train times and delays" or "souvenir name, quantity, and price"—can improve clarity, though the exact wording depends on the diagram’s purpose.

Don’t Over‑Specify

DFDs are typically created early in system development when many details are still uncertain. Using generic terms like "details" or "information" leaves room for discussion, but overly vague terminology can reduce the diagram’s usefulness.

Avoid Over‑Scope

Focus on interactions between the system and external parties; internal interface communication is out of scope and should not be shown.

Don’t Confuse Data Flow with Process Flow

Connectors in a DFD represent data, not process steps. Labeling a connector as "request" is unnecessary. For modeling process flow, use activity diagrams or BPMN; for internal data‑store structure, use entity‑relationship diagrams.

Thank you for reading, and feel free to share, like, and follow.