Data Flow Diagram (DFD) Example for a Customer Service System

CS System Example

Data Flow Diagram (DFD) is a hierarchical diagram that includes:

Context diagram (conceptually level 0)

Level‑1 processes

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

Context

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

The context DFD is the entry point of the data‑flow model. It contains only one process and does not display any data stores.

Level‑1 Process

The next diagram shows the level‑1 DFD, which decomposes the CS system process shown in the context diagram. The diagram contains four processes, two external entities, and four data stores.

Passengers can receive transport details through the "Query Transport Details" process, which obtains data from the "Transport Details" store (persistent data, labeled “D”) and the "Railway Real‑Time Statistics" store (transient data, labeled “T”).

CS Assistant can start the "Purchase Souvenir" process, storing order details in the "Order" data store. Although the customer initiates the purchase, the assistant records the order.

CS Assistant can also initiate the "Report Lost Item" process, storing the information in the "Lost Item" database.

Data Flow Diagram Tips and Considerations

Use D, M, and T to indicate data type

Each data store is prefixed with a letter indicating the type of data it holds: "D" for persistent computerized data, "T" for temporary (transient) data, and "M" for manual (non‑computerized) data. "T(M)" denotes manually handled transient data.

Pay attention to hierarchy of details

When labeling data stores, be specific about the information they contain (e.g., route information, train times, delays; souvenir name, quantity; ticket type and amount) rather than using generic terms like "details".

Do not over‑specify

DFDs focus on the interaction between the system and external parties, not on internal communication between interfaces.

Do not confuse data flow with process flow

Connectors represent data movement, not control flow. Data stores are not considered to have processing capability; for modeling process flow, use activity diagrams or BPMN, and for internal structure of data stores, use ER diagrams.

The original article is available at https://architect.pub/data-flow-diagram-examples-customer-service-system and includes links to discussion groups and social media channels for further learning.