使用者本文模型化

小組可以針對即將估計或開發的使用者本文，建立可協助了解使用者本文的模型。 如果問題相當複雜，小組也可以在開發期間所舉行的定期討論中使用模型與產品擁有者進行溝通。

例如，專案可能牽涉到對小組來說是全新的一組概念。 與產品擁有者合作，小組可以開發網域類別圖表，以擷取這些概念及其之間的關聯性。 如果小組必須了解使用者活動中的主要順序，可以建立活動圖表。

如需詳細資訊，請參閱模型化使用者要求。

網域模型：使用者的語言

網域類別圖表

網域類別圖表會顯示與應用程式相關的概念和關聯性。 與應用程式相關的人員可以使用這些概念達到更加一致的了解。

上圖的範例並非直接指軟體方案的類別圖表，而可能以多種不同的方式代表這些關聯性。 相反地，它呈現您可以撰寫使用者本文的詞彙：

客戶選擇「菜單」(Menu) 從中建構「訂單」(Order)，然後再透過從「菜單」(Menu) 選取「菜單項目」(Menu Item)，以便在「訂單」(Order) 中建立「訂單項目」(Order Item)。

因為這個圖表是概念模型而非程式中的物件，在用於此目的時通常不要將作業指派給類別。 您可以改用活動圖表來說明使用者執行的動作。

如需詳細資訊，請參閱 UML 類別圖表：方針。

活動圖表

小組可以說明使用者能夠執行的活動流程，並使用活動圖表顯示每個點的替代動作做法。

小組建立測試案例時，可以參考活動圖表，並透過活動圖表為每個路徑建立測試。

使用者本文可能將路徑導入現有活動圖表。 例如，使用者本文可能是「身為客戶，我可以選擇稍後再儲存訂單，而不是立即付款」。將這個本文列入開發期程 (Sprint) 時，可以更新活動圖表來表示新功能。

如果您更新活動圖表以反映小組已實作的所有使用者本文，活動圖表可以描述一組完整的路徑，讓使用者能夠使用應用程式的特定版本來採用這組路徑。

如需詳細資訊，請參閱 UML 活動圖表：方針。

使用模型發現分歧

小組可以避免圖表不支援的交談中所發生的誤解，以便更加了解使用者的需求。 例如，圖表將明確區分訂單項目與菜單項目。

建立模型有助於小組提出可能到了開發後期才發現的問題。 一些技巧如下：

• 詢問關於類別圖表上的基數 (例如，「菜單項目能否出現在一個以上的菜單上？」)。

• 詢問關於類別圖表中的迴圈 (例如，「在任何訂單中，所有項目是否都來自同一個菜單上？」)。

在圖表上可以加入這些問題類型的回答做為註解。

模型一致性

小組只要確定模型與使用者本文之間是否一致，就可以解決模稜兩可的問題：

• 使用者本文使用模型中定義的詞彙，以及與模型定義的關聯一致的詞彙。 如果模型定義菜單項目，本文就不應該使用「產品」一詞來表示相同的東西。 如果類別圖表顯示一個菜單項目只屬於一個菜單，本文就不應該提到在菜單之間共用項目。

• 每個使用者本文都描述一系列由活動圖表允許的步驟。

• 使用者本文或活動描述如何建立及終結類別圖表上的每個類別和關聯性。 例如，使用者本文建立什麼菜單項目？ 何時會終結訂單？

模型和產品待處理項目

小組可以標示模型和腳本以顯示每個使用者本文將變更的部分，而且可以為模型加上色彩或註解以協助您規劃開發工作。 例如，小組可以為活動圖表中的動作加上色彩，來表示已完成的動作和將在下一個期程完成的動作。

如需詳細資訊，請參閱模型化使用者要求。

模型和測試

小組可以使用網域模型做為系統測試的基礎，讓測試與使用者需求之間的關聯性更清晰。 此關聯性可協助小組快速且正確地更新測試，並協助確認產品是否符合新需求。

小組可以將統一模組化語言 (Unified Modeling Language，UML) 模型中的任何項目連結到任何工作項目，例如測試。 當模組的任一部分變更時，模組將協助小組找出相關的項目。

使用網域模型協助您建立測試：

• 至少建立一個與每個類型或關聯建構相關的測試，例如菜單項目或訂單項目，以及至少一個與其解構相關的測試。

• 確認活動圖表所描述的所有路徑都經過測試。

  注意事項
  這些測試也應該涵蓋您通常不會在活動圖表中說明的例外路徑。

• 使用網域模型的詞彙定義測試。 例如，您的測試可能包含「選取菜單項目」(Select Menu Item) 動作的測試，它會驗證「訂單」(Order) 中的動作結果是否包含新的「訂單項目」(Order Item)。 若要撰寫自動化測試，您可以使用直接以圖表為基礎的類別和關聯性。

如需詳細資訊，請參閱從模型開發測試。