什麼是使用案例?

使用案例(Use Case)是一種需求捕捉(Requirement capture)及記錄的技術。

使用案例係利用純文字的紀錄,以敘述性的方式來描述參與者(Actor)使用系統的操作互動過程,最後,系統能滿足參與者使用系統的目的。

在利用文字來記錄使用案例的敘述(Description)之前,我們可能會先利用使用案例圖(Use Case Diagram)來突顯參與者使用系統的目的。利用圖形的表達,以鳥瞰的觀點可以快速的一窺全貌。界定系統的範圍(System Boundary)、找出系統的主要(Primary)及支援(Support)參與者,以及系統所需擔負的責任(亦即,稱之為使用案例)。

使用案例圖是有利於團隊的溝通,這也是人與生俱來的本能:利用圖形的表達往往勝過以文字來溝通的方式。

團隊有了初步對系統整體外觀的瞭解及共識,再由如需求分析師(RA, Requirement Analyst)將橢圓形的使用案例打開,以正確易讀的格式來描述參與者與系統之間對話的過程。

由簡入繁,逐步增加使用案例的精確度(precision),不要一開始就陷入繁雜的細節,如此才不至於將過多的精神擺在錯誤的設計及描述上。使用案例圖,可以協助由簡入繁、減少不必要的謬誤發生。 參考下圖1。

使用案例圖範例

圖一、使用案例圖範例


從圖中的觀察,很明顯的可以看出,系統的設計範圍為 “網路訂購系統”,使用這個系統的其中一個主要參與者為 “顧客(Customer)”,該參與者使用系統的目的為 “訂購商品(Place Order)”。

“訂購商品” 是系統的使用案例,參與者為 “顧客”。確定了參與者的目的後,再來會以文字敘述的方式來紀錄該目的的細節,也就是紀錄參與者為了達成該目的,而與系統的操作互動過程的情形。這稱為使用案例敘述(Use Case Description)。

一個簡單的 “訂購商品” 使用案例敘述如下表。

Use Case Name 訂購商品
Brief Description 顧客瀏覽欲購買商品資訊,然後把想購買的商品放進購物車(shopping cart)內。當顧客完成商品選購並選擇結帳。系統列出結帳程序,提供顧客選擇付款方式、填寫寄送資訊、選擇出貨方式等。系統確認無誤後,即完成此次訂購商品的交易。
Basic Course of Events
  1. 系統列出可供訂購的商品資訊。
  2. 顧客瀏覽商品資訊。
  3. 顧客可以選擇其中一項商品的詳細資訊。
  4. 顧客瀏覽商品詳細資訊時,可以選擇將商品放入購物車內。
  5. 系統保存購物車的商品資訊。
  6. 顧客可以繼續瀏覽商品資訊及將欲購買商品放入購物車內。
  7. 顧客選擇結帳。
  8. 系統列出結帳程序。
  9. 顧客選擇付款方式、填寫寄送資訊、選擇出貨方式。
  10. 系統證實顧客填寫結帳相關資訊正確無誤。
  11. 系統儲存此次訂購的交易資訊。

使用案例是由軟體巨擘 Jacobson 於 1992 年率先發表的,對於近代物件導向的技術具有相當大的衝擊。並且由 Booch、Jacobson、Rumbaugh所謂的O-O 三巨頭所聯合制訂並已交由 OMG 審議的 UML(Unified Modeling Language) 規格中,已納為主要的標準規格之重要一環。
這裡列出幾位軟體巨擘們對使用案例的定義。

  • “使用案例是一種敘事性的文件,用以描述某個參與者(actor)使用系統完成某個事件的流程順序” [Jacobson92]。
  • “使用案例就是一組情節(scenarios),它們跟系統常見的使用目的互相關連” [Fowler97]。
  • “A use case is a sequence of actions that an actor(usually a person, but perhaps an external entity, such as another system) performs within a system to achieve a particular goal” [Rosenberg99]。
    “使用案例是一個參與者(actor) (通常是使用者,但或許可以為一個外部的實體, 例如另一個外部系統),在與內部系統的互動中,來達成一個特定目標的一系列行動”。
  • “The Unified Modeling Language User Guide” 一書中,則給予 Use Case 的定義:
    “A use case describes a set of sequence, in which each sequence represents the interaction of the things outside the system(its actors) with the system itself(and its key abstractions)”。
    “使用案例描述了一連串的循序,每一個循序表達了外部於系統的事物(參與者)與系統本身(及它的關鍵抽象)之間的互動”。

從以上的論述中,可以得到與使用案例相關的特點:

  • 使用案例係用自然語言(例如以英文或中文來敘事)來描述的一份敘述性文件,一般而言,使用案例不牽涉以圖形或程式語言的語法(如 java)來描述。
  • 使用案例所描述的的情節(Scenario)正是參與者(actor)期望能從與系統的互動溝通當中,來完成(得到)他們的目的(Goal)。
    例如 “購買商品(Buy Items)” 正是消費者消費的目的:
    ”消費者拿購買的貨品結帳,出納員紀錄購買貨品並收取貨款。一旦完成,消費者帶著貨品離開。”
  • 一個使用案例可以有一個正常的情節,以及多個例外(exception)的情節。正常的情節描述的是參與者與系統的正常互動過程 ; 而在與系統的互動過程中,如果考慮到例外狀況的發生,視狀況的複雜度,可以描述在正常情節內的 ”替代方案內(Alternative Paths)” 或可以對複雜的例外狀況以另一個情節來描述它。
  • 系統會提供一連串的功能(function)來與參與者互動,但參與者並不需要知道系統內部作什麼事,或如何作,系統只要把結果傳回給參與者即可。所以,對參與者而言,系統是一個黑箱(Black-box)。
  • 使用案例的描述是強調系統應該作什麼(what to do),而不是如何作(how to do)。所以,對於實作的細節,不應該描述在使用案例的敘述內。
  • 參與者(actor)是直接來操作系統的,在使用案例圖中,雖然參與者(actor)被表示成 ”棒形人偶” 的圖示,可是參與者不見得一定就是由人所擔任的角色。參與者也有可能是一個外部的系統,它可能需要從這個系統中得到一些資訊。

文章導覽

   

共有 2 則迴響

  1. Hi Powell:
    我一直提醒與強調,UC 不是需求的全部,而是一個很關鍵的需求捕捉技術。
    有些假設點,也要能釐清。例如,面對是 Operator 時,我也會如貴公司專案的方式,利用畫面來輔助溝通;而面對如 Stakeholder,利用 UC 又是不同的表達意涵與目的,相對,對於團隊內部的溝通,UC 又有另外的表達目的。

    不是”用”得不好,就覺得 UC 不好 “用”;也不是 “用得” 很好,就想要利用某種 UC 用在 “Everywhere”。

    這些都會有問題的。

    多多開拓自己的視野,多多懂得從各種角度思考,不要被侷限在現況,而沒看到更廣的視界。

  2. 其實,我才剛開始接觸UML…所以對於Use Case有一些些初學者的想法。總覺得用『文字』去『詳細』敘述使用者要『作』什麼似乎不是那麼貼切現實的狀況。
    我們專案目前的做法是把使用者操作的畫面+牽涉到的資料格式型態+按下某些按鈕所預期出現的畫面作成使用者需求文件。我也嘗試過使用Use Case式的文字描述,但是當我拿給PG或是User看的時候,發現還是用操作畫面比較好『溝通』….當然,如果有文字敘述更好…但是,那是在有充裕時間的前提下…。
    還是非常感謝您詳細生動的說明,對於剛學UML的我,有很大的幫助。

發佈回覆給「Powell」的留言 取消回覆

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *