結構化分析
前言
結構化分析，是由資料流程圖開始，由上到下按資料流的處理程序，進行功能拆解，以邏輯概念的方式，達成並涵蓋所有的使用者需求。 本文的目的，便是介紹結構化分析過程中，可採用的各種表示方法，以及其運用方式與注意事項。
邱奕南，2009/8/12
資料流程圖（Data Flow Diagram，簡稱DFD）
資料流程圖，為結構化分析中最主要的圖形工具，以下為其最基本的圖例：
各圖形的意義為：
以下為資料流程圖實際運用的另一個例子：
以下為利用資料流程圖分析系統的過程：
以下則是在展開資料流程圖時的應注意事項：
資料詞典（Data Dictionary，簡稱DD）
資料詞典是用來定義與描述資料流程圖中出現的名稱，包括資料流、檔案、資料項、資料處理等。
（一）資料流定義
資料流的定義，皆使用資料描述記號描述。這些記號包括：
- =表前者由後者所組成。
- +表And。
- [ ]表多選一，項目間用|隔開。
- ( )表可有可無。
- x{ }y表重複出現x～y次，無x時表0，無y時表無限。
- * *表註解。
例如：
個人資料 = 姓名 + 性別 + 1{連絡電話} + (傳真電話) * 這是註解 *
性別 = [男 | 女]
（二）檔案定義
一般除非是特定格式的重要檔案才需要描述，否則皆交由系統設計師在設計時再依資料結構與演算法決定。以下為檔案定義應有的內容格式：
- 檔案名稱
- 組成：使用資料描述記號描述。
- 組織：描述檔案的存取方式及其資料架構。
（三）資料項定義
用以定義出現在資料流或檔案定義裡，具有特殊值域意義或限制的資料組成項目。一般的資料項，應交由系統設計師來決定其形態、結構與值域。以下為資料項定義應有的內容格式：
- 資料項名稱
- 值域及意義：描述各種值和它的意義。
（四）資料處理描述
描述資料流程圖裡各資料處理功能。以下為資料處理描述應有的內容格式：
- 資料處理功能的編號與名稱
- 輸入：應處理的輸入資料。
- 輸出：處理後應輸出的資料。
- 處理描述：描述應進行的資料處理、特殊的要求與限制。可使用結構化語言、決策圖（Decision Table）、決策樹（Decistion Tree）等工具描述。以能清楚描述應做的工作為原則，至於如何做的細節係在系統設計時才考量。
結構化語言，也稱為虛擬碼（Pseudo Code），是以自然語言做為描述的工具，但以結構化程式語言進行組織。亦即利用下列結構來組織自然語言：
- 循序（Sequence）
- 決策（Decision）：if-then-else、switch-case。
- 重複（Repetition）：for-loop、while-do、repeat-until。
以下則為決策表的一例：
條件一 Ｙ Ｙ Ｙ Ｎ Ｎ Ｎ
條件二 Ｌ Ｍ Ｈ Ｌ Ｍ Ｈ
動作一 Ｙ Ｙ Ｎ ？ ？ Ｎ
動作二 Ｎ Ｙ Ｎ ？ Ｎ Ｎ
決策樹和決策表相似，只是改用圖形的方式呈現而已。
資料流程圖的擴充
傳統的資料流程圖，並無法表示即時系統或控制系統的功能與行為，故有學者便提出了一些擴充資料流程圖形來達到此一需求。以下便是一個基本例子：
各圖形的意義為：
資料處理的時間次序
資料流程圖中並未指明各資料處理的先後次序，故當需要表示資料處理的執行次序或條件時，便必須採用其他圖形來輔助。
（一）流程圖（Flow Chart）
流程圖是最常用也最容易被理解的執行次序表示法，以下為其基本圖例：
各圖形的意義為：
（二）控制流程圖（Control Flow Diagram，簡稱CFD）
與流程圖獨立於資料流程圖之外不同，控制流程圖是基於資料流程圖的結果來標示控制流。也就是複製一份資料流程圖，然後將其中的資料流全數改成控制流（線形亦需變更為虛線）。 由於會有執行次序問題者，皆是資料處理有多個輸出資料流的情況，故只需針對這些輸出資料流，分別標上相對應的控制條件即可。 由於CFD與DFD有相同的圖形結構，故比流程圖更適合用來表示資料處理的次序。
（三）狀態轉移圖（State Transition Diagram，簡稱STD）
狀態轉移圖雖可用來定義資料處理的時間次序，但更常被用來定義系統的行為模式。首先定義出系統的各種狀態與應處理事務，再針對各狀態定義出各種事件，以及處理該事件的事務與最後應移轉的狀態。以下為一個簡單的列印系統STD例子：
狀態轉移圖也可用狀態轉移表的形式來表示。
實體關係圖（Entity-Relationship Diagram，簡稱ERD）
當系統有資料庫存取的需求時，多以下列步驟進行資料物件的關聯定義：
實體關係圖主要用來表示真實世界裡各事物（實體或物件）間的關係，其資訊的來源必須基於需求規格書，並與資料詞典相互配合。以下為其基本圖例：
各圖形的意義為：
以下則為一個應用例子：
對於太過複雜的ERD圖，為了方便閱讀，多會省略代表物件屬性的橢圓，而在方形實體物件裡或其他地方，直接以資料描述記號方式表示。例如前例中的課程屬性，便可寫成：
課程編號 + 上課時間 + 上課老師 + {選修學生}
需求回溯表
需求回溯表的目的有二，一是確認分析結果涵蓋全部的需求，一是在需求或功能變更時，可以得知會影響到那些功能或需求。需求回溯表的形式可有兩種：
以正向回溯表為例：
SR4.1.1: SF1.3.2.1.1, SF1.3.2.1.2
表示需求SR4.1.1是由資料處理功能SF1.3.2.1.1與SF1.3.2.1.2所完成。
參考文獻
