業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。
第乙個壞訊息：編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去做將會有所幫助，但通常編寫者和讀者不會認識到這樣做的重要性。使用系統用例的讀者批評業務用例所處層次太高，但卻沒有認識到提供系統詳細行為細節不是業務用例應該做的。業務用例編寫者偶爾把系統行為細節寫入其中，結果導致業務主管對這類有詳細細節行為的文件失去了興趣。
為了減少這種混亂，應該經常在用例模板中寫明用例範圍及層次，讓用例編寫者依此規則編寫，同時讓讀者了解這些規則。如果可以的話，盡量對用例使用圖示。對兩者使用稍微不同的模型和用完全不同的數字進行編號（如一組從
1000開始對用例編號，另一組從1開始編號）。同時，編寫一些可以直接使用和視覺化的構件。這樣就可以既能充分利用這種合作關係，又不會讓人混淆。
第二個壞訊息：完全且正確地連線系統和使用者用例不太值得。通常，業務用例編寫者應對業務過程到系統使用（通常沒有描述）進行描述。而在描述日常生活中客戶如何使用新系統之前，用例編寫者已經花光時間、財力、精力及熱情。而系統用例編寫者有時為了保持一致，會在業務過程中加一兩句，但是他們通常不願意重寫乙個包含新系統功能的業務用例。
在完整的業務用例展開為系統用例方面，我有一些成功的經驗。根據我的經驗，通常把業務用例分為
3個層次：開始是少數幾個黑盒、雲朵級業務用例；然後很快轉換為白盒、雲朵級業務用例；最後展開為白盒、風箏級業務用例。
然而，在此過程中，看不到業務用例和系統用例之間清晰的連線。
在下面的論述中，firepond的rusty walters闡述了他在業務過程用例方面的經驗。
◆ rusty walters：業務建模和系統需求
受益於早先曾經閱讀過你的書，我通過以前的嘗試能夠對問題合理規劃，並且能利用新的知識。
閱讀前的經歷：
在閱讀這本書之前，我從事過產品組中幾個應用程式功能需求文件的編寫工作。
在乙個應用程式開發中，我們編寫各個層次的系統用例，包括概要級、使用者級和子功能級。我們主要集中在系統功能方面。對建模後的結果也非常滿意，它非常易於理解。同時，我們也覺得沒有開發業務用例來展示整個環境的必要，系統概要用例就包括了我們全部的需求。
在另乙個應用程式開發中，雖然還是同樣的開發組負責用例
建模，情況卻完全不同。回顧起來，我明白問題的癥結在於，不同組的成員從不同角度接近系統。我從業務過程到技術進行建模，有的人卻從技術到業務過程進行建模。毫無疑問，在兩組設計人員中，每個用例的設計範圍不清晰。
在從業務過程到技術進行建模的組中，他們從不編寫系統用例；而在從技術到業務過程進行建模的組中，他們也從不編寫業務用例。相反，由於兩組都希望直接利用對方編寫的用例，因此難免正面衝突和相互指責。由於當時對界定用例範圍層次沒有遠見並且缺少必要的理解，用例模型變得相當混亂。直到最後，整個小組對用例模型仍不滿意。
事實上，整個小組都知道這樣有問題，但卻不知道癥結何在。
閱讀後的經驗：
正如我在乙個試圖理解和文件化開發過程的小組中發現的，從核心業務到技術進行建模似乎不會導致什麼混亂。
160
我們一起討論業務過程及其內部工作方式（不包括軟、硬體系統）時，每乙個人都很清楚。而混亂出現的區域確實與業務和部門的範圍有關係。
我們從業務中很概要級（雲朵級）的黑盒用例開始，大家對這些用例都很清楚，甚至包括那些從事底層建模的人。然後，如書本中所說的一樣，很快寫出很概要級（雲朵級）的白盒用例。
當我們決定討論下一低層次用例時，設計域（即我們是討論整個業務，還是某個部門）引發的混亂出現了。這個問題也與如何建立後續用例有關。在乙個特殊的例子中，當我們認識到那些應該在呼叫用例中實現，而不應該作為當前用例的一部分後，刪除了上面兩個步驟。同時開發組也不打算把業務用例展開為系統用例需求。
雖然在會議期間很難注意和修正整個過程，但會後，對問題域的理解相對容易一些。在文件化會議結果的過程中，我使用設計域語境圖，用圖標明每個用例的範圍和層次。如果圖足夠簡單，就會給讀者留下深刻印象，並直接浮現在讀者腦海中。
本文節選自《編寫有效用例》一書
[美]alistaircockburn（阿利斯泰爾.科伯恩) 著
王雷，張莉譯
圖書詳細資訊:
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...
關於業務用例
本來想把這專案的過程全部記錄下來的,可惜.實言了 這次來講一下用例吧.我這公司是 公司.和公司打交道的就是客戶和 商 其實 商也是客戶 客戶買.公司向 商買.所以呢.其實我就只有二個業務用例.好了,最外圍的邊界已經確定了.這二個用例就是 買產品 和 賣產品 圖我就不畫了,大家發揮想像力吧.要記住這個...