使用 UML 進行需求分析

在專案開始開發之前，必須要做的階段就是「需求分析」， 這個階段的主要工作內容包含：資料蒐集、需求分析以及撰寫需求報告書。 本文將依以下內容來說明：

• 系統領域分析（domain analysis）
• 如何擷取需求
• 整理需求分析
• 撰寫軟體需求規格書 (Software Requirement Specification, SRS)

系統領域分析

一個計劃，若一開始就沒有切確掌握系統需求，往往是失敗的主要原因。 「領域分析」的目的，就是要由各個層面來蒐集專案的需求， 你可以針對不同單位的使用者實際進行訪談，以瞭解各種業務的操作流程。

領域分析也同時帶給你以下幾點好處：

1. 更有效率的和客戶溝通
   因為對客戶的 domain-knowloege 愈是了解，彼此在溝通上就會愈有共識，避免雞同鴨講的情況發生。
2. 協助系統開發
   了解企業實際的作業流程，將有助對於日後的系統設計與規劃。 尤其是客戶的企業邏輯和商業規則（Business Logic and Business Rule），如果沒有確認清楚，日後的設計必定漏洞百出。
3. 預留新系統的開發空間
   當更深一層了解到客戶業務之後，你可以觀察他們既有的系統，或者現行的作業方式，提供能夠提升效率、降低成本等建議，以為另外一個計劃做準備。

如何擷取需求

領域分析即然那麼重要，那麼該要如何去了解需求呢？你可以針對以下幾個方向著手：

• 既有的表單與報表
• 訪談
• 開會討論
• 其他
  資料查詢、問卷調查、觀察..

整理需求分析

當透過各種需求擷取方式所取得的需求資訊，我們必須將其做適當的整理與分析，以避免雜亂無章。 你可以依據以下原則來進行：

需求分類

功能需求

功能需求就是系統該提供給使用者的服務。

非功能需求

非功能需求指的是和系統執行效率相關之需求，以下幾點是 RUP 中所列的參考項目：

• 回應時間
• 執行效能
• 維護性
  說明可增進日後系統維護的相關項目，例如編碼原則、命名規則等。
• 使用性
  描述對一個正常使用者所需之訓練時間。
• 可靠度
  可靠度包含許多要項，最常見的是描述系統的失敗率。

需求描述

對於需求描述，你應該以使用者的觀點出發，並用淺顯易懂的句子來描述，勿長篇大論，也不要太抽象。 例如對一個線上購書專案，你可以列出以下需求描述：

• 允許使用者瀏灠及查詢電影相關資訊。
• 允許使用者加入會員。
• 允許會員進行線上預購電影票。

另外，像「實現線上購書流程自動化」這類的描述就太過於抽象化，對於日後的分析工作較無實質幫助，它出現的地方應該是在計畫書中，而不是在需求分析描述。

事件表

什麼是事件

在一個搜尋書籍資料的功能中，使用者在輸入查詢條件後，必須按下按鈕，系統才會開始搜尋。 同樣的，在一個 ATM 系統中，使用者也必須製造某些事件來告訴系統你到底想要做什麼，例如提款、存款等等。 由此看來，事件和功能是一體兩面的概念。

對於功能的需求描述，我們可以將它歸納成事件，並且儘量以：主詞+動詞+(受詞)的形式來描述事件的名稱。

撰寫事件表

事件表主要是用來歸納整理所有的事件，它包含的欄位有：

事件名稱	觸發器	來源	活動	回應	目的地

• 事件名稱：以主詞+動詞+(受詞)的形式，寫出要系統去完成的某項功能。
• 觸發器：代表引發事件的資料
• 來源：代表資料的來源。
• 活動：當事件發生時，系統所需要執行的動作，例如新增…、查詢…、修改…、刪除…等
• 回應：處理之後所產生的輸出資料。
• 目的地：輸出資料的目的地

範例一：

對於一個線上購書系統，最明顯的事件就是「顧客下訂單」。 在這個事件中，由於訂單是由顧客下的，所以來源就是顧客； 系統應該產生一筆新的訂單資料，以記錄這個活動。 而「訂單編號」就是這個活動的回應，目的地當然就是使用者。

事件名稱	觸發器	來源	活動	回應	目的地
顧客下訂單	訂單	顧客	產生一筆新的訂單資料	訂單編號	使用者

若訂單有需要交由客服部門來處理，你也可以將事件表改寫如下：

事件名稱	觸發器	來源	活動	回應	目的地
顧客下訂單	訂單	顧客	產生一筆新的訂單資料	訂單編號	使用者 客服部門

若訂單成功之後，必須以 email 回應使用者，你也可以將事件表改寫如下：

事件名稱	觸發器	來源	活動	回應	目的地
顧客下訂單	訂單	顧客	產生一筆新的訂單資料	email 訂單明細	使用者

範例二：

同樣的方法，若針對書籍查詢的功能，你可以使用以下事件表示法：

事件名稱	觸發器	來源	活動	回應	目的地
顧客搜詢書籍	搜詢請求	顧客	搜詢書籍	符合條件的書籍資料	顧客

範例三：

假如在需求分析時，你發現到系統必須產生月報表，它是一個以「時間」為觸發條件的需求，而且，與上面例子不同的是，它的事件要求是來自於系統，是一種內部的實體，而不是外部實體。 對於這樣的事件可以使用以下事件表示法：

事件名稱	觸發器	來源	活動	回應	目的地
產生月報表	時間	系統	產生月報表	月報表	經理

詞彙表

事件表是用來描述系統應該提供的功能，這當中必定包含許多與domain相關的資料與概念，此時就可以利用詞彙表將其記錄整理起來。

詞彙表內容擷取的方向如下：

• 捕捉所有出現於需求描述的所有名詞。
• 捕捉所有出現於事件表中的所有名詞。
• 捕捉必須要表現在表單或報表中所需要的相關資料。

詞彙	解釋	附註
登入資料	帳號、密碼
訂單	包含客戶資料、訂購項目
客戶資料	客戶編號、姓名、住址、電話、Email
訂購項目	訂購編號、書籍編號、數量
書籍資料	書籍編號、書籍名稱、作者、摘要

撰寫軟體需求規格書

軟體需求規格書（Software Requirement Specification, SRS）是系統分析過程後的產出，這份文件是用來提供日後系統開發的參考依據。 它並沒有制式的規格，可能隨著不同公司而有不同的規定，記載的內容也不盡相同。有時候它會被要求包含資料庫的結構模型，或者包含使用者介面等等。 不管其內容如何，最重要的是，這份需求文件，必須在最後階段經過客戶與廠商雙方的驗證與確認，如此才能進行接續的工作。

底下是 RUP 提供的一個軟體需求規格書樣版，可用來記錄系統的需求，其記載項目如下：

• 系統目標
• 系統範圍
• 系統整體描述
• 功能需求
• 非功能需求
• 系統所需提供之使用者、軟體、硬體等切面之需求
• 其他資料

PS. SRS 有另外一個專業名稱，叫做「系統需求規格書」（System Requirement Specification）