{"id":1176,"date":"2026-02-25T10:36:58","date_gmt":"2026-02-25T10:36:58","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/pt\/docs\/mastering-data-flow-diagram-leveling-and-balancing\/dfd-exercises-and-templates\/dfg-terminology-list\/"},"modified":"2026-02-25T10:36:58","modified_gmt":"2026-02-25T10:36:58","slug":"dfg-terminology-list","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/pt\/docs\/mastering-data-flow-diagram-leveling-and-balancing\/dfd-exercises-and-templates\/dfg-terminology-list\/","title":{"rendered":"Glossary of DFD Terms and Relationships"},"content":{"rendered":"

Never assume that a term is self-explanatory. Misunderstanding a single word\u2014like \u201cprocess\u201d or \u201cdata store\u201d\u2014can derail an entire model. I\u2019ve seen teams waste weeks on a misaligned diagram simply because \u201cdata flow\u201d was interpreted differently across stakeholders. The fix? Anchor every term to a shared definition.<\/p>\n

This glossary is built from over two decades of modeling systems from healthcare to finance, where consistency wasn\u2019t just ideal\u2014it was non-negotiable. You\u2019ll find precise, field-tested definitions that clarify ambiguity and align with DFD standards. Each term includes context, usage, and why it matters in balancing and leveling. Use this as your go-to reference.<\/p>\n

Core DFD Elements<\/h2>\n

Process<\/h3>\n

Represents a transformation or computation that alters data. It takes input, performs an operation, and produces output.<\/p>\n

Not a program or function\u2014it\u2019s a logical action. For example, \u201cvalidate customer login\u201d is a process, not a code block.<\/p>\n

Key rule: Every process must have at least one input and one output. If it has neither, it\u2019s not a valid process.<\/p>\n

External Entity<\/h3>\n

An actor outside the system boundary that sends or receives data flows. Also called a “source” or “sink.”<\/p>\n

Examples: Customer, Bank, Government Agency.<\/p>\n

Always label with a noun and avoid verbs. \u201cCustomer\u201d is correct; \u201cSubmitting Application\u201d is misleading\u2014use \u201cCustomer\u201d with a clear data flow like \u201cSubmits Application\u201d.<\/p>\n

Data Flow<\/h3>\n

Represents the movement of data between processes, data stores, or external entities. It\u2019s not a physical transfer\u2014it\u2019s a logical description of data being passed.<\/p>\n

Use clear, action-oriented labels: \u201cCustomer Order Details\u201d or \u201cPayment Confirmation.\u201d<\/p>\n

Never describe the data itself. \u201cSend data\u201d is vague. \u201cTransmit Invoice to Accounting\u201d is precise.<\/p>\n

Data Store<\/h3>\n

Represents a place where data is held for later use. It is not a database or file system\u2014it\u2019s a conceptual container.<\/p>\n

Example: \u201cCustomer Records\u201d or \u201cPending Orders.\u201d<\/p>\n

Must be referenced by at least one process. If a data store is not accessed, it\u2019s redundant.<\/p>\n

Structural and Relational Concepts<\/h2>\n

System Boundary<\/h3>\n

Defines the scope of the system being modeled. Everything inside is part of the system; everything outside is external.<\/p>\n

Drawn as a rectangle or box around the primary processes. It\u2019s the first line of defense against scope creep.<\/p>\n

Ask: \u201cDoes this flow cross the boundary? If yes, it must be labeled and accounted for.\u201d<\/p>\n

Leveling<\/h3>\n

The process of decomposing a high-level DFD into increasingly detailed levels (e.g., Level 0 \u2192 Level 1 \u2192 Level 2).<\/p>\n

Each level adds detail while preserving the parent\u2019s context. Level 0 is the context diagram; Level 1 shows high-level processes.<\/p>\n

Never skip levels. Each decomposition must be traceable and logically consistent.<\/p>\n

Decomposition<\/h3>\n

The act of breaking down a complex process into smaller, manageable sub-processes.<\/p>\n

Use the \u201cWhat happens next?\u201d question: \u201cAfter receiving an order, what does the system do?\u201d Split actions until each sub-process is atomic.<\/p>\n

Rule of thumb: If a process can be split further without changing the data flow, it\u2019s not fully decomposed.<\/p>\n

Atomic Process<\/h3>\n

A process that cannot be meaningfully decomposed further. It\u2019s the smallest unit of functional activity.<\/p>\n

It must have inputs, outputs, and a clear transformation. There is no internal data flow.<\/p>\n

Example: \u201cCalculate tax\u201d is atomic. \u201cProcess order\u201d is not\u2014it can be broken into \u201cValidate,\u201d \u201cConfirm,\u201d \u201cSend to Billing.\u201d<\/p>\n

Validation and Consistency<\/h2>\n

DFD Balancing<\/h3>\n

The principle that data flows in and out of each level must match across parent and child diagrams.<\/p>\n

Every flow into a process in a child diagram must have a corresponding flow in the parent. Same for outputs.<\/p>\n

If you see \u201cCustomer Order\u201d in Level 1 but \u201cCustomer Order Submission\u201d in Level 2, you\u2019ve violated balancing.<\/p>\n

Consistency Across Levels<\/h3>\n

Meaning and labeling must remain stable between levels. A change in terminology breaks traceability.<\/p>\n

Use a data dictionary. If \u201cCustomer Order\u201d is defined as \u201ca record of products ordered by a customer,\u201d that definition must apply at all levels.<\/p>\n

Don\u2019t rename terms for \u201cclarity.\u201d Rename only when necessary\u2014and update the dictionary.<\/p>\n

Data Dictionary<\/h3>\n

A formal list of all data elements used in the DFD, including name, definition, aliases, and source.<\/p>\n

Not optional. It\u2019s your truth layer. Without it, even a balanced DFD can be misinterpreted.<\/p>\n

Example entry:<\/p>\n