作業: 尋找參與者和使用案例
這項作業用來識別參與者和使用案例,以支援所實作的需求。識別參與者和使用案例會明確定義系統的範圍。
規範: 需求
目的

這項作業的目的如下:

  • 定義系統範圍 - 系統將處理什麼,以及在系統之外,將處理什麼。
  • 定義誰以及哪些項目將與系統互動。
  • 概述系統功能。
關係
主要說明

在尋找參與者和使用案例時,保留使用案例研討會是一項非常成功的技術。

步驟
尋找參與者

尋找參與者是定義系統之使用時,最前面的幾個步驟之一。系統必須與它互動的每個外部現象類型都是用參與者來表示。如果要尋找參與者,請提出下列問題:

  • 哪些使用者群組需要系統協助他們執行作業?
  • 執行系統最明顯的主要功能時,需要哪些使用者群組?
  • 執行次要功能時,例如系統的維護和管理,需要哪些使用者群組?
  • 系統將與任何外部軟硬體系統互動嗎?

任何符合一或多個這些種類的個人、群組或現象,都是候選參與者。

如果要判斷您有沒有正確的(人類)參與者,您可以嘗試命名兩三個能夠扮演參與者的人,再看您的這組參與者是否足以滿足他們的需求。如果要進一步瞭解參與者是由什麼構成,請參閱準則:參與者

剛開始時,可能很難找出最適合的參與者,您可能無法立即找到它們全部,因為您還沒有找到所有使用案例。只有處理使用案例可讓您更深入瞭解系統環境及它與系統互動的方式。當您進行到這個程度時,您可能會想修訂您的原始模型,因為剛開始往往會建立太多參與者模型。當您變更參與者時,請小心;引進的變更也會影響使用案例。請記住,參與者的任何修正都會造成系統介面和行為的主要改變。如果您開發了商業使用案例模型和商業分析模型,您可以利用它們作為識別主要參與者的來源。

命名和簡要說明已找到的參與者

參與者的名稱必須清楚表示參與者的角色。請確定未來的階段不至遭到混淆不同參與者名稱的風險。

請撰寫簡要說明來定義每個參與者,其中包括參與者的責任區及參與者要系統做什麼。由於參與者代表系統之外的事物,因此,您不需要詳細說明它們。另請參閱準則:參與者中的「簡要說明」一節。

尋找使用案例

第一份參與者概要完成之後,下一步便是尋找系統的使用案例。最初的使用案例非常初步,它們當然必須經過幾次變更,才會穩定。如果系統的願景或需求有缺點,或系統分析不明確,系統的功能就會不清楚。因此,您必須不斷問您自己,您是否找到了正確的使用案例。另外,在達到最終版本之前,您也應該準備新增、移除、結合和分割使用案例。您詳細描述使用案例之後,會更深入瞭解這些使用案例。

尋找使用案例最好的方法是考慮每個參與者對於系統有什麼需求。請記住,系統只是為了使用者而存在,因此,應該是以使用者的需求為基礎。您將利用在系統上設定的功能需求來辨識許多參與者的需求。請針對每個參與者,不論是不是人類,向您自己提出下列問題:

  • 參與者要系統執行的主要作業是什麼?
  • 參與者將建立、儲存、變更、移除或讀取系統中的資料嗎?
  • 參與者需要向系統通知突然發生的外部變更嗎?
  • 需要向參與者通知系統中的特定事件嗎?
  • 參與者將啟動或關閉系統嗎?

這些問題的回答代表用來識別候選使用案例的事件流程。它們並非全都構成個別使用案例,有些可以建模成相同使用案例的變式。什麼是變式,什麼是個別而明確的使用案例,有時並不容易分清楚。不過,當您詳細說明事件流程時,它們會變成比較清晰。

在需求之外,組織的企業模型(也稱為商業模型)也是在確定使用案例時,很有價值的輸入來源。企業模型會說明資訊系統可如何納入現有的作業中,可協助您瞭解系統的週遭項目。另外,您也會發現必須定義在企業模型中的概念,因為企業模型包含企業的「商業物件」。如果您已遵循商業模型工作流程,您必須用商業使用案例模型和商業分析模型來作為輸入。

系統可以有多種可能的使用案例模型。尋找「最佳」模型的最佳方式是開發兩三個模型,選擇您偏好的模型,再進一步開發它。開發幾個替代模型也可協助您更深入瞭解系統。

當您概述您的第一個使用案例模型時,您應該先確認這個使用案例模型會處理所有功能需求。請仔細檢查需求,以確定所有使用案例符合所有需求。

如需使用案例是什麼及如何尋找它們的相關資訊,請參閱準則:使用案例模型準則:使用案例

命名和簡要說明已找到的使用案例

每個使用案例都應該有一個名稱,指出它與參與者互動所完成的事項。名稱必須是可供瞭解的幾個字。任兩個使用案例都不能用相同的名稱。另請參閱準則:使用案例中的「名稱」一節。

請撰寫使用案例的簡要說明來定義每個使用案例。當您撰寫說明時,請參閱名詞解釋,必要的話,也請定義新的概念。另請參閱準則:使用案例中的「簡要說明」一節。

概述事件流程

這時,您也應該撰寫使用案例事件流程的第一份初稿。請用一些簡短的即時執行來說明每個使用案例的事件流程,但不要進入細節。稍後指定使用案例的人會需要這份逐步說明,即使這個人是您也一樣。首先,請概述基本事件流程,您同意這個基本事件流程之後,請新增替代流程。

範例:

回收機系統中的「回收項目」使用案例事件流程最初的逐步說明,看起來可能如下:

  • 客戶按「啟動」按鈕。
  • 客戶插入存放項目。
  • 系統檢查插入的存放項目類型。
  • 系統遞增所收到項目類型的當日總量。
  • 客戶按「收據」按鈕。
  • 系統印出收據。
收集其他需求

部分系統需求無法配置給特定使用案例;請將它們收集在增補規格中(請參閱工作成果:增補規格)。

說明參與者和使用案例如何互動

由於顯示參與者如何關聯於使用案例很重要,因此,您應該在尋找使用案例時,確定哪些參與者會與這個使用案例互動。如果要執行這個動作,您必須定義一個可以在參與者和使用案例之間,依照信號傳輸的相同方向來導覽的通訊關聯。

信號傳輸通常都是會雙向運作。當這樣時,您必須讓通訊關聯能夠進行雙向導覽。請定義每個參與者和使用案例配對最多一個通訊關聯。

另外,您也應該簡要說明您所定義的每個通訊關聯。

如需通訊關聯的相關資訊,請參閱工作成果準則:通訊關聯

套裝使用案例和參與者

如果參與者或使用案例數目太大,請將它們分割成使用案例套件來簡化使用案例模型的維護。這也會使開發人員承擔套裝使用者案例或參與者的責任,既讓使用案例模型更容易理解,同時也簡化了使用案例模型中的責任指派。

某些將使用案例套裝在一起的替代方式是它們符合下列情況:

  • 與相同參與者互動。
  • 彼此之間有併入或延伸關係。
  • 都是選用的,由系統一起提供,或完全不由系統提供。

另外,還有其他方式;不過,如果要使模型維持符合直覺,當您套裝時,請務必使用清晰的策略。

如需使用案例套件的相關資訊,請參閱工作成果準則:使用案例套件

用圖解呈現使用案例模型

您可以在使用案例模型的圖解中,說明使用案例和參與者之間的關係,以及相關使用案例之間的關係。這些圖可能包含下列中的任何項目:

  • 屬於相同使用案例套件的參與者。
  • 參與者與它所互動的所有使用案例。
  • 處理相同資訊的使用案例。
  • 相同參與者群組所用的使用案例。
  • 通常在單一序列中執行的使用案例。
  • 屬於相同使用案例套件的使用案例。
  • 最重要的使用案例。這類型的圖可以當作模型的摘要,且很可能併入使用案例視圖中。
  • 一起開發的使用案例(在相同漸進式內)。

每個圖都應該是使用案例模型中的適當套件所擁有。

如需使用案例圖的相關資訊,請參閱準則:使用案例圖

開發使用案例模型的調查

在這個步驟中,您將開發使用案例模型的調查說明。在您的調查中,請務必併入下列項目:

  • 使用者運用使用案例的一般順序。
  • 使用案例模型尚未處理的功能。

如需使用案例模型之調查說明的相關資訊,請參閱準則:使用案例模型中的調查說明一節。

評估結果

在這個階段,您應該檢查使用案例模型來驗證您的工作是否上軌道,但不要詳細審查模型。另外,當您處理使用案例模型時,您也應該考慮檢查使用案例模型。如需尋找哪些項目的特定建議,請參閱核對清單:使用案例模型

不是開發小組的人(如使用者和客戶)要在這個階段核准使用案例模型,這一點非常重要。因此,在完成這項作業之前,您必須讓使用者和客戶參與審查使用案例模型。您可以利用使用案例模型的調查及上一步驟所建立的使用案例圖來指引討論。

利益關係人必須判斷:

  • 是否識別了所有必要的使用案例。
  • 是否識別了任何不必要的使用案例。
  • 是否依照正確次序來執行每個使用案例的行為。
  • 是否每個使用案例的事件流程都符合這個階段所可能完成的程度。
  • 使用案例模型是否因使用案例模型的調查說明而成為可理解。
詳細資訊