需求描述：為了向資料工程師清楚表達需求，並且將概念化作文件供檢視以及日後參考，需要一個通用的規範來做這件事。
元件符號
- 實體 Entity：資料的來源（Source）或是目的地（Sink）。
2. 處理工作 Process：將 input 根據商業邏輯產生 output 的運算元件。
3. 資料儲存 Data Store：儲存資料的元件。
4. 資料流 Data Flow：資料流的移動路線，連結上面三個元件間的線條。
圖示上有下面兩種標示方式，個人是覺得差異不大只要團隊有共識能夠溝通就好，不過稍微看了一下似乎 Gane and Sarson 比較多人用（?）。
由這些元件構成一張資料流程圖（Data Flow Diagram），然而為求表達清楚，我們會將資料流程圖分成幾個層級來呈現。
層級
資料流程圖會分成好幾個層級（Level），從 0 開始編號，接著為 1, 2, 3 …，視系統複雜度而定，但一般不超過 3。其編號順序是一種循序漸進的概念，從整體到細部、從抽象到具體，不過一定要包含 Level 0 的環境圖。
Level 0 資料流程圖：又稱環境圖（Context Diagram），是整個系統的工作處理摘要圖，主要目的是讓人一目瞭然系統的資料流程，一般而言不包含資料儲存（Data Store）元件。
原則
- 可讀性：一個畫面說完流程。資料流（Data Flow）的線條不交叉。
- 一致性：每個處理工作（Process）至少包含各一個輸入與輸出，檢視是否有不必要的資料輸入、是否有不可能的資料輸出。
- 正確性
工具
個人工作上還是用 Google 的 Draw.io，方便團隊存取。不過這篇文章參考的 Lucidchart 也許也可以試試看。
資料辭典（Data Dictionary）
開始工作後，深深體會到文件的重要性，而資料辭典（Data Dictionary）就是將所有在資料流程圖（Data Flow Diagram）出現的元件列出來，並將每個元件的目的、定義、說明訴諸文字，在表達上有一些通用的符號：
- +：和
- [ a, b, c]：a 或 b 或 c
- a + (b)：a 或是 a + b
- =：等於
- { a }5：5 個 a 資料
- { b }*：0 或多個 b 資料
- /* comment */：註解
除了上面提到的四個元件，還必須包含資料元素以及資料結構。資料元素為資訊系統中有意義的最小單位，一般我們稱為欄位（field），而資料元素結合後則為資料結構。以上這些元件，在文件上所需包含的內容如下：
資料元素
- 欄位名稱
- 資料型態及長度
- 預設值
- 定義及說明
資料結構
- 資料結構名稱
- 定義及說明
- 屬性
- 資料來源
- 負責工程師
資料儲存
- 資料儲存名稱
- 定義及說明
- 屬性
- 數量
- 頻率
資料流
- 資料流名稱
- 定義及說明
- 起源
- 去處
- 頻率
實體
- 實體名稱
- 定義及說明
- 輸入資料流
- 輸出資料流
處理工作
- 處理工作名稱
- 定義及說明
- 編號
由於處理工作上需要比較複雜的邏輯，因此一般會佐以流程控制圖（Control Flow Diagram）做進一步說明，大概長這樣：
其中，矩形代表處理工作，菱形代表條件判斷，邏輯依循線條的箭頭方向行進。其他似乎還有其他方式，但個人在工作實務上主要是使用這個方法。
以上，是在了解資料流程圖的簡單筆記。
參考資料
http://wayne.cif.takming.edu.tw/SE/peter/dfd.pdf
http://web.ydu.edu.tw/~alan9956/docu3/0992sa/sa04_dfd.pdf
https://nptel.ac.in/courses/Webcourse-contents/IIT%20Kharagpur/Soft%20Engg/pdf/m05L10.pdf