前言

要能建構一份有效的使用案例需求模型 (Use Case Model)，比想像中得難，使用案例是 “易學難精”，只是那麼幾個簡單的圖形元素來畫使用案例圖、以及僅用白話的文字敘述來紀錄使用案例的需求描述，但是，若沒有把持使用案例最根本的原則與精神，真的很難寫得好。筆者在諸多 IT 單位的顧問輔導經驗中，所看到多個單位所 “畫” 出的使用案例，10 個中就有8個有問題，探究其中最大的問題，在於寫使用案例的需求分析人員，很難擺脫掉 “既有傳統” 的束縛，例如會從企業流程 (Business Process) 的觀點來分析使用案例，或者是馬上就聯想到系統內部的實作問題，包括權限控管等問題。筆者常開玩笑的說，要能寫好使用案例，最好本身就是 “無知”，不知道企業流程的邏輯判斷規則、”看不到” 系統內部是如何實現(Realize)使用案例的。奇怪的是，要能 “逼” 自己 “無知”，對系統需求分析人員好像很難，而且往往就是在不知不覺中，就把既往對 “領域” 與 “平台” 的知識給表達在使用案例中，事實上，根本就是把使用案例當成是 “另一種” 需求記錄的工具而已。

很是可惜，筆者一直認為，使用案例絕對是以 “專案型態(Project-based)” 開發的最有效利器，它表達的就是 “純粹” 的資訊系統 “局部” 功能觀點的需求模型，只要能寫好使用案例，甚至在不需要作系統內部結構分析的情況下，馬上就可以轉移至程式碼的實作階段，而且是很快速直覺。再利用分析層次的類別 (analysis class)，就可以建構符合三層 (3-tier) 結構的 MVC 模型，有效隔離 UI 與資料庫的變動性，同時，再加上一個極為重要的手段：
”對每一個使用案例”，都加上能驗證功能的測試程式碼！” 如此在每一次的功能需求變動，都能提醒開發人員注意變動的影響部分，包括功能測試碼也跟著要修正。

為了順應短線的專案開發生態，快速實現「使用案例」，馬上導出至系統的實作，是最有效與最現實的手段。然後加上兩個配套的措施，以確保專案的品質：以使用案例為單位，撰寫功能測試程式碼；利用分析類別，建構符合 MVC 的三層實體框架，以隔離 UI 與 資料庫的變動。

而當第一個釋出(release)的專案能滿足系統的功能需求後，因此而能取得更多的開發資源，以及開發人員的溝通默契與技能逐漸成熟後，且已有基本的框架結構，此時再針對程式碼施以重構(refactoring)，以及對結構作重整(refine)，兩者是屬於系統內部結構分析的範疇，如此而更有機會成為可再利用性高價值的產品(Product)。

所以，如何寫出有效能確實表達系統功能觀點的使用案例，可以說是專案開發成功與否最重要的關鍵。但如同前述，使用案例是「易學難精」，在此筆者列出幾個比較常見的問題，再以簡單的三言兩語來說明為何這些是問題、SA 大概是以什麼角度、假設點在分析使用案例的，然後筆者再提供修正後的建議。底下的每一個問題，是經過簡化，實際的案例，大部分是同時有著眾多下述的問題合著來的，而開發團隊卻經常有茫點，而無法理出問題會是在哪裡。

1、從企業流程的觀點描述使用案例之間的關係

問題：
這幾乎是因為太清楚領域知識與業務流程的 “資深 SA” 所畫出來的，經常都會把使用案例當成是企業流程的活動(activity)，然後 “想辦法” 將這些使用案例依據業務流程的規則與順序給 “串起來”。請記得！！ 使用案例是不表達業務流程的，業務流程的表達，會利用如活動圖(activity diagram)來描述，使用案例僅僅是表達參與者在某個時間點使用系統的局部功能觀點。

圖1、問題—從企業流程的觀點描述使用案例之間的關係

修正：
絕對不要把業務流程的觀點給表達在使用案例的，就是老老實實，根據參與者希望系統該提供 “哪些系統功能”，這些功能，就會成為一個個的使用案例。

圖2、修正—只 “老老實實” 表達局部功能觀點的使用案例

2、模組化的分析思維

問題：
這也是分析使用案例相當常見的老問題。SA 將以往模組化(modular)，也就是以功能樹(functional tree) 的分析思維，將大功能逐層分解成一個個的小功能，然後只是利用使用案例來取代傳統的模組化的表達而已。

圖3、問題—利用使用案例來表達模組化的分析思維

修正：
模組太大了，無法成為有效、以使用案例為單位的功能點(functional point)。使用案例的單位要能符合 “S.M.A.R.T” 原則，也就是 " Specific(具體的)”、”Measurable(可測量的)”、” Accurate(精確的)”、”Reachable(可達成的)”、"Time-limit(有時限的)”。更簡單的說，每一個使用案例都是可以個別在某個時間點內，系統能履行功能來滿足參與者使用系統的目的。

另外一點要注意的是，圖 3 SA 不一定會畫出 “主檔維護作業” 這個大模組的使用案例，但是，若將使用案例命名為如 “人事主檔作業”、”出差勤作業” 等，SA 的心中，八九不離十，仍是模組化的思維。使用案例的命名法則，一定是 “動詞+名詞”，充分能表達出系統 “What(goal) can I(system) do for you(actor)” 的目標。所以使用案例的命名，一定會是 “維護人事資訊”、”維護出差勤資訊” 等。這好像是細節？ 但其實往往命名就能反應出 SA 的想法、假設點等分析思維的。

圖4、修正—符合 S.M.A.R.T 原則的使用案例

3、權限檢核的 “How-to” 思維

問題：
這幾乎是 “Coding 人員” 兼當 SA 的作品。在分析使用案例時，馬上就聯想到系統的實作，包括權限控管、交易控管、企業邏輯等條件判斷這些諸多實作面 “How-to” 的問題。

圖 5、問題—分析使用案例時，馬上聯想到實作面的議題

修正：
資訊系統層級的使用案例會以 “黑箱(black-box)” 來看待系統，使用案例的敘述只專注在參與者與系統之間的互動對話過程(session)，系統的實作，會是留待在系統內部的結構分析與設計上的階段，例如，在循序圖的設計階段時，才會來描述實作面上所關注的議題，如本題 “權限檢核”、或者 “2-phase commit” 交易控管的問題。事實上，”誰(actor)” 來使用該使用案例，就多少已經隱含了權限控管的考量了，例如，行政人員可以 “維護員工資訊”，但員工卻沒有權限來使用該使用案例。

圖 6、修正—不要在使用案例中表達系統實作面的設計

4、系統本身當參與者(Actor)

問題：
當 SA 發現到系統需要在某個時間點，要能 “自動” 執行某個使用案例時，會以為系統本身就是參與者。ERP 的系統作業，例如日結帳、月結算、批次處理等相關作業，相當常見到這類型的案例。

圖 7、問題—開發的系統，本身又當成呼叫自己的參與者

修正：
回到 “參與者(actor)” 的最基本定義，參與者只有兩種，一個是使用系統的使用者，另一個是外部的系統，所以，在開發範圍中的系統，不可能自己又是擔任外部的參與者角色，會 ”自動” 觸發使用案例的參與者，其實是外部系統，例如 “Timer”、”排程系統(schedule system)” 等。請注意，在分析使用案例時，最好能將系統範圍(system boundary)界定並表達出來，如下圖，就很清楚開發的系統是財會系統，如此也比較能避免掉 SA 不知不覺就把開發的系統又當成是呼叫自己的參與者這樣的謬誤。

圖 8、修正—界定系統設計範圍，確實釐出系統的參與者

5、子系統(sub-system)的定義不明確

問題：
下圖乍看之下沒有問題，但筆者一定會就此圖問 SA 與系統架構的開發人員，是否未來在 ERP 系統的開發，有確實將「財務管理系統」分離成為獨立的一個模組(Module)，也就是說，ERP 系統必然只能透過介面(interface)來呼叫「財務管理子系統」所提供的 APIs(Application Programming Interfaces)，而不能直接連接該子系統的私有資料庫。但幾乎所得到的答案，都是沒有所謂的介面設計的觀念。將「財務管理」規劃為子系統是因為業務面的需要，是依照功能來規劃 ERP 會有哪幾個子系統(或者稱之為模組)，但那僅此於業務面的邏輯區分，在實體的資訊系統中，並沒有界定這些子系統(或模組)之間，是透過介面的訊息溝通傳遞。

圖 9、問題—子系統的定義不明確

修正：
既然在實體上，並沒有確實抽離「財務管理系統」，那麼，系統的開發範圍就必然是在 ERP 單一一個系統的範疇之內，也就是沒有「財務管理」這個外部的系統參與者；同樣地，也沒有所謂的「銷售子系統」來呼叫 ERP 系統(透過介面的呼叫)，以下圖的使用案例為例，參與者其實是排程系統。

圖 10、修正—業務邏輯面的子系統，並不能成為 ERP 系統的外部參與者