模型化使用者要求
Microsoft Visual Studio Ultimate 可以繪製有關使用者活動的圖表和系統在協助使用者達成目標方面所發揮作用的圖表，從而協助您了解使用者的需求，並就此需求與使用者進行討論和溝通。需求模型是這些圖表的集合，其中每個圖表都側重於使用者需求的不同方面。
如需觀看示範影片，請參閱：模型化商業領域 (英文)。
需求模型可協助您：
將重點放在系統的外部行為上，而不涉及其內部設計。
需求模型可以用較自然語言清晰的方式描述使用者與專案關係人的需求。
定義可供使用者、開發人員和測試人員使用的一致字彙表。
減少對需求理解的差距和不一致。
減少回應需求變更所需要做的工作。
計劃功能的開發順序。
使用模型做為系統測試的基礎，讓測試與需求之間的關聯性更清晰。當需求變更時，此關聯性可協助您正確更新測試。這樣可以確保系統符合新的需求。
需求模型所提供的最大優點就是可用來與使用者或其代表進行重點討論，並且每次討論時都可拿上次討論後的需求模型做參考。在開始撰寫程式碼之前，您不需要做得非常詳細。即使是一個非常簡單、功能尚不完善的應用程式，通常都會成為促進與使用者展開需求討論的基礎。模型是摘要那些討論結果的有效方式。如需詳細資訊，請參閱在開發程序中使用模型。
.gif "注意事項") 注意事項 |
|---|
在所有這些主題中，「系統」都表示正在開發的系統或應用程式。它可能是許多軟體和硬體元件的大型集合、單一應用程式，或較大型系統內的一個軟體元件。無論是哪一種情況，需求模型都可描述可從系統外部了解的行為，不論是透過使用者介面或 API 都是如此。 |
一般工作
您可以建立數種不同的使用者需求檢視。每一個檢視都會提供特定類型的資訊。建立這些檢視時，最好經常在這些檢視之間切換。您可以從任何檢視開始。
圖表或文件 |
在需求模型中描述的內容 |
章節 |
|---|---|---|
使用案例圖表 |
使用系統的人員以及使用系統所做的動作。 |
描述如何使用系統 |
概念類別圖表 |
用來描述需求的型別字彙，在系統的介面上可以看到這些型別。 |
定義用來描述需求的詞彙 |
活動圖表 |
使用者與系統或系統的一部分所執行之活動之間的工作流程和資訊。 |
顯示使用者與系統之間的工作流程 |
順序圖表 |
使用者與系統或系統的一部分之間的互動順序。活動圖表的替代檢視。 |
顯示使用者與系統之間的互動 |
其他文件或工作項目 |
效能、安全性、可用性和可靠性準則。 |
描述服務需求品質 |
其他文件或工作項目 |
非特定使用案例專屬的條件約束和規則 |
顯示商務規則 |
請注意，大部分圖表類型都可以用於其他用途。如需圖表類型的概觀，請參閱開發軟體設計的模型。如需繪製圖表的基本資訊，請參閱 HOW TO：編輯 UML 模型和圖表。
描述如何使用系統
建立使用案例圖表，以描述系統的使用者以及使用目的。使用案例代表系統的使用者目標，以及他們要達到目標所執行的程序。
例如，線上餐點銷售系統必須允許消費者從菜單選擇項目，同時還必須允許供應餐廳更新菜單。您可以在使用案例圖表中摘要此範例：
.png "客戶和餐廳的使用案例")
您也可以顯示如何由幾個較小的案例組成使用案例。例如，訂購餐點是購買餐點的一部分，其中還包括付款和送貨：
.png "系統參與付款而非外送。")
您還可以顯示正在開發的系統範圍中包括哪些使用案例。例如，示範中的系統沒有加入「餐點送貨」使用案例。這有助於設定開發工作的內容。(在使用案例圖表中，子系統容器可用來代表系統或系統的元件)。
它也可協助小組討論在後續版本中要包含的內容。例如，您可以討論在系統的初始版本中，是否將「餐點付款」直接安排在餐廳與消費者之間，而不是貫穿整個系統。在這種情況下，您可以針對初始版本，將「餐點付款」移出「立即進餐系統」矩形。
使用案例圖表只提供使用案例的摘要。若要提供更詳細的說明，可以將圖表上的使用案例連結至各個文件，以及連結至其他圖表。若要了解如何進行，請參閱 HOW TO：將使用案例連結到文件與圖表。
繪製使用案例圖表可協助您的小組：
將重點放在使用者期望系統執行的內容，而不會因為實作的細節而分心。
討論系統或系統特定版本的範圍。
下列主題提供詳細資訊：
若要了解 |
讀取 |
|---|---|
如何建立使用案例的詳細資訊 |
|
使用案例圖表上的項目 |
|
如何從使用案例開發程式碼 |
定義用來描述需求的詞彙
您可以使用 UML 類別圖表來協助您開發商務概念的一致詞彙，用於以下用途：
讓使用者自行用來討論運用此系統的商務活動。
描述使用者的需求，例如描述使用案例、商務規則和使用者劇本。
在系統的 API 上或透過使用者介面交換的資訊類型。
系統或接受度測試的描述。
當用於此目的時，UML 類別圖表的內容稱為概念類別圖表。(它也稱為「領域模型」(Domain Model) 或「分析類別模型」(Analysis Class Model))。
在概念類別圖表中，您可只顯示需求描述中需要的那些類別，而無需顯示系統內部設計的任何詳細資料。圖表不會顯示系統內部設計的任何詳細資料。您通常不會在概念類別上顯示作業或介面。
例如，您可以針對「立即進餐」系統繪製下列概念類別：
.png "類別菜單、訂單、菜單項目、訂單項目。")
概念類別圖表提供在整個需求模型中使用的詞彙。例如，在使用案例「訂購餐點」的詳細描述中，您可以撰寫：
消費者選擇「菜單」(Menu) 從中建構「訂單」(Order)，然後透過從「菜單」(Menu) 選取「菜單項目」(Menu Item)，以辨在「訂單」(Order) 中建立「訂單項目」(Order Item)。
請注意在該描述中使用詞彙如何成為模型中類別的名稱。圖表可消除那些類別之間模棱兩可的關聯性。例如，它會清楚顯示每個「訂單」只與一個「菜單」相關聯。
追蹤發現，對使用者需求的誤解通常源於對詞彙真正意義的誤解。例如，大部分餐廳都對詞彙「菜單」和「訂單」的理解有共識，但對「訂單」上的項目和「菜單」上的項目之間的不同之處卻不是很清楚。與商務專案關係人討論需求時，闡明這些不同是十分重要的。類別圖表是很有用的工具，可協助您釐清詞彙及其之間的關聯性。
概念類別模型可以構成基本詞彙，可以依據它們來描述系統的商務邏輯。然而，軟體中的類別通常比概念模型更複雜，因為實作必須考量諸如效能、散發、彈性和其他因素的問題。在一個系統中，經常會發現同一概念類別的數個不同實作。
例如，「訂單」可以在系統的不同部分和各部分之間不同介面上，以 XML、SQL、HTML 和 C# 呈現。「訂單」和「菜單」之間的關聯可以使用許多不同的方式呈現，例如 C# 程式碼內的參考、資料庫中的關聯或 XML 中交互參考 ID。但是，儘管具有這些變化，概念模型仍在軟體的每個部分都提供正確的重要資訊。範例中的類別圖表告訴我們在每個實作中，每個「訂單」都只有一個關聯「菜單」。
繪製需求類別圖表可協助您的小組：
定義在討論使用者需求過程中所使用的基本詞彙，並使之標準化。
釐清那些詞彙之間的關聯性。
下列主題提供詳細資訊：
若要了解 |
讀取 |
|---|---|
尋找需求類別的詳細資訊 |
|
概念類別圖表上的項目 |
|
如何從概念類別開發程式碼 |
在概念類別圖表中，將箭頭放在關聯上來代表巡覽性通常是沒有用的。這是因為圖表不代表實作。關聯代表真實物件之間的關聯性。下列 Visual Studio 擴充功能會將非方向箭頭設為預設值：範例：UML 網域模組化功能 (英文)。
顯示商務規則
商務規則不是與特定使用案例相關聯的需求，而是應在整個系統中都要觀察的需求。
許多商務規則是概念類別之間關聯性的條件約束。您可以撰寫這些「靜態商務規則」(Static Business Rule)，做為與概念類別圖表上相關類別的關聯註解。例如：
.png "附加至 Order 類別之註解的規則。")
「動態商務規則」(Dynamic Business Rule) 限制允許的事件順序。例如，您可使用順序圖表或活動圖表來顯示使用者必須先登入，然後才能在系統上執行其他作業。
然而，透過使用靜態規則來取代動態規則，可以更有效更廣泛地描述許多動態規則。例如，您可將布林屬性「已登入」加入概念類別模型中的類別。您可加入「已登入」，做為登入使用案例的後置條件，並做為其他大部分使用案例的前置條件。這個方法可讓您避免定義所有可能的事件順序組合。當需要將新的使用案例加入模型時，它也具有更大的彈性。
請注意，這裡的選擇是關於如何定義需求，這與如何在程式碼中實作需求無關。
下列主題提供詳細資訊：
若要了解 |
讀取 |
|---|---|
尋找和記錄靜態商務規則的詳細資訊 |
|
概念類別圖表上的項目 |
|
如何開發遵守商務規則的程式碼 |
描述服務需求品質
服務需求品質具有數個類別，包括以下內容：
效能
安全性
可用性
可靠性
加強性
您可以在特定使用案例的描述中包含這些需求的一部分。其他需求不是使用案例特定的需求，最有效的方法是分開用不同的文件撰寫。盡量遵守需求模型定義的詞彙，這樣做很有用。在下列範例中，請注意在需求中使用的主要詞彙是前述示範中行動、使用案例和類別的標題：
如果在「客戶」正在「訂購餐點」時，「餐廳」刪除「菜單項目」，則參考該「菜單項目」的任何「訂單項目」都會以紅色顯示。
下列主題提供詳細資訊：
若要了解 |
讀取 |
|---|---|
記錄服務需求品質的詳細資訊 |
|
將其他文件附加至使用案例 |
|
如何開發遵守服務需求品質的程式碼 |
顯示使用者與系統之間的工作流程
您可以使用活動圖表來顯示不同使用案例之間的工作流程。透過繪製活動圖表，顯示使用者執行的主要工作 (同時包括系統內和系統外)，來開始需求模型通常很有用。
例如：
.png "包含三個動作和一個迴圈的活動。")
您可以繪製使用案例圖表和活動圖表，來顯示相同資訊的不同檢視。使用案例圖表在顯示大型活動內較小動作的巢狀結構時更有效，但不會顯示工作流程。例如：
.png "前述動作的使用案例")
請注意，您也可以使用活動圖表來描述軟體內的演算法，但在使用圖表進行商務程序時，可將重點放在系統之外可以看到的動作上。
下列主題提供詳細資訊：
若要了解 |
讀取 |
|---|---|
如何定義商務工作流程的詳細資訊 |
|
活動圖表上的項目 |
|
如何從活動圖表開發程式碼 |
顯示使用者與系統之間的互動
您可以使用順序圖表來顯示系統與外部行動之間，或系統各部分之間的訊息交換。這樣可在使用案例中提供步驟的檢視，非常清楚顯示互動的順序。當使用案例中具有數個互動對象，以及系統具有 API 時，順序圖表特別有用。
例如：
.png "包含系統和行動的順序圖表")
順序圖表的一個優點就是很容易查看流入您正在建構之系統的訊息。若要設計系統，您可針對系統的每個元件，使用不同的生命線取代單一「系統」生命線，然後顯示它們之間的互動，以回應每個流入訊息。
下列主題提供詳細資訊：
若要了解 |
讀取 |
|---|---|
如何定義互動的詳細資訊 |
|
順序圖表上的項目 |
|
如何從順序圖表開發程式碼 |
使用模型以減少不一致
建立模型通常會大幅減少使用者需求中的不一致和模棱兩可之處。對於系統運作的商務領域，不同的專案關係人通常具有不同的理解。因此，您的首要工作是先解決客戶之間的這些差異。
您會發現在建立模型時，自然會遇到關於商務領域的許多問題。將這些問題提供給使用者，您可減少在專案的稍後階段所需要的變更。下面是可先詢問自己的某些特定問題，如果不清楚答案，再詢問商務專案關係人：
對於需求模型中的每個類別，詢問「何種使用案例會建立此類別的執行個體？」 以線上餐點訂購服務為例，您可以詢問「何種使用案例會建立餐廳菜單類別的執行個體？」 這會衍生出新餐廳如何註冊至服務以及提供菜單的相關討論。您可以詢問什麽會建立或變更屬性和關聯等類似問題。
對於需求模型中的每個使用案例，嘗試使用類別圖表提供的詞彙，描述每個使用案例的結果或後置條件。透過在發生使用案例之前和之後繪製類別的執行個體，來顯示使用案例的效果通常很有用。例如，如果使用案例後置條件為「菜單項目已加入客戶的訂單」，請繪製「訂單」和「菜單項目」類別的執行個體。將使用案例的效果 (例如新連結或新物件) 以不同顏色或新繪圖物件顯示。這通常會引導就模型中需要哪些資訊展開討論。儘管需求類別不是直接與實作相關，但它們會描述系統需要儲存和傳輸的資訊。
詢問屬性和關聯的條件約束，特別是涉及多個屬性或關聯的條件約束。
詢問有效和無效的使用案例順序，繪製順序圖表或活動圖表對其進行示範。
透過檢查不同圖表所提供檢視之間的關聯性，可以快速了解使用者工作的主要概念，並協助他們了解對系統的需求。您也可以更清楚了解專案關係人最不確定的需求。您可以計劃在專案的早期階段，至少以簡化的形式開發那些功能，以讓使用者進行體驗。