Data Flow Fields
1. Description
-
What it’s for: A narrative overview of this data flow — what data moves, between which components, and why.
-
What to include:
- The source and destination of the data.
- What the data represents and why it needs to flow.
- Any key processing or transformation at a high level (detail goes in the Data Mapping tab).
- The business process or event that triggers or relies on this flow.
-
Example:
"Supplier invoice data received from the EDI gateway is validated, enriched with purchase order references, and loaded into the ERP Accounts Payable module. This flow supports the automated invoice matching process and replaces the current manual email-and-spreadsheet process."
2. Sizing
-
What it’s for: The volume characteristics of this data flow — how much data is involved.
-
What to include:
- Number of records per run or per day.
- File sizes or payload sizes if applicable.
- Peak vs average volumes if they differ significantly.
- Any growth expectations over the life of the solution.
-
Example:
"Average 200 invoices per day; peak 1,500 at month-end. Each invoice record is approximately 2KB. Expected 15% annual growth in invoice volume."
3. Frequency
-
What it’s for: How often this data flow occurs.
-
What to include:
- The trigger: scheduled (include interval), event-driven, real-time, or on-demand.
- For scheduled flows: the schedule and any blackout windows.
- Any latency requirements (e.g. “must complete within 30 minutes of trigger”).
-
Example:
"Triggered by EDI gateway on receipt of each invoice batch; typically 4–6 batches per day during business hours. Month-end batches may arrive outside business hours and must be processed within 2 hours of receipt."
Relationships
Business Traceability
| Relationship | What to link |
|---|---|
| Supports Business Requirement | Business Requirements that this data flow helps to satisfy |
| Supports Non-Functional Requirement | Non-Functional Requirements — throughput, latency, data retention — that this flow addresses |
| Supports Transition Requirement | Transition Requirements that this flow helps to deliver (e.g. a migration flow) |
| Supports Business Process | Business Processes that this data flow supports or enables |
| Supports Business Scenario | Business Scenarios in which this data flow participates |
| Supports Business Outcome | Business Outcomes that this data flow contributes to |
| Implements Business Rule | Business Rules that this data flow enforces (e.g. data residency, transformation rules) |
| Implements Business Reference | Standards, policies, or regulatory documents that govern this data flow |
Data and Information
| Relationship | What to link |
|---|---|
| Uses Business Information | Business Information items that this flow carries or transforms |
| Uses Data Set | Data Sets — the structured data schemas — that are involved in this flow |
| Uses Data Store | Data Stores that this flow reads from or writes to |
Technical Components
| Relationship | What to link |
|---|---|
| Uses API | APIs through which this data flow is implemented |
| Uses Stream | Message queues or event streams used by this flow |
| Uses Service | Backend services that participate in this flow |
| Uses Technology | Technologies used to implement this flow (e.g. ETL tool, messaging platform) |
Quality Attributes
| Relationship | What to link |
|---|---|
| Uses Availability | Availability mechanisms applied to this flow (e.g. retry logic, failover) |
| Uses Recoverability | Recovery mechanisms in place if this flow fails (e.g. dead-letter queues, reprocessing) |
| Uses Performance | Performance mechanisms and targets for this flow |
| Uses Security | Security controls applied to data in transit (encryption, access control, audit logging) |
| Uses Deployability | Deployment patterns relevant to this flow |
| Uses Observability | Observability mechanisms — logging, monitoring, alerting — applied to this flow |
Acceptance and Testing
| Relationship | What to link |
|---|---|
| Has Acceptance Criteria | Business-level criteria for verifying this data flow works as intended |
| Has Implementation Acceptance Criteria | Technical criteria for verifying the implementation of this flow |
| Has Test Data | Test data sets used to test this flow |
RAID and Work
| Relationship | What to link |
|---|---|
| Has Assumption | Assumptions made about this data flow (e.g. assumed availability of source data, assumed API contract) |
| Has Risk | Risks associated with this flow (e.g. data quality risk, volume risk, latency risk) |
| Has Issue | Known issues affecting the definition or implementation of this flow |
| Has Task | Tasks assigned to this flow |
Design
| Relationship | What to link |
|---|---|
| Supports Design Decision | Design Decisions that are informed by or affect this data flow |