用例的具體寫法

1. 引言

前面咱們學習了518需求分析方法，而一個完整的用例，正好體現了518需求分析方法中涉及的內容。

2. 用例元素

一個完整的用例應該包含以下幾個部分：

2.1 【用例名稱】

通常狀況下，用例的名稱即需求的名稱。

2.2 【場景】

場景即用例發生的環境，正好對應5W中的3個W：Who、Where、When

2.3 【用例描述】

描述詳細的用例內容，對應5W中的What和How，即用戶應該怎樣作，以及每一個步驟中的輸出。但並不要求每一個步驟都必定有輸出，能夠有也能夠沒有，也能夠有多個。

2.4 【用例價值】

描述用例對應的客戶價值，對應5W中的Why。

2.5 【約束和限制】

即整個需求流程中相關的約束和限制條件，對應518方法中的8C。

3. 樣例分析和步驟

咱們來看一個簡單的樣例：POS機。

3.1 【第一步：正常處理】

【用例名稱】 買單 【場景】 Who：顧客、收銀員 Where：商店的收銀臺 When：營業時間 【用例描述】

1. 顧客攜帶選擇好的商品到收銀臺；
2. 收銀員逐一掃描商品條形碼，系統根據條形碼查詢商品信息；
3. 掃描完畢，系統顯示商品總額，收銀員告訴顧客商品總額；
4. 顧客將錢交給收銀員；
5. 收銀員清點錢數，輸入收到的款額，系統給出找零的數目；
6. 收銀員將找零的錢還給顧客，並打印小票；
7. 買單完成，顧客攜帶商品和小票離開； 【用例價值】 顧客買完單之後，就能夠攜帶商品離開，而超市也將獲得收入； 【約束和限制】
8. POS機必須符合國標XXX；
9. 鍵盤使用中文，由於收銀員都是中國人；
10. 一次買單數額不能超過99999RMB；
11. POS機要很是穩定，至少一天內不要出現故障；

3.2 【第二步：異常處理】

在第一步的基礎上，咱們增長相關步驟的異常狀況說明和處理，例如以下的黑體字： 【用例名稱】 買單 【場景】 Who：顧客、收銀員 Where：商店的收銀臺 When：營業時間 【用例描述】

1. 顧客攜帶選擇好的商品到收銀臺； （這一步沒有異常）
2. 收銀員逐一掃描商品條形碼，系統根據條形碼查詢商品信息； 2.1 掃描儀壞了，必須支持手工輸入條形碼； 2.2 商品的條形碼沒法掃描，必須支持手工輸入條形碼； 2.3 條形碼可以掃描，但查詢不到信息，須要收銀員和顧客溝通，放棄購買此產品
3. 掃描完畢，系統顯示商品總額，收銀員告訴顧客商品總額； （這一步沒有異常）
4. 顧客將錢交給收銀員； 4.1 顧客的錢不夠，顧客和收銀員溝通，刪除某商品； 4.2 顧客的錢不夠，顧客和收銀員溝通，刪除某類商品中的一個或幾個（例如買了5包煙，去掉兩包） 4.3 顧客以爲某個商品價格過高，要求刪除某商品；
5. 收銀員清點錢數，輸入收到的款額，系統給出找零的數目； （這一步沒有異常）
6. 收銀員將找零的錢還給顧客，並打印小票；
7. 買單完成，顧客攜帶商品和小票離開； 【用例價值】 顧客買完單之後，就能夠攜帶商品離開，而超市也將獲得收入； 【約束和限制】
8. POS機必須符合國標XXX；
9. 鍵盤使用中文，由於收銀員都是中國人；
10. 一次買單數額不能超過99999RMB；
11. POS機要很是穩定，至少一天內不要出現故障；

有的人可能會認爲第三、第五、第6步都應該有異常，例如系統壞了應該怎麼處理。 但實際上咱們沒有必要這麼寫，由於用例分析的目的是爲了詳細分析爲了實現客戶價值，系統應該怎麼作，若是系統自己都壞了，這個就不是用例關注的內容了。

須要注意的是：用例分析中的「異常」是指流程的異常狀況，而不包含系統自己的的異常。

3.3 【第三步：替代處理】

在第二步的基礎上，咱們增長替代處理。即：有的步驟能夠換一種方式來實現。例如以下用例中的付款方式，能夠有信用卡支付、會員卡支付、購物卡支付等。 【用例名稱】 買單 【場景】 Who：顧客、收銀員 Where：商店的收銀臺 When：營業時間 【用例描述】

1. 顧客攜帶選擇好的商品到收銀臺； （這一步沒有異常）
2. 收銀員逐一掃描商品條形碼，系統根據條形碼查詢商品信息； 2.1 掃描儀壞了，必須支持手工輸入條形碼； 2.2 商品的條形碼沒法掃描，必須支持手工輸入條形碼； 2.3 條形碼可以掃描，但查詢不到信息，須要收銀員和顧客溝通，放棄購買此產品
3. 掃描完畢，系統顯示商品總額，收銀員告訴顧客商品總額； （這一步沒有異常）
4. 顧客將錢交給收銀員； 4.1 顧客的錢不夠，顧客和收銀員溝通，刪除某商品； 4.2 顧客的錢不夠，顧客和收銀員溝通，刪除某類商品中的一個或幾個（例如買了5包煙，去掉兩包） 4.3 顧客以爲某個商品價格過高，要求刪除某商品； 4-A：顧客使用信用卡支付 4-A.1 信用卡支付流程（請讀者自行思考完善，能夠寫在這裏，若是太多，也能夠另外寫一個子用例） 4-B：顧客使用購物卡支付 4-B.1 購物卡支付流程 4-C：顧客使用會員卡積分支付 4-C.1 會員卡積分支付流程
5. 收銀員清點錢數，輸入收到的款額，系統給出找零的數目； （這一步沒有異常）
6. 收銀員將找零的錢還給顧客，並打印小票；
7. 買單完成，顧客攜帶商品和小票離開； 【用例價值】 顧客買完單之後，就能夠攜帶商品離開，而超市也將獲得收入； 【約束和限制】
8. POS機必須符合國標XXX；
9. 鍵盤使用中文，由於收銀員都是中國人；
10. 一次買單數額不能超過99999RMB；
11. POS機要很是穩定，至少一天內不要出現故障；

通過上面步步爲營，逐步細化和求精，咱們已經獲得了一個比較完善的需求了，這個過程當中並無高深的技巧，也沒有涉及須要豐富的經驗。

有的讀者可能會有疑問：我怎麼知道第4步有那些異常、那些替代方案呢？ 其實很簡單：問你的客戶！客戶是最清楚了，但若是你不問，嘿嘿，客戶倒不必定會告訴你：）

但只要咱們掌握了NEA用例分析方法，即便客戶忘記了，或者沒有意識到，咱們也會將需求挖出來，這樣需求就不會遺漏。

4. 要畫圖嗎

你們能夠看到，咱們在前面進行用例分析的時候，並無看到任何圖，而是純文本！

對於那些UML狂熱分子來講，這多是難以接受的，怎麼能沒有圖呢？UML中的用例圖不就是用來分析需求的麼？

咱們固然不懷疑UML的權威性，但任何東西都有侷限性，UML也不例外。UML的侷限就在於UML是一個建模的語言，就像漢語、英語同樣，只是一種表達形式，而不是一種分析和創做方式。

好比說你會漢語，但並不表明你就能寫小說，你會畫UML用例圖，但並不表明你就能作需求分析。相反，必須是有了需求和用例以後，纔有用例圖，說白了，用例圖是用例的圖形化描述，可是它並不能取代用例。

除了UML自己的侷限性外，還有另一個更重要的緣由：用例是客戶和公司關於產品的一個共同認識！通常狀況下，市場人員和客戶溝通交流，瞭解客戶的需求，而後和客戶一一確認，最後造成需求文檔。在這個過程當中，主要是客戶和市場人員參與，而沒有研發的人員參與。

對於客戶來講，他確定是以天然語言，而不會用UML來描述需求；對於市場人員來講也同樣，他可能對UML一竅不通，甚至他之前可能都是賣醫療器械，甚至有多是狗皮膏藥的，他還管你什麼軟件工程，什麼UML？

5. 小結

因此，採用用例方法分析需求的時候，咱們都是採用純文原本描述需求的，而不會採用用例圖來分析需求