functional-diagrams

Original：🇺🇸 English

Translated

Use when creating data flow diagrams (DFD), functional decomposition trees, IDEF0 diagrams, or BPMN process models. Covers process-oriented and data-oriented diagram types for analyzing system behavior and data transformation. USE FOR: data flow diagrams (DFD), functional decomposition, IDEF0 modeling, BPMN process modeling, process analysis, data transformation visualization, system behavior documentation, input-output analysis DO NOT USE FOR: object-oriented modeling (use uml), system container decomposition (use c4-diagrams), enterprise architecture (use togaf or archimate)

2installs

Sourcetyler-r-kendrick/agent-skills

Added on2026-02-26

NPX Install

npx skill4agent add tyler-r-kendrick/agent-skills functional-diagrams

SKILL.md Content

View Translation Comparison →

Functional Diagrams

Overview

Functional diagrams describe systems in terms of processes, data flows, and transformations rather than objects or containers. They answer the question "what does the system do with data?" and "how are functions decomposed into sub-functions?"

This skill covers four complementary functional diagramming techniques:

Data Flow Diagrams (DFD) — Show how data moves through a system
Functional Decomposition — Break high-level functions into sub-functions
IDEF0 — Model decisions, actions, and activities with inputs, controls, outputs, and mechanisms
BPMN — Model business processes with standardized notation

Data Flow Diagrams (DFD)

DFDs show how data is processed by a system. They use four core element types and are organized into hierarchical levels.

DFD Elements

Element	Symbol	Description
Process	Circle or rounded rectangle	Transforms input data into output data
Data Store	Open-ended rectangle (parallel lines)	Repository where data is held for later use
External Entity	Rectangle (square)	Source or sink of data outside the system boundary
Data Flow	Arrow with label	Movement of data between elements

DFD Levels

DFDs are organized hierarchically, with each level providing more detail:

┌─────────────────────────────────────────────────────────┐
│ Context Diagram (Level -1)                               │
│                                                          │
│  ┌──────────┐    order     ┌──────────┐   receipt       │
│  │ Customer  │────────────►│  Order    │──────────►      │
│  │ (External)│◄────────────│  System   │   ┌──────────┐ │
│  └──────────┘  confirmation│ (Process) │──►│ Warehouse│ │
│                             └──────────┘   │ (External)│ │
│                                            └──────────┘ │
│  Shows: entire system as ONE process                     │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ Level 0 Diagram                                          │
│                                                          │
│  ┌──────────┐  order   ┌─────────┐  valid   ┌────────┐ │
│  │ Customer  │────────►│ 1.0     │  order   │ 2.0    │ │
│  │           │         │ Validate │────────►│ Process │ │
│  └──────────┘         │ Order   │         │ Payment │ │
│                        └─────────┘         └───┬────┘ │
│                             │                   │      │
│                        error│              payment     │
│                             ▼              info │      │
│                        ┌─────────┐              ▼      │
│                        │ D1:     │         ┌────────┐ │
│                        │ Error   │         │ 3.0    │ │
│                        │ Log     │         │ Fulfill │ │
│                        └─────────┘         │ Order  │ │
│                                            └───┬────┘ │
│  Shows: major processes within the system       │      │
│                                           shipment    │
│                                            info │      │
│                                                 ▼      │
│                                           ┌──────────┐ │
│                                           │ Warehouse│ │
│                                           └──────────┘ │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ Level 1+ Diagrams                                        │
│                                                          │
│  Explodes a single Level 0 process into sub-processes.   │
│  E.g., "1.0 Validate Order" becomes:                     │
│                                                          │
│  ┌─────────┐ order  ┌─────────┐ checked  ┌─────────┐   │
│  │ 1.1     │───────►│ 1.2     │────────►│ 1.3     │   │
│  │ Check   │        │ Verify  │          │ Confirm │   │
│  │ Syntax  │        │ Stock   │          │ Price   │   │
│  └─────────┘        └────┬────┘          └─────────┘   │
│                          │                              │
│                     ┌────▼────┐                          │
│                     │ D2:     │                          │
│                     │ Inventory│                          │
│                     │ DB       │                          │
│                     └─────────┘                          │
└─────────────────────────────────────────────────────────┘

DFD Rules

All data flows must be labeled. Unlabeled arrows are ambiguous.
No data flow between two external entities. The diagram models the system, not the outside world.
No data flow between two data stores. Data movement requires a process.
Every process must have at least one input and one output. A process with no inputs is a "miracle"; a process with no outputs is a "black hole."
Data stores must connect to processes, not external entities. External entities interact through processes.
Level numbers must be consistent. Sub-processes of Process 1.0 are 1.1, 1.2, 1.3, etc.

DFD in Mermaid Syntax

Mermaid does not have native DFD support, but flowchart syntax can represent DFD concepts:

mermaid

flowchart LR
    %% External Entities (rectangles)
    Customer[Customer]
    Warehouse[Warehouse]

    %% Processes (rounded)
    P1([1.0 Validate Order])
    P2([2.0 Process Payment])
    P3([3.0 Fulfill Order])

    %% Data Stores (cylinder shape for databases)
    D1[(D1: Orders DB)]
    D2[(D2: Inventory DB)]

    %% Data Flows
    Customer -->|order| P1
    P1 -->|valid order| P2
    P1 -->|order record| D1
    P2 -->|payment confirmation| P3
    P3 -->|stock query| D2
    D2 -->|availability| P3
    P3 -->|shipment request| Warehouse
    P1 -->|confirmation| Customer

Functional Decomposition

Functional decomposition breaks a system into hierarchical sub-functions. Each level reveals more detail about how a function is accomplished.

Decomposition Tree Structure

┌──────────────────────────────────────────┐
│         Order Management System           │
│              (Level 0)                    │
└──────────────┬───────────────────────────┘
               │
    ┌──────────┼──────────────┬─────────────────┐
    │          │              │                  │
    ▼          ▼              ▼                  ▼
┌────────┐ ┌────────┐  ┌──────────┐      ┌──────────┐
│ Receive│ │ Process│  │ Fulfill  │      │ Manage   │
│ Order  │ │ Payment│  │ Order    │      │ Returns  │
│ (1.0)  │ │ (2.0)  │  │ (3.0)   │      │ (4.0)    │
└───┬────┘ └───┬────┘  └────┬─────┘      └────┬─────┘
    │          │             │                  │
  ┌─┼─┐     ┌─┼─┐       ┌──┼──┐           ┌──┼──┐
  ▼ ▼ ▼     ▼ ▼ ▼       ▼  ▼  ▼           ▼  ▼  ▼
1.1 1.2    2.1 2.2     3.1 3.2 3.3       4.1 4.2 4.3
Val Cap    Auth Rec    Pick Pack Ship    Auth Proc Ref

Decomposition Guidelines

Stop decomposing when a function is simple enough to be implemented as a single unit of work.
Each parent function should decompose into 2-7 child functions. Too few suggests unnecessary hierarchy; too many suggests the parent is not well-defined.
Naming convention: Use verb-noun pairs (e.g., "Validate Order", "Process Payment", "Ship Package").
Maintain consistency: All children at the same level should be at the same granularity.

Functional Decomposition in Mermaid

mermaid

flowchart TD
    A[Order Management System]
    A --> B[1.0 Receive Order]
    A --> C[2.0 Process Payment]
    A --> D[3.0 Fulfill Order]
    A --> E[4.0 Manage Returns]

    B --> B1[1.1 Validate Order]
    B --> B2[1.2 Capture Order Details]
    B --> B3[1.3 Confirm Order]

    D --> D1[3.1 Pick Items]
    D --> D2[3.2 Pack Order]
    D --> D3[3.3 Ship Package]

IDEF0 (Integration Definition for Function Modeling)

IDEF0 models functions (activities, processes, operations) and the data/objects that inter-relate those functions. Each function is represented as a box with four types of arrows.

ICOM Convention

        Controls (top)
            │
            ▼
    ┌───────────────┐
    │               │
Inputs ──►│   Function    │──► Outputs
(left)    │               │    (right)
    └───────┬───────┘
            │
            ▲
        Mechanisms (bottom)

Arrow Position	Name	Description	Example
Left (entering)	Inputs	Data or objects transformed by the function	Raw order data
Top (entering)	Controls	Conditions, rules, or constraints that govern the function	Business rules, regulations
Right (exiting)	Outputs	Data or objects produced by the function	Validated order
Bottom (entering)	Mechanisms	Resources that perform the function	Staff, software, equipment

IDEF0 Example: Process Customer Order

              Business Rules     Pricing Policy
                   │                  │
                   ▼                  ▼
              ┌──────────────────────────────┐
              │                              │
Customer  ──►│    Process Customer Order     │──► Confirmed Order
Order         │          (A0)                │──► Invoice
              │                              │──► Shipment Request
              └──────────────┬───────────────┘
                             │
                  ┌──────────┼──────────┐
                  ▲          ▲          ▲
              Order Mgmt   ERP       Warehouse
              Team        System     Staff

IDEF0 Decomposition

Like DFDs, IDEF0 diagrams decompose hierarchically:

A-0: Top-level context diagram (single box)
A0: First decomposition (3-6 child functions)
A1, A2, ...: Further decomposition of each function

A-0: Process Customer Order
 └── A0 Decomposition:
      ├── A1: Validate Order
      ├── A2: Check Inventory
      ├── A3: Calculate Pricing
      ├── A4: Process Payment
      └── A5: Initiate Fulfillment

IDEF0 Rules

Each function box must have at least one control and one output. Inputs and mechanisms may be optional.
3-6 functions per diagram. Too few does not add value; too many becomes unreadable.
Arrows between boxes model data/object flow. An output of one function can become the input or control of another.
Boundary arrows connect to parent diagram arrows via ICOM codes.
Node numbering: A0 decomposes to A1-A6; A1 decomposes to A11-A16; etc.

IDEF0 in Mermaid

mermaid

flowchart LR
    subgraph Controls
        BR[Business Rules]
        PP[Pricing Policy]
    end

    subgraph Inputs
        CO[Customer Order]
    end

    subgraph "A0: Process Customer Order"
        A1([A1: Validate Order])
        A2([A2: Check Inventory])
        A3([A3: Calculate Pricing])
        A4([A4: Process Payment])
        A5([A5: Initiate Fulfillment])
    end

    subgraph Outputs
        CF[Confirmed Order]
        INV[Invoice]
        SR[Shipment Request]
    end

    subgraph Mechanisms
        OT[Order Mgmt Team]
        ERP[ERP System]
        WS[Warehouse Staff]
    end

    CO --> A1
    BR --> A1
    BR --> A3
    PP --> A3
    A1 -->|valid order| A2
    A2 -->|stock confirmed| A3
    A3 -->|priced order| A4
    A4 -->|paid order| A5
    A5 --> CF
    A4 --> INV
    A5 --> SR
    OT -.-> A1
    ERP -.-> A2
    ERP -.-> A3
    ERP -.-> A4
    WS -.-> A5

BPMN (Business Process Model and Notation)

BPMN is an ISO standard (ISO/IEC 19510) for graphically representing business processes. It is the most widely used process modeling notation.

Core BPMN Elements

Flow Objects

Element	Symbol	Description
Task	Rounded rectangle	An atomic activity within a process
Sub-Process	Rounded rectangle with +	A compound activity containing a nested process
Event (Start)	Thin circle	Indicates where a process begins
Event (Intermediate)	Double circle	Occurs between start and end
Event (End)	Thick circle	Indicates where a process ends
Exclusive Gateway (XOR)	Diamond with X	Decision point, only one path taken
Parallel Gateway (AND)	Diamond with +	All paths are taken simultaneously
Inclusive Gateway (OR)	Diamond with O	One or more paths taken
Event-Based Gateway	Diamond with pentagon	Path determined by event occurrence

Swimlane Elements

Element	Description
Pool	A container representing a participant (organization, system, role)
Lane	A sub-partition within a pool, typically representing a specific role or department

Connecting Objects

Element	Description
Sequence Flow	Solid arrow showing order of activities within a pool
Message Flow	Dashed arrow showing communication between pools
Association	Dotted line connecting data objects or annotations to flow objects

Data Elements

Element	Description
Data Object	Information required or produced by a task
Data Store	A persistent repository

BPMN Example: Order Fulfillment Process

┌──────────────────────────────────────────────────────────────────────┐
│ Pool: Order Fulfillment                                               │
│                                                                       │
│ ┌─────────────────────────────────────────────────────────────────┐  │
│ │ Lane: Sales                                                      │  │
│ │                                                                  │  │
│ │  (○)──►[Receive Order]──►<X>──►[Send Confirmation]──►           │  │
│ │  Start                   │                                       │  │
│ │                     invalid                                      │  │
│ │                          │                                       │  │
│ │                          ▼                                       │  │
│ │                   [Reject Order]──►(●)                           │  │
│ │                                   End                            │  │
│ └──────────────────────────────────┼──────────────────────────────┘  │
│                                     │ valid                          │
│ ┌──────────────────────────────────▼──────────────────────────────┐  │
│ │ Lane: Warehouse                                                  │  │
│ │                                                                  │  │
│ │  [Pick Items]──►[Pack Order]──►[Ship Order]──►(●)               │  │
│ │                                                End               │  │
│ └──────────────────────────────────────────────────────────────────┘  │
│                                                                       │
│ ┌──────────────────────────────────────────────────────────────────┐  │
│ │ Lane: Finance                                                    │  │
│ │                                                                  │  │
│ │  [Process Payment]──►<X>──►[Issue Invoice]──►(●)                │  │
│ │                       │                      End                 │  │
│ │                  failed│                                          │  │
│ │                       ▼                                          │  │
│ │                [Escalate to Manager]──►(●)                       │  │
│ │                                       End                        │  │
│ └──────────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────┘

Legend: (○) = Start Event, (●) = End Event, <X> = Exclusive Gateway
        [Task] = Task/Activity

BPMN in Mermaid

Mermaid does not have native BPMN support, but flowchart syntax can approximate BPMN processes:

mermaid

flowchart TD
    Start((Start)) --> ReceiveOrder[Receive Order]
    ReceiveOrder --> ValidCheck{Valid?}
    ValidCheck -->|Yes| SendConfirmation[Send Confirmation]
    ValidCheck -->|No| RejectOrder[Reject Order]
    RejectOrder --> EndReject((End))

    SendConfirmation --> Fork{Parallel}
    Fork --> PickItems[Pick Items]
    Fork --> ProcessPayment[Process Payment]

    PickItems --> PackOrder[Pack Order]
    PackOrder --> ShipOrder[Ship Order]
    ShipOrder --> Join{Join}

    ProcessPayment --> PayCheck{Payment OK?}
    PayCheck -->|Yes| IssueInvoice[Issue Invoice]
    PayCheck -->|No| Escalate[Escalate to Manager]
    Escalate --> EndEsc((End))
    IssueInvoice --> Join

    Join --> EndSuccess((End))

Choosing the Right Functional Diagram

Diagram Type	Best For	Not Suitable For
DFD	Data transformation analysis, system boundaries, data store identification	Process timing, organizational roles
Functional Decomposition	Breaking complex systems into manageable pieces, scope definition	Data flow, process sequencing
IDEF0	Understanding function constraints and resources, manufacturing and engineering processes	Simple workflows, quick communication
BPMN	Business process documentation, workflow automation, cross-department handoffs	Data modeling, system architecture

Combining Functional Diagram Types

These diagram types are complementary:

Functional Decomposition Tree
    │
    │ identifies functions to model
    ▼
IDEF0 Diagrams
    │
    │ identifies data transformations
    ▼
Data Flow Diagrams
    │
    │ identifies processes to orchestrate
    ▼
BPMN Process Models

Start with Functional Decomposition to identify the major functions of the system.
Use IDEF0 to understand the inputs, outputs, controls, and mechanisms of critical functions.
Create DFDs to trace how data moves through and between the functions.
Model in BPMN when the focus shifts to implementing business processes with specific roles and decision logic.

Best Practices

Start at the context level. Whether using DFD or IDEF0, begin with a single-process context diagram before decomposing. This establishes scope and boundaries.
Maintain level consistency. All processes at the same decomposition level should be at the same granularity. Do not mix high-level and detailed processes on the same diagram.
Label every data flow. Unlabeled arrows are the most common DFD error and make diagrams ambiguous.
Limit elements per diagram. Follow the 3-7 process guideline per decomposition level. More than 7 processes on a single diagram reduces readability.
Use verb-noun naming for processes. "Validate Order", "Calculate Tax", "Ship Package" — not "Order Validation" or "Tax Module."
Distinguish between data flow and control flow. In DFDs, arrows represent data movement. In BPMN, arrows represent sequence flow. Do not mix paradigms on a single diagram.
Validate data conservation. All data entering a process must either be output or stored. Data does not appear or disappear inside processes.
Use BPMN pools for organizational boundaries. Each pool represents a distinct participant. Use lanes within pools for roles or departments.
Use Mermaid flowcharts as a practical approximation. While Mermaid does not natively support DFD or IDEF0 notation, flowchart syntax captures the essential structure and is renderable in documentation platforms.
Cross-reference between diagram types. When using both DFDs and BPMN, ensure process names and data labels are consistent across all diagrams. A process called "Validate Order" in the DFD should have the same name in the BPMN model.

functional-diagrams

NPX Install

Tags

SKILL.md Content

Functional Diagrams

Overview

Data Flow Diagrams (DFD)

DFD Elements

DFD Levels

DFD Rules

DFD in Mermaid Syntax

Functional Decomposition

Decomposition Tree Structure

Decomposition Guidelines

Functional Decomposition in Mermaid

IDEF0 (Integration Definition for Function Modeling)

ICOM Convention

IDEF0 Example: Process Customer Order

IDEF0 Decomposition

IDEF0 Rules

IDEF0 in Mermaid

BPMN (Business Process Model and Notation)

Core BPMN Elements

Flow Objects

Swimlane Elements

Connecting Objects

Data Elements

BPMN Example: Order Fulfillment Process

BPMN in Mermaid

Choosing the Right Functional Diagram

Combining Functional Diagram Types

Best Practices