UML：業務用例

     業務用例（business use case）是定義了一組業務用例執行個體。業務用例具有名稱。

      業務用例執行個體（business use case instance）是在業務中執行的一系列動作，這些動作為業務的個體主角產生具有可見價值的結果。 
 
      商務程序被定義為數個不同的業務用例，其中每個業務用例都代表業務中某個特定的工作流程。業務用例確定了執行業務時將要發生的事情；它描述了一系列動作的執行，而這些動作會產生對特定業務主角具有價值的結果。商務程序為業務產生價值或降低業務的成本。

遊客 (Passenger) 可以獨自旅行，也可以隨旅遊團 (Tour Guide) 旅行。隨旅遊團旅行時，遊客將由導遊帶領。

      業務用例描述了“在業務中執行的一系列動作，這些動作為業務的個體主角產生具有可見價值的結果”。因此，從個體主角的角度看，業務用例確定了一個能夠產生期望結果的完整工作流程。這與我們常說的“商務程序”很相似，但是“業務用例”有更精確的定義。

      業務用例概念的定義包含了許多對理解業務用例十分重要的關鍵字：

      業務用例執行個體 - 上面定義的實際上是一個特定的業務工作流程，即一個執行個體。實際上，存在大量可能的工作流程，而且它們中有很多是非常相似的。
為了使業務用例模型易於理解，可以將類似的工作流程組成一個業務用例（按照物件模型的話來說就是一個“類”）。確定和描述業務用例是指確定和描述具有類特徵的業務用例，而不是單個用例執行個體。

      個體主角-主角可能是找到正確的業務用例的關鍵。從個體主角開始（實際上是從主角執行個體開始），可以協助我們避免太大或太複雜的業務用例。
確定合適的主角時，首先指定至少兩三個能擔任所討論主角的人，然後嚴格評估每個人需要什麼樣的支援。例如，假定您最初確定了一個名為“客戶”的主角。而後，隨著您仔細考查每個客戶所需的支援，可能發現三種不同的客戶：產品的一般“使用者”、“採購員”和“評估員”，他們能夠將產品與其他同類產品進行比較。每種客戶都需要一個單獨的業務用例，因為它們代表了作用於業務的不同角色。

      具有可見價值的結果 - 該表達對於確定正確的業務用例範圍非常重要，這個範圍不能太小，也不能太大。規定業務用例應該給出一個具有可見價值的結果（即可以感覺到而且可以進行評測），這可以協助您找到完整的流程，同時防止業務用例太小。
      一個好的業務用例可以協助主角執行具有可確定價值的任務。它可能會為成功執行的業務用例確定一個價格。一個太小的業務用例由於範圍有限，導致進行重建的可能性較小。

      在業務中 -“在業務中執行的動作”意味著業務向主角提供業務用例，同時業務用例只包含那些業務中實際執行的動作。其他地方進行的支援工作並不包含在內。

      動作 - 動作由主角對業務發出的請求調用，或者在某個特定時間調用。動作包括內部活動和決策，以及對被調用的主角或其他主角的請求。

      商務服務通過不同的業務用例來描述，每個業務用例都有自己的任務。這些業務用例的集合組成使用業務的所有可能的方法。另請參見指南：業務用例模型。

一、業務用例與業務用例實現

      在受用例驅動的業務建模項目中，您將製作業務的兩個視圖。

      業務用例本身展示了業務的外部視圖，它確定了業務為了向主角交付期望結果，關鍵要執行什麼。同時還確定了執行業務用例時，業務與主角之間需要進行哪些互動。必須在確定並同意每個業務用例的工作時製作該視圖。這一系列業務用例描述了業務的概貌，對僱員瞭解執行業務的哪些不同部分以及所期望的結果十分有用。

      另一方面，業務用例實現給出了業務用例的內部視圖，它確定了如何組織和執行工作來獲得期望的結果。實現中包含了業務角色和業務實體，它們涉及業務用例的執行，以及進行該工作所需的業務角色和業務實體之間的關係。必須製作該視圖，以便確定並同意為獲得期望的結果，如何在每個業務用例中組織工作。

      兩種業務用例視圖面向的主要對象都是業務中的人員 - 外部視圖供業務用例外的人員使用，而內部視圖則供業務用例內的人員使用。

二、類和業務用例執行個體

      隨著業務的進行，您將發現可以確定的單獨工作流程的數目幾乎是無限的。一個用例執行個體只是一個特定的工作流程（即情境）。它對應著（由大量協作的業務成員按照物件模型中所定義的角色來執行的）工作，而不是某個特定的業務成員，也不是成員所擔當的角色。

      業務用例通常用來使用例模型易於理解，同時避免過多的細節。它代表一組業務用例執行個體，這些業務用例執行個體具有類似但不完全相同的工作流程。

      通常，某個能擔當特定角色的僱員會在多個不同的業務用例執行個體中發揮作用。

      樣本：
      在機場登記處，個人登記 (Individual Check-in) 和團體登記 (Group Check-in) 兩個業務用例對登記處僱員的工作能力有相同的要求，而且兩個業務用例訪問相同的起飛資訊。因此，兩個用例可以而且應該使用同一個登記處服務人員 (Check-in Agent) 角色和起飛 (Departure) 實體。

三、業務用例的範圍

      有時，我們很難確定一項服務是一個業務用例還是多個業務用例。在機場登記流程中應用業務用例的定義。一個旅客將機票和行李交給登記處服務人員，他為旅客找到一個座位，然後列印登機證並開始處理行李。如果旅客攜帶的是普通行李，登記處服務人員將列印行李標籤和旅客行李領取牌，在行李上貼好行李標籤，最後將行李領取牌和登機證一起交給旅客，從而完成該業務用例。如果行李形狀或所裝東西比較特殊，不能按普通行李運輸，則旅客必須將行李送往特殊行李台。如果行李過重，旅客必須去機場票務處交納費用，因為登記處服務人員不負責收取費用。

      您是否要為登記處、特殊行李台和票務處各設一個業務用例呢？或者您只需要一個業務用例？的確，該處理過程涉及三種不同的操作。但問題是，是否每個操作對攜帶特殊行李的旅客都是有意義的？當然不是，只有整個過程（從旅客到達登記處直到他補交完行李超重費）對旅客來說才是有意義的。所以，涉及三個不同櫃檯的整個過程才是一次完整的使用，即一個業務用例。

      除了這個標準之外，另一個實用的方法就是將密切相關服務的說明放在一起，這樣您可以同時對它們進行複審、修改和測試，為它們編寫手冊，並將它們作為一個單元來管理。

      值得注意的是兩個獨立的業務用例可能有相似的開始。

      樣本：
      在保險公司中，業務用例“索賠處理”和“申保處理”都以某人 (主角) 與申請處理員的聯絡開始。申請處理員和主角交換資訊，確定對方需要賠償還是保險諮詢。然後，也只有在此時，才可以確定應該執行哪個業務用例。儘管兩個業務用例有相似的開始，但它們之間卻是相互獨立的。

四、名稱

      業務用例的名稱應該能夠描述執行業務用例執行個體時所發生的情況。因此，名稱的形式應該是主動的，通常使用動詞的動名詞形式 (Checking-in) 或同時使用動詞和名詞。

      名稱也可以從外部或內部的角度來描述業務用例中的活動，如“訂購”和“收到訂單”。儘管業務用例描述業務中發生的事情，但它常會很自然地從主要主角的角度來命名業務用例。一旦確定了要使用的命名方法，就要在業務模型中對所有業務用例遵循同樣的規則。

五、目標

      業務用例的目標應該至少從兩方面來說明：

      為那些與商務程序互動的業務主角指定它們期望業務能實現的價值（外部目標）。 
      從使用商務程序的組織的角度，明確開發該商務程序的目的是什麼以及希望通過該流程達到什麼目標（內部目標）。 

六、效能目標

      最常用的分類指標是：

      時間 - 執行工作流程或部分工作流程大致需要的時間。 
      成本 - 執行工作流程或部分工作流程大致需要的成本。 

      困難的是理解哪些情境（業務用例執行個體）與評測有關。判斷的標準可以是情境使用的頻率，或情境的業務相關性。如果能確定工作流程中的重要部分，您只要評測這個分支流的成本或時間就可以了，這樣可以減少許多工作量。

七、工作流程 - 結構

      大多數工作流程可以看作是由多個分支流組成的，這些分支流共同組成了整個流程。有時候，業務中多個業務用例會有共同的分支流，或是同一個分支流出現在一個業務用例的不同部分。如果這種共同行為出現的情況較頻繁，則應該由同一個角色來執行。

      如果某個分支流具有實質內容，為多個業務用例公用並且形成一個自然定界的獨立部分，那麼應該將該行為分離出來，作為一個獨立的業務用例，這樣會使模型更加清晰。這時，這個新的業務用例要麼包含於原始用例（請參見指南：業務用例模型中的內含項目關聯性）或是原始用例的擴充（請參見指南：業務用例模型中的擴充關係），要麼是原始用例的父用例（請參見指南：業務用例模型中的用例泛化關係）。

      樣本：
      在機場登記處，個人登記和團體登記兩個業務用例使用同一個過程來處理個人旅客的行李。因為此分支流獨立於機票處理，而且在邏輯上是聯絡在一起的，所以此分支流在行李處理 (Baggage Handling) 業務用例中被單獨建模。

      可以使用活動圖表以可視化方式表示業務用例的工作流程，請參見指南：業務用例模型中的活動圖表。

      有關構建和描述業務用例工作流程的詳細資料，請參見指南：用例中關於“事件流”的討論。

八、工作流程 - 樣本

      某組織向單個客戶銷售專門配置的解決方案，以下是對其“投標流程”業務用例中工作流程的描述。在指南：業務用例模型中的活動圖表的“使用樣本”一節中，您可以找到一個活動圖表樣本，該圖以可視化的方式顯示了此工作流程的結構：

1. 基本工作流程

      1.1. 最初接觸

      此流程從客戶和公司之間的最初接觸開始。最初接觸可能採取以下方式之一：

      客戶與公司聯絡，提出詢問或一系列需求。
      公司確定自己的產品能為客戶創造價值，同時為公司創收。
 
      公司與客戶聯絡以確定：

      客戶連絡人，
      公司連絡人，
      該客戶是否是公司的新客戶，
      所有圍繞此協議的有關投標的競爭資訊。

      1.2. 最初機會工作

      這部分工作有兩個主要目的：

      搜集客戶需求，
      決定針對此機會的進一步行動。
      初步搜集客戶需求、制定銷售計劃（可選）、進行機會分析各步驟可以按迭代方式進行，有時也可以稍做並行。

      1.2.1 初步搜集客戶需求

      搜集產品需求和客戶業務需求，方法如下：

      詢問客戶
      考慮所有客戶輸入
      進行初步的現場調查（可選）
      研究一切可用的客戶資訊

      一整套需求應該包括：

      技術選擇（如果客戶希望研究多種備選方案，則可能有多個選擇）
      所有產品喜好設定
      功能性需求（市場分析）
      構建結構和環境特徵
      人數統計
      機動性/容量
      網路增長預測
      確定的基礎資訊
      時間軸
      服務需求
      價格需求

      1.2.2 制定銷售計劃（可選）

      公司與客戶合作，確定如何提出一個滿足客戶需求的解決方案。制定銷售計劃，其中包括潛在解決方案的當前網路和轉換特徵。還要討論公司的戰略定位和其網路情況，這樣我們可以為滿足進一步的需要作準備。
然後，同客戶一起對此銷售計划進行複審，保證它精確完整。該計劃將在整個投標流程中發揮指導作用，協助確定要建議的產品、市場封裝或貨品明細分類項，以及整理標書所要進行的假設。

      1.2.3 進行機會分析

      公司將獲得有關潛在解決方案高水平價位及成本的資訊。這樣做是為了瞭解此機會的潛在價值，而不是為客戶提供一個精確的報價。
隨後公司考慮客戶需求，以確定：

      機會中的風險（產品可用性、競爭、客戶風險）
      成本和收入的比較
      機會類型（簡單、複雜等）
      銷售的可能性
      大概的銷售量數字
      大概的時間表
 
      根據這些估計，公司就是否繼續此機會作出決策。

      1.3. 制定投標專案計劃

      公司將制定一個計劃，來制定並提交標書。計劃中應包括投標中各部分工作的分配情況。

      1.4. 制定交付專案計劃

      根據以下資訊，公司將制定一個交付解決方案的暫訂專案計劃：

      客戶需求中的期限
      資源可用性
      生產能力
      新產品的可用性
      第三方產品的可用性
      此專案計劃將用於制定未來的生產計劃。

      另外，此專案計劃將在“報價流程”進行更新和修改。

      1.5. 準備報價

      該步驟在業務用例“報價流程”中有詳細說明。
“報價流程”結束時應有一個設計好的解決方案。該方案可能具有不同程度的確定性，而且要提供價格。

      1.6. 編輯其他資訊

      公司編輯資訊來回答客戶的所有詢問（這些詢問通常牽涉到未來的產品開發，它們可能是客戶業務需求的一部分）。這些資訊還包括公司認為客戶應該瞭解的資訊。詢問通常分為以下幾類：

      技術
      當前的效能
      未來的效能
      符合標準
      符合未來的標準
      當前提供的服務
      未來將提供的服務。
 
      1.7. 分析並完成標書

      公司編輯完成標書，其中包括以下資訊：

      報價
      現成的市場材料（已有）
      產品資訊（已有）
      財務條款
      進度資訊
      按標書要求水平進行財務分析匯總
      客戶與公司各自的責任和處罰
      法律“環境”聲明
      制定標書中的解決方案時所作的所有假設
      公司將這些資訊編輯為可呈交給客戶的標書。

      1.8. 呈交標書

      公司向客戶提交或提出以上資訊。

      1.9. 獲得客戶決策資訊

      客戶將對標書進行反饋。公司獲得客戶對標書中報價的認可。根據客戶和解決方案特點的不同，這種認可可以有多種不同的形式。
可能是：

      一份正式簽署的購貨訂單
      一個客戶將發出購貨訂單的口頭協定
      一個正式簽署的合約
      一個口頭協定

      如果在有效期間內未作出任何決定，則視為拒絕

2. 備選工作流程

      2.1. 放棄商機

      在 1.2. 中，如果放棄商機，則可以採取以下措施：

      完全放棄
      嘗試與其他供應商合作
      重新定向到其他領域
      將請求轉寄給其他經銷商/供應商
      嘗試改變客戶需求
 
      2.2. 無法滿足客戶需求

      如果在進行機會分析或報價準備的過程中，公司不能針對客戶的需求提出解決方案，那麼可能要採取以下措施：

      建議使用另一家廠商的裝置
      重新評估客戶需求
      與公司聯絡以獲得有關未來產品的資訊
      嘗試改變客戶需求
      決定開發新產品
      尋求合資夥伴或供應商
      尋求其他融資方式
      採用不同的折扣方式

      2.3. 關鍵資訊未知

      如果在“投標流程”中公司發現某些關鍵資訊未知或無法得到，可採取以下措施：

      獲得此資訊
      作出假設，然後繼續

      如果進行了假設，則必須對假設進行記錄並作為標書的附帶文檔交給客戶。

      2.4. 新的、不完整的或不正確的一般客戶簡檔

      如果公司認為一般客戶簡檔由於某些原因而不準確，則可採取以下措施：

      如果是新客戶，則與之協商達成一致
      包含/確定客戶偏好
      確定已安裝的資訊庫
      請求對記錄進行更新

九、可能性

      業務用例的可能性應反映出業務用例在流程和規模方面進行改進的潛力。參考您指定的業務用例指標。

十、擴充點

      擴充點使業務用例有進行擴充的可能。它有一個名稱，以及一組對業務用例的工作流程中一個或多個位置的引用。

      另請參見指南：業務用例模型中的擴充關係。

十一、好的業務用例的特徵

      其名稱和簡要說明清晰易懂，甚至對業務建模團隊之外的人來說也是如此。
      從外部（即主角的）角度看，每個業務用例都是完整的。例如，保險公司的“索賠處理”業務用例以一個客戶提交索賠請求開始。如果不包含保險公司向客戶發出有關索賠請求處理決定的通知或（在同意賠償的情況下）保險賠償的支付，則“索賠處理”業務用例是不完整的。
      每個業務用例一般至少涉及一個主角。業務用例由主角啟動，通過與主角進行互動來完成活動並交付結果。
      支援用例可能不與主角進行互動，不過這種情況不太常見。如果業務用例由某個內部事件啟動，並且不必和主角進行互動即可完成活動，則可能出現上述情況。

十二、好的工作流程說明的特徵
 
      說明必須清晰易懂，甚至對業務建模團隊之外的人來說也是如此。
      對工作流程進行描述，而不是僅僅描述業務用例的目的。
      只對業務內部的活動進行描述。
      描述業務用例中所有可能的活動。例如，滿足或不滿足某個條件將分別出現什麼情況。
      不提及那些與其沒有通訊的主角。如果提及了其他主角，將使說明更加難於理解和維護。
      只描述屬於本工作流程的活動，不涉及在其他並行的業務用例中進行的活動。
      不提及無關的業務用例。如果業務用例要求在業務開始之前某種結果必須存在於業務中，則應該將其作為前置條件進行描述。但對前置條件的描述不應該涉及產生此結果的業務用例。
      如果業務用例中活動的順序不固定，說明中應該指出這一點。
      有結構地進行說明，這樣易於閱讀和理解。
      說明清晰地描述了工作流程的開始和結束。
      清楚地說明每個擴充關係，這樣插入業務用例的方式和時間將顯而易見。

十三、好的抽象業務用例的特徵

      具有實質性。請記住，具體業務用例與其抽象業務用例必須易於理解。因此，一個抽象業務用例不應該太小。如果某個抽象業務用例不具有實質性，您應該將其刪去，而其活動應在受影響的具體業務用例中進行說明。
      它包含邏輯上相關的活動。
      它為某個特定原因而存在。一個抽象業務用例應該包含以下三類活動中的任意一類：多個業務用例中共用的活動；可選的活動；或那些非常重要、要在模型中強調的活動。