前文介紹了系統用例，在這一節中，我們將討論的是用例描述 和邏輯模型 的工作。
從任何乙個環節我們都會看到用例，但是僅僅依靠用例本身的圖來描述用例是不夠的，為什麼呢？因為用例它所要描述的是乙個場景，換句話說，就是用例是描述了某件詳細的事情。如果作為乙個場景的話必然要考慮這麼幾個問題：
l 誰在這個場景中做事？
l 什麼時候進入這個場景？ l
這個場景在做什麼？ l
這個場景有沒有特殊規則？ l
這個場景結束後會有什麼情況？ l
這個場景和別的場景會有什麼聯絡？
考慮這幾個問題的話，那我們就可以開始描述我們的用例了，這步工作我們就稱為用例描述。
好了，我們針對這幾個問題乙個個來給出它們的標準定名： l
誰在這個場景中做事？
我們稱之為參與者 l
怎麼會進入這個場景？
我們稱之為前置條件 l
這個場景在做什麼？
我們稱之為基本操作流程、可選操作流程 l
這個場景有沒有特殊規則？
我們稱之為業務規則 l
這個場景結束後會有什麼情況？
我們稱之為後置條件 l
這個場景和別的場景會有什麼聯絡？
我們稱之為相關用例
讀過我之前一篇的朋友一定會記得用例分為業務用例和系統用例兩種。針對這兩種用例，相對來說都會根據這些標準定名來描述用例。
只是，有許多人習慣在業務用例中不作描述，或者只是簡單的描述一下，這點我認為無所謂，因為業務用例是描述企業的組織機構中各部門的業務，它的用例實在是很粗的，它本身的目標只在於可以及時得在談需求時記錄下企業的業務。不過我認為最好的做法是在業務用例的階段，我們需要將業務用例劃分出來，然後根據調研的結果將業務流程清晰的描述出來，表達的方式就不用太過拘泥，最簡單的就可以是「我做1->
我做2->
我做3…
」。
而在系統用例部分則不得不清晰得來表明每個用例的場景，演示系統的需求，描述系統的功能。那麼這裡我們就用乙個例子來說明一下這些描述吧。
根據之前曾經給出的一組用例來看：
我們來描述「提取商品資訊」這個用例（請注意這是系統用例）。
參與者：
商品管理員
參與者的意思是，誰在對這個用例進行使用
前置條件：
1. 商品管理員登陸 ***
系統後擁有能夠操作該用例的許可權
2. 商品資訊的名稱、生產日期可以被商品管理員獲取作為條件
前置條件的意思是，在怎樣的前提下，該用例才有可能被使用。
基本操作流程：
商品管理員輸入商品名稱和資訊 ->
系統提取對應的商品並顯示所有商品資訊
可選操作流程：
商品管理員輸入商品名稱和資訊 ->
系統無法根據條件得到對應商品資訊，系統提示商品管理員重新輸入條件
基本操作流程和可選操作流程的意思是，描述用例中基本的操作步驟和系統的反應結果，以及針對同一操作步驟可能會出現的另一種可能性。
業務規則： 1.
在提取商品資訊的時候必須滿足不能提取「安全鎖」型別的商品
業務規則的意思是，在整個用例的場景中，無法在前置條件或後置條件以及基本操作流程和可選操作流程中描述的一些特殊業務規則。該業務規則是隱含的卻是必須的。
後置條件：
1. 被提取的商品其狀態全部變成「已檢視」狀態的商品
後置條件的意思是，在用例結束後會產生怎樣的乙個結果，而該結果可能會對今後的其他用例產生一定的影響。
相關用例：
擴充套件的用例：列印商品資訊、更新商品資訊
被包含的用例：獲取商品單價
相關用例的意思是，能夠在用例的描述中檢視到當前用例與其他用例的關係，一般只有直接與當前用例相關的用例才會被作為相關用例，而且需要使用「擴充套件的用例」和「被包含的用例」來清晰的定義。
這樣，我們的系統用例就完成了，雖然很煩瑣，但是能夠清晰的告之你的客戶 ,
你的系統將會做什麼，不是一件令人很愉快的事嗎？
完成了這一步後，我們接著的工作就需要進入邏輯模型 了。邏輯模型對於我們來說，是為了展示這個系統是怎樣做的。因此它牽涉到的內容就比較多了。而一般而言，對於邏輯模型，我們通常分為做三步：
step-1
：業務物件模型
業務物件模型描述的是現行的業務活動物件之間的關係，是通過從業務用例檢視中調研描述的結果以及角色和客戶交付的文件中的物件演化而來，通過物件合作來實現。
step-2
：分析模型
分析模型屬於推進用例的實現，它是在系統用例模型和業務物件模型基礎上更進一步的對乙個用例的實現說明。它更多的是告訴了我們，針對某個用例，系統會怎樣實現。而在這裡我們就會引出乙個新名詞「用例實現」，也會看到「類」。
step-3
：設計模型
設計模型和分析模型一樣，其實也是告訴了我們針對某個用例系統會怎樣實現，只是設計模型更抽象，它已經要求帶入了實現技術的概念。
需求分析階段的工作（二） 用例描述和邏輯模型
前文介紹了系統用例，在這一節中，我們將討論的是用例描述 和邏輯模型 的工作。從任何乙個環節我們都會看到用例，但是僅僅依靠用例本身的圖來描述用例是不夠的，為什麼呢？因為用例它所要描述的是乙個場景，換句話說，就是用例是描述了某件詳細的事情。如果作為乙個場景的話必然要考慮這麼幾個問題 l誰在這個場景中做事...
需求分析階段的工作（一） 業務用例和系統用例
在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件模型和分析模型的概念。言歸正傳，先來看用例模型。用例模型 用例模型包含了兩部分 業務用例模型和系統用例模型。從字面的意義來看，確實很難分清兩者究竟...
需求和分析階段的任務
需求階段的任務 1 需求說明書 簡單的進行客戶調研，明確專案的功能，並且對功能進行簡單的描述。提供給使用者，用於售前的合同以及 2 需求規格說明書 該說明書屬於合同簽訂以後的成果。需要詳細的進行客戶調研，明確客戶的業務流程，處理的表單資訊等等。規格說明書中需要有業務流程圖，表單的各個域資訊，以及一些...