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

前言

要能建構一份有效的使用案例需求模型 (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 系統的外部參與者

文章導覽

   

共有 12 則迴響

  1. Hello Partick:
    使用者的期望大致分為兩大類:1.business process, 2.system function.
    UC 並不足以表達 bp, 它適用於表達 end user 的系統功能;bp 利用活動圖來表達比較恰當。 而此兩者,往往是互補,是呈現兩種層次需求的工具。

    個人曾寫過這一篇文章,您可以參考並歡迎提問之。 🙂
    http://www.kenming.idv.tw/index.php?title=a_cc_uaf_aysafic_uai_af_eu_e_af_aysam_cu&more=1&c=1&tb=1&pb=1

  2. What I think is if use case does not directly represent business process, it would centainly create gaps between the actual user and the end product (either software or system). The most common situation is the user’s expectation (from the business process point of view) has not included or partially included in functionality.

    In the experience of recent project I paticipated, I could see there was huge gap in end user’s expectation and the actual system. It was all caused by requirement gathering ambiguty I suppose.

  3. Hi jesily:

    你後面的解釋,與我個人對軟體設計的理念,應該是想法蠻一致的…

    不過,仍舊提醒一下:「對於「其它想到實作倒是無妨」這樣的心態比較無法接受。很有可能,UC 真的是變成「另一種需求記錄的工具」而已。」

    看來,可能是文字的表達,或者是,手段上的不同,導致我們作法上不同吧。

  4. Dear Kenming,

    我說的是一種比喻, 並沒有小看使用案例

    我認為在軟體開發的每個階段都應該想到實作面的問題

    就譬如建築師在設計建築藍圖時, 理應也要想到實作施工問題

    否則空有漂亮的藍圖, 建築工人卻無法完成, 也算是失敗

  5. 這篇文章真的讓我收獲良多

    但我倒認同 M 的想法, 不管黑貓或白貓會捉老鼠的就是好貓

    就如同語言一樣, 只要能溝通就好了, 何必去斤斤計較文法呢?

  6. Hi M:
    我也認同 M 所提「UC 是界定系統範圍的好工具」,不過,對於「其它想到實作倒是無妨」這樣的心態比較無法接受。很有可能,UC 真的是變成「另一種需求記錄的工具」而已。

  7. 我還是認為use case是用來界定專案範圍的好工具,其他想到實做倒是無妨,你總要想到的。
    而且user case重要的是搭配他的輔助文章,而不是那幾張圖,這是給初學UML者一定要知道的。

  8. 謝謝你的分享,這個文章解開了我對usecase的疑惑。但是傳統的Programmer仍然不能從Usecase的價值中,發現Usecase究竟能如何幫助他們,以致於淪為文章「記錄需求的工具」,實在是很可惜。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *