查詢業務參與者
業務參與者可以是與業務互動的任何個人、小組、組織、公司或機器，例如：
如果您打算建模的業務是大型公司的一部分，這些類別還可以包含諸如以下的業務參與者：
要考慮業務建模的範圍和您定義為「目標組織」的業務的邊界，這很重要。如果您只選擇了業務的一部分作為目標組織，那麼同一家公司的其他部分也將是業務參與者。
命名每個業務參與者，採用的命名方式是其名稱代表它在業務中的角色。通過編寫簡要描述定義每個業務參與者，該簡要描述考慮到參與者的職責及其與業務互動的原因，包括業務參與者想從業務中獲得的附加價值的型別。
查詢業務用例
要查詢主要業務用例，請考慮每個業務參與者從業務接收到的價值。問您自己：業務參與者期望從業務中接收到什麼服務。它可能有助於以核心業務用例開始 － 核心業務用例即那些服務於客戶（在不存在**互動的情況下則服務於客戶的等同物件）的用例。
研究業務參與者的生命週期是有幫助的，它可以確定以下問題的答案：
從支援業務的角度，流程也可以表示為業務用例。問您自己：為了向客戶交付產品和服務，什麼是必需的。當然，業務建模的範圍以及定義的業務建模目標將確定支援業務用例的詳細程度（如果您打算考慮它們的話）。尋找以下種類的流程：
從管理業務的角度出發，流程可以表示為業務用例，儘管從資訊系統方面來講很少會對它們感興趣。要確定管理流程，請尋找與將業務作為乙個整體管理相關聯的任務，以及通常與所有者參與者互動的任務。考慮所有者參與者從業務中接收到的內容。搜尋可實現以下目標的任務：
此類流程的生命週期常常跨越乙個財政年度。
確定業務用例的另乙個方法是讓領域專家描述現有業務中的每項任務。 然後將這些任務分組為已命名並進行了簡要描述的業務用例。
考慮業務目標
複審所有已描述的業務目標，並考慮業務用例是否會支援這些目標。如果您發現業務用例支援兩個完全不同的目標，您可以考慮將該用例分成兩部分。如果業務用例支援差別很大的業務目標，您將發現很難度量或改善其效能。不支援任何已確定的業務目標的業務用例可能是不必要的。另一方面，這些業務用例的進一步調查可能揭示未發現的業務目標。
還必須與業務參與者相比較來考慮業務目標。確定的業務目標是否將業務朝這些目標計畫要包含的業務參與者的方向推進？ 是否存在業務目標未針對的任何業務參與者？ 在此分析期間還可能發現新的業務目標。
劃分業務用例的優先順序
一旦您確定了業務參與者和業務用例，您必須劃分那些能引起高度興趣從而必須詳細描述的業務用例的優先順序。要確定高優先順序的業務用例：
生成業務用例工作流程的概述
為理解業務用例的目的，您常常需要工作流程的分步概述。將在隨後指定業務用例的人員也將需要此分步描述。
例如，業務用例「個人檢入」的分步工作流程描述的第一稿可能看起來如下：
請注意，這是第一稿，因此它可能缺少一些任務，這些任務將在以後發現。您還可以將備用流程包含在這組初始步驟中。第一稿使人們可以清晰地了解：業務用例將做什麼，何時開始，何時結束，它提供什麼價值。通常，您為業務用例定義粗略的分步概述的時間不會超過乙個小時。（但支援業務用例和管理業務用例的概述除外 － 它們通常並不涇渭分明。）
重點關注最重要的業務用例 － 也就是，代表最高改進可能的用例。是否可以增加業務用例的範圍，以便最初由客戶執行的工作或者無人執行的工作現在由目標組織執行？ 是否可以縮小範圍，以便客戶現在將執行先前由目標組織執行的任務？ 如果乙個業務用例能更好地為客戶提供服務，則該用例得到了改進，這暗示它變得更簡單，能生產更好的產品，提供更短的前導時間，等等。「客戶應該能夠直接接觸業務的核心部分」。
對於每個業務用例，設定可度量的目標，這些目標可以用來驗證您是否已成功。隨後這些業務目標可以進行優化，並轉換成其他業務目標，以及轉換成業務策略。當建立新的目標組織時，業務目標可用來持續地度量業務用例如何執行，如何改進。
描述業務參與者和用例如何互動
確定那些與業務用例互動的業務參與者，方法是定義它們之間的通訊關聯。如果顯示誰啟動通訊是很重要的，則您可以向關聯新增可導航性。如果它改進了模型的可讀性，您還可以命名該關聯。
封裝業務用例和參與者
如果您有許多業務用例，您可以將它們分成各個包，以使文件易於理解。例如，可以根據型別（例如市場、法規實體和合作夥伴）封裝業務參與者。業務用例可以根據目的分組，例如銷售和市場、產品開發以及管理。另外，它們也可以根據業務參與者分組，例如股東和投資者或直接消費者。
在用例圖中顯示業務用例模型
用例圖說明業務參與者、業務用例及其關係的組合。圖可以包含任何以下內容：
請注意最重要業務用例的圖可以充當完整業務用例模型的摘要，從而證明對其進行複審是有幫助的。
撰寫業務用例模型調查
業務用例模型的調查描述需要表述以下資訊：
評估結果
在此狀態下，請確保檢查業務用例模型，以驗證您的工作是否處在正軌。但是，不要詳細地複審模型。您還必須在對業務用例模型進行操作時考慮業務用例模型的核對表。相關各方必須確定：
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...
關於業務用例
本來想把這專案的過程全部記錄下來的,可惜.實言了 這次來講一下用例吧.我這公司是 公司.和公司打交道的就是客戶和 商 其實 商也是客戶 客戶買.公司向 商買.所以呢.其實我就只有二個業務用例.好了,最外圍的邊界已經確定了.這二個用例就是 買產品 和 賣產品 圖我就不畫了,大家發揮想像力吧.要記住這個...