拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即
uml中的用例模型和邏輯模型。
在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件模型和分析模型的概念。
言歸正傳，先來看用例模型。
用例模型
用例模型包含了兩部分：業務用例模型和系統用例模型。從字面的意義來看，確實很難分清兩者究竟在做些什麼工作。因此我們要重點解釋一下。
業務用例模型的目的在於：
1．描述企業的內部組織結構
2．描述企業各部門的業務
3．關注於角色和系統的互動介面
系統用例模型的目的在於：
1．關注於演示對系統的需求
2．拋棄部門的功能，更加細化
3．系統用例模型應該劃分子系統以對應不同的功能
這二者最大不同點在於：業務用例模型僅關注於企業部門的業務，而系統用例模型則關注於系統本身實現後的互動。
圖素業務用例模型和系統用例模型有共同的圖素，但是在意義上是完全不同的
角色：業務用例模型
系統用例模型
對於角色來說，業務用例模型有兩種角色的變體，分別是業務角色和業務員工。系統用例模型則沒有業務員工，只有業務角色。而它們的含義又是不同的。
在業務用例模型中，業務角色代表企業外的角色，業務員工代表企業內的角色。例如對於商店來說顧客就是它的業務角色，而售貨員就是它的業務員工。
在系統用例模型中，業務角色代表系統外的角色。例如對於銷售管理系統來說，任何乙個操作員都是業務角色，因為它不屬於系統內。
用例：業務用例模型
系統用例模型
對於用例來說，業務用例模型因為需要描述部門的業務，因此它將使用一般用例的變體：業務用例。而系統用例模型則只需要使用用例的本體就可以了。二者的區別在於，業務用例的粒度很粗，它只描述部門的總體業務；用例的粒度很細，需要描述到系統中業務場景的工作。
業務用例模型工作流程
step-1：建立業務用例物件模型的包
使用包的變體「
business use case model
」：
step-2：建立用例物件的角色
建立業務員工和業務角色。
step-3：建立組織結構圖
製作業務用例模型時，需要通過擴充套件的關係來將各個業務員工和業務角色組織起來，形成組織結構圖。（說明：需要通過抽象將業務員工的組織關係描述得清晰一些，而業務角色可能沒有階層的關係）
組織結構圖的包應該使用包的變體「
organization unit
」：step4：建立業務用例
使用業務用例和業務員工、業務角色來粗略的描述部門的業務工作。
系統用例模型工作流程
step-1：建立系統用例物件模型的包
直接建立包就可以了：
step-2：建立用例物件的角色
建立業務角色
step-3：建立系統用例
使用業務角色和系統用例來詳細描述系統的工作，業務角色對用例的關係應該設定為「
use」，系統用例之間的關係將使用「
extend
」、「include
」來描述。
系統用例的名字很重要，因為它將直接影響關係的描述。（在任何乙個專案開展時都要對名字本身進行約束，動賓結構，還是主動結構）
比如：有乙個系統用例，名為「維護商品資訊」，顯然如果有乙個業務角色為「商品管理員」，那這個業務角色對「維護商品資訊」的資訊就應該是：
而「維護商品資訊」這個用例的粒度太粗，因此還需要細化它，假使，「查詢商品資訊」和「更新商品資訊」都和「維護商品資訊」是有關係的，那麼它們之間的關係就應該使用「
extend
」、「include
」來描述。請先看下圖：
「查詢商品資訊」和「維護商品資訊」是擴充套件（
extend
）的關係，「更新商品資訊」和「維護商品資訊」是包含（
include
）的關係。
這樣的圖示說明了什麼？請記住，擴充套件關係是指對於被擴充套件方（在這裡指「維護商品資訊」），擴充套件方（在這裡指「查詢商品資訊」）是非必要實現的，也即沒有「查詢商品資訊」，一樣可以叫做「維護商品資訊」。但是相對包含關係就不一樣，「更新商品資訊」對於「維護商品資訊」來說是必須實現的乙個用例，如果沒有「更新商品資訊」就沒有「維護商品資訊」了。此外，對於擴充套件關係，還有乙個條件，就是擴充套件方應該在被擴充套件方用例實現的基礎上進行的擴充套件。因此對於上圖，若要表達的更清晰，則可以這樣畫：
這樣的結果，告訴了看這個用例的人乙個這樣的資訊：更新商品資訊後可以查詢其他商品資訊。
請再看乙個例子：
這個用例圖告訴了我們這樣的資訊：
step-1
商品管理員首先要提取商品資訊
step-2
在提取商品資訊的同時，需要獲取商品單價，這是必須完成的
step-3
提取商品資訊後可以更新商品資訊和列印商品資訊
step-4
對於列印商品資訊而言合計商品總量是必須完成的乙個工作
從剛才的圖中我們只看到了用例的關係和系統角色在各個階段所做的乙個大體工作，但是對於系統用例來說，每個用例都應該進行必要的描述（這點對於用例來說就是場景的描述）。
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...
關於業務用例
本來想把這專案的過程全部記錄下來的,可惜.實言了 這次來講一下用例吧.我這公司是 公司.和公司打交道的就是客戶和 商 其實 商也是客戶 客戶買.公司向 商買.所以呢.其實我就只有二個業務用例.好了,最外圍的邊界已經確定了.這二個用例就是 買產品 和 賣產品 圖我就不畫了,大家發揮想像力吧.要記住這個...