使用案例分析常見的幾個問題

前言

要能建構一份有效的使用案例需求模型 (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 的想法、假設點等分析思維的。

修正—符合 S.M.A.R.T 原則的使用案例
圖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 系統(透過介面的呼叫),以下圖的使用案例為例,參與者其實是排程系統。

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