我個人一向主張寫 Use Case 的敘述之前,先畫使用案例圖(Use Case Diagram) 。原因在於我們可以從鳥瞰的視野綜觀系統的全貌:

  1. 可以利用套件(Package)界定系統的設計範圍(Boundary)。
  2. 避免過早涉及至細節(Detail)。

先說明,什麼是鳥瞰?

  • 從高處俯視低處。
  • 對事實情況作概略的觀察。

利用使用案例圖,可以協助我們從 "鳥瞰" 的視野來看系統的外觀,避免從系統的內部來看 Use Case (這是許多 Developer 常犯的毛病)。
同時,因為鳥瞰,所以,比較容易能看出系統的全貌、界定系統的範圍、區分系統的內與外(這很重要,如此才能知道什麼該作,什麼不需作)。還有,也比較容易看出使用案例的所表達的層次(level),如企業層級(Business level)、使用者目標層級(User-goal level)等。

寫使用案例若不知道系統的設計範圍,我很難相信 RA(Requirement Analyst)能寫得好 Use Case。
理由為何?若未能確定系統邊界,那麼,你如何能將系統視為一個黑箱(Black box)?你又如何能確認誰是使用系統的主要參與者(Primary Actor)?

而 Developer 常常以為很清楚系統範圍,但事實上系統範圍的界定在團隊成員之間往往會有見解上的落差。
例如,觀察下圖一,顧客至錄影帶店租片,很直覺地,我們發現有個 Use Case:租片 。

使用案例圖(沒有以Package界定範圍)
圖一、使用案例圖(沒有以Package界定範圍)

沒有畫出系統邊界,一般是常見於單一系統的開發,且系統的範圍很明確。但我們觀察圖一,試著問問團隊內部的開發成員們,她們所認知的系統是界定在那個範圍呢?
可能會以為,不就是要開發一個影片租借系統嗎?


我們來反思,顧客會直接去 "使用" 軟體應用系統嗎?不然吧,直接使用系統的實際參與者(Actor)是錄影帶店的櫃臺人員。

所以,若把圖一的系統範圍界定於 "影片租借系統",Actor 是 "顧客",Use Case 是 "租片",其實是大有問題的。

實際上,圖一的使用案例圖是屬於 "企業層級(Business level)" 的 Use Case,偏向於描述企業的流程,而非操作系統功能面的 "使用者目標(User-goal level)" 層級的 Use Case。
系統界定的範圍一般以企業為單位,如下圖二。

企業層級的使用案例圖
圖二、 企業層級的使用案例圖

圖二是以百X達為系統的範圍,內部包括了 "內部的工作者(internal worker)",如店長、櫃臺人員;同時也可能包括了如影片租借、會計、人事等軟體應用系統。
所以,是不是百X達所有的內部的系統均是由同一個開發團隊來開發的?還只是負責開發其中單一個子系統呢?

很有可能,只是承包 "影片租借系統" 的開發。那麼,顯然,主要參與者就不是顧客了,而是實際操作系統的櫃臺人員;使用系統的 "Goal" 也不是 "租片",而是成為 "處理租片" 的 Use Case 了。如下圖三。

影片租借系統的使用案例圖
圖三、 影片租借系統的使用案例圖

我們可以發現,因為系統的範圍很明確的界定在 "影片租借系統",所以,當系統若是接受是以信用卡刷卡的方式付款,那麼,系統就需要連到外部銀行的系統,此時,銀行的外部系統就成為 "影片租借系統" 的 "Supporting Actor" 了。

圖三所表達的使用案例圖,其層次是偏於 "使用者目標等級"。亦即,當 RA 要寫 Use Case 敘述時,所訪談的 Actor,大部分是直接操作系統的使用者(Operator),如櫃臺人員。而圖二企業層級的使用案例圖,所訪談的主要對象不是主要的參與者:顧客,反而是制訂企業案例流程的利益關係人(Stakeholder)了。

企業層級的使用案例圖,著重於描述企業內部的流程;非著重於描述系統的行為。通常會以白箱式(White-box)的作法打開企業內部,以瞭解內部 internal worker的互動情形。

而使用者目標等級的使用案例圖,是經常最被討論的層次。系統範圍經常是指軟體應用系統,為滿足主要參與者(Primary Actor)來使用系統的目的。而通常是使用者在某一段時間(3~30分鐘)操作系統後所完成的目標。
在此一層次,我們會以”黑箱(black-box)”的方式來描述使用案例,瞭解參與者與系統之間的互動(或稱之為對話)關係。

利用使用案例圖,協助我們確定及界定了系統的廣度(系統範圍)與深度(系統層次),可以讓我們看到 "誰(Actor)"來使用系統,以及系統要作的"事(系統行為或稱之為系統責任)。然後再進一步去瞭解 Use Case 的敘述,紀錄 參與者 與 系統 之間的操作對話的互動過程。
再更進一步,才去設計系統內部是如何 "實現(Realize)" Use Case。

由整體、全貌的觀照,找出及界定系統的範圍,然後將焦點擺在橢圓的 Use Case, 釐清參與者的目的(Goal)。再來才是寫出正確易讀的 Use Case 敘述,瞭解參與者與系統之間對話的過程。
由簡入繁,逐步增加使用案例的精確度(precision)。不要一開始就陷入繁雜的細節,如此才不至於將過多的精神擺在錯誤的設計及描述上。

使用案例圖, 就是協助你由簡入繁、減少不必要的謬誤發生。