第一份參與者概要完成之後,下一步便是尋找系統的使用案例。最初的使用案例非常初步,它們當然必須經過幾次變更,才會穩定。如果系統的願景或需求有缺點,或系統分析不明確,系統的功能就會不清楚。因此,您必須不斷問您自己,您是否找到了正確的使用案例。另外,在達到最終版本之前,您也應該準備新增、移除、結合和分割使用案例。您詳細描述使用案例之後,會更深入瞭解這些使用案例。
尋找使用案例最好的方法是考慮每個參與者對於系統有什麼需求。請記住,系統只是為了使用者而存在,因此,應該是以使用者的需求為基礎。您將利用在系統上設定的功能需求來辨識許多參與者的需求。請針對每個參與者,不論是不是人類,向您自己提出下列問題:
-
參與者要系統執行的主要作業是什麼?
-
參與者將建立、儲存、變更、移除或讀取系統中的資料嗎?
-
參與者需要向系統通知突然發生的外部變更嗎?
-
需要向參與者通知系統中的特定事件嗎?
-
參與者將啟動或關閉系統嗎?
這些問題的回答代表用來識別候選使用案例的事件流程。它們並非全都構成個別使用案例,有些可以建模成相同使用案例的變式。什麼是變式,什麼是個別而明確的使用案例,有時並不容易分清楚。不過,當您詳細說明事件流程時,它們會變成比較清晰。
在需求之外,組織的企業模型(也稱為商業模型)也是在確定使用案例時,很有價值的輸入來源。企業模型會說明資訊系統可如何納入現有的作業中,可協助您瞭解系統的週遭項目。另外,您也會發現必須定義在企業模型中的概念,因為企業模型包含企業的「商業物件」。如果您已遵循商業模型工作流程,您必須用商業使用案例模型和商業分析模型來作為輸入。
系統可以有多種可能的使用案例模型。尋找「最佳」模型的最佳方式是開發兩三個模型,選擇您偏好的模型,再進一步開發它。開發幾個替代模型也可協助您更深入瞭解系統。
當您概述您的第一個使用案例模型時,您應該先確認這個使用案例模型會處理所有功能需求。請仔細檢查需求,以確定所有使用案例符合所有需求。
如需使用案例是什麼及如何尋找它們的相關資訊,請參閱準則:使用案例模型和準則:使用案例。
命名和簡要說明已找到的使用案例
每個使用案例都應該有一個名稱,指出它與參與者互動所完成的事項。名稱必須是可供瞭解的幾個字。任兩個使用案例都不能用相同的名稱。另請參閱準則:使用案例中的「名稱」一節。
請撰寫使用案例的簡要說明來定義每個使用案例。當您撰寫說明時,請參閱名詞解釋,必要的話,也請定義新的概念。另請參閱準則:使用案例中的「簡要說明」一節。
概述事件流程
這時,您也應該撰寫使用案例事件流程的第一份初稿。請用一些簡短的即時執行來說明每個使用案例的事件流程,但不要進入細節。稍後指定使用案例的人會需要這份逐步說明,即使這個人是您也一樣。首先,請概述基本事件流程,您同意這個基本事件流程之後,請新增替代流程。
範例:
回收機系統中的「回收項目」使用案例事件流程最初的逐步說明,看起來可能如下:
-
客戶按「啟動」按鈕。
-
客戶插入存放項目。
-
系統檢查插入的存放項目類型。
-
系統遞增所收到項目類型的當日總量。
-
客戶按「收據」按鈕。
-
系統印出收據。
收集其他需求
部分系統需求無法配置給特定使用案例;請將它們收集在增補規格中(請參閱工作成果:增補規格)。
|