從任何一個環節我們都會看到用例，但是僅僅依靠用例本身的圖來描述用例是不夠的，為什么呢？因為用例它所要描述的是一個場景，換句話說，就是用例是描述了某件詳細的事情。如果作為一個場景的話必然要考慮這么幾個問題：

• 誰在這個場景中做事？
• 什么時候進入這個場景？
• 這個場景在做什么？
• 這個場景有沒有特殊規則？
• 這個場景結束后會有什么情況？
• 這個場景和別的場景會有什么聯系？

　　考慮這幾個問題的話，那我們就可以開始描述我們的用例了，這步工作我們就稱為用例描述。

　　好了，我們針對這幾個問題一個個來給出它們的標準定名：

• 誰在這個場景中做事？

　　　　　　我們稱之為參與者

• 怎么會進入這個場景？

　　　　　　我們稱之為前置條件

• 這個場景在做什么？

　　　　　　我們稱之為基本操作流程、可選操作流程

• 這個場景有沒有特殊規則？

　　　　　　我們稱之為業務規則

• 這個場景結束后會有什么情況？

　　　　　　我們稱之為后置條件

• 這個場景和別的場景會有什么聯系？

　　　　　　我們稱之為相關用例

　　讀過我之前一篇的朋友一定會記得用例分為業務用例 和系統用例 兩種。針對這兩種用例，相對來說都會根據這些標準定名來描述用例。

　　只是，有許多人習慣在業務用例 中不作描述，或者只是簡單的描述一下，這點我認為無所謂，因為業務用例是描述企業的組織機構中各部門的業務，它的用例實在是很粗的，它本身的目標只在于可以及時得在談需求時記錄下企業的業務。不過我認為最好的做法是在業務用例的階段，我們需要將業務用例劃分出來，然后根據調研的結果將業務流程清晰的描述出來，表達的方式就不用太過拘泥，最簡單的就可以是“我做 1-> 我做 2-> 我做 3… ”。

　　而在系統用例 部分則不得不清晰得來表明每個用例的場景，演示系統的需求，描述系統的功能。那么這里我們就用一個例子來說明一下這些描述吧。

　　根據之前曾經給出的一組用例來看：

　　我們來描述“提取商品信息”這個用例（請注意這是系統用例 ）。

參與者：

　　商品管理員

　　參與者的意思是，誰在對這個用例進行使用

前置條件：

　　1. 商品管理員登陸 XXX 系統后擁有能夠操作該用例的權限

　　2. 商品信息的名稱、生產日期可以被商品管理員獲取作為條件

　　前置條件的意思是，在怎樣的前提下，該用例才有可能被使用。 

基本操作流程：

　　商品管理員輸入商品名稱和信息-> 系統提取對應的商品并顯示所有商品信息

可選操作流程：

　　商品管理員輸入商品名稱和信息-> 系統無法根據條件得到對應商品信息，系統提示商品管理員重新輸入條件

　　基本操作流程和可選操作流程的意思是，描述用例中基本的操作步驟和系統的反應結果，以及針對同一操作步驟可能會出現的另一種可能性。 

業務規則：

　　1.在提取商品信息的時候必須滿足不能提取“安全鎖”類型的商品

　　業務規則的意思是，在整個用例的場景中，無法在前置條件或后置條件以及基本操作流程和可選操作流程中描述的一些特殊業務規則。該業務規則是隱含的卻是必須的。 

后置條件：

　　1. 被提取的商品其狀態全部變成“已查看”狀態的商品

　　后置條件的意思是，在用例結束后會產生怎樣的一個結果，而該結果可能會對今后的其他用例產生一定的影響。 

相關用例：

　　擴展的用例：打印商品信息、更新商品信息

　　被包含的用例：獲取商品單價

　　相關用例的意思是，能夠在用例的描述中查看到當前用例與其他用例的關系，一般只有直接與當前用例相關的用例才會被作為相關用例，而且需要使用“擴展的用例”和“被包含的用例”來清晰的定義。 

　　這樣，我們的系統用例就完成了，雖然很煩瑣，但是能夠清晰的告之你的客戶,你的系統將會做什么，不是一件令人很愉快的事嗎？

　　完成了這一步后，我們接著的工作就需要進入邏輯模型了。邏輯模型對于我們來說，是為了展示這個系統是怎樣做的。因此它牽涉到的內容就比較多了。而一般而言，對于邏輯模型，我們通常分為做三步：

Step-1 ：業務對象模型 

　　業務對象模型描述的是現行的業務活動對象之間的關系，是通過從業務用例視圖中調研描述的結果以及角色和客戶交付的文檔中的對象演化而來，通過對象合作來實現。

Step-2 ：分析模型 

　　分析模型屬于推進用例的實現，它是在系統用例模型和業務對象模型基礎上更進一步的對一個用例的實現說明。它更多的是告訴了我們，針對某個用例，系統會怎樣實現。而在這里我們就會引出一個新名詞“用例實現”，也會看到“類”。

Step-3 ：設計模型 

　　設計模型和分析模型一樣，其實也是告訴了我們針對某個用例系統會怎樣實現，只是設計模型更抽象，它已經要求帶入了實現技術的概念。