## 連載：面向對象葵花寶典：思想、技巧與實踐（18） - 用例分析 很多人在分析需求的時候，采用的是東扯葫蘆西扯瓢的方式，列出了很多的需求點，但當你看完后，你還是不知道到底要干嘛！！ ?---- 寫在前面 用例，英文名稱Use?Case，英文和中文都是很好理解，因為大家都這么用，我們暫且不去追究名稱上的問題，只要知道“用例是用來描述需求的流程”，即：**描述5W1H中的How**。 ? 看起來用例應該很好寫，因為用例是描述需求的流程的，而需求的流程一般都是客戶根據自己的業務總結出來，然后告訴我們的。我們只要將客戶描述的內容記錄下來即可，既簡單又輕松！ ? 但現實與理想總是有差距的，你可能會遇到一個對業務并不十分熟悉的客戶，又或者和你交流的人員是客戶的臨時工，還有可能和你交流的人馬上要休婚假了，他巴不得趕快了結這個無聊的事。。。。。。總之，各種各樣的情況都可能出現，就是完美的情況不會出現！ ? 這種情況下，我們如何才能做到完善的分析呢？我們怎么知道我們的分析是否正確，是否有遺漏，是否足夠了？ ? 一般的情況下，公司里負責需求分析得人員都是資深的員工，對領域、對系統有一定的積累和經驗，即使面對這些情況，也可以通過自己的經驗來彌補。 ? 但對于一個菜鳥，遇到這種情況應該怎么辦呢？難道菜鳥就不能做需求分析了么？ ? 別慌，菜鳥雖然沒有經驗，但只要掌握正確的方法，一樣可以做出很好的需求分析，這就是我總結的用例三部曲方法，又或叫做NEA方法。 ? 我總結出的用例方法三段法（NEA方法）： 1）?正常處理（Normal）：通過和客戶溝通，分析需求的正常流程； 2）?異常處理（Exception）：在正常處理流程的步驟上，分析每一步的各種異常情況和對應的處理； 3）?替代處理（Alternative）：在正常處理流程的步驟上，分析每一步是否有其它替代方法，以及替代方法如何做； ? 經過這簡單三步后，How可以說分析得八九不離十了。 ### 【用例的具體寫法】 前面我們學習了518需求分析方法，而一個完整的用例，正好體現了518需求分析方法中涉及的內容。 一個完整的用例應該包含如下幾個部分： 【用例名稱】 一般情況下，用例的名稱即需求的名稱。 【場景】 場景即用例發生的環境，正好對應5W中的3個W：Who、Where、When 【用例描述】 描述詳細的用例內容，對應5W中的What和How，即用戶應該怎樣做，以及每個步驟中的輸出。但并不要求每個步驟都一定有輸出，可以有也可以沒有，也可以有多個。 【用例價值】 描述用例對應的客戶價值，對應5W中的Why。 【約束和限制】 即整個需求流程中相關的約束和限制條件，對應518方法中的8C。 ? ? 我們來看一個簡單的樣例：POS機。 **【第一步：正常處理】** | 【用例名稱】 買單 【場景】 Who：顧客、收銀員 Where：商店的收銀臺 When：營業時間 【用例描述】 1.?顧客攜帶選擇好的商品到收銀臺； 2.?收銀員逐一掃描商品條形碼，系統根據條形碼查詢商品信息； 3.?掃描完畢，系統顯示商品總額，收銀員告訴顧客商品總額； 4.?顧客將錢交給收銀員； 5.?收銀員清點錢數，輸入收到的款額，系統給出找零的數目； 6.?收銀員將找零的錢還給顧客，并打印小票； 7.?買單完成，顧客攜帶商品和小票離開； 【用例價值】 顧客買完單以后，就可以攜帶商品離開，而超市也將得到收入； 【約束和限制】 1.?POS機必須符合國標XXX； 2.?鍵盤使用中文，因為收銀員都是中國人； 3.?一次買單數額不能超過99999RMB； 4.?POS機要非常穩定，至少一天內不要出現故障； **【第二步：異常處理】** 在第一步的基礎上，我們增加相關步驟的異常情況說明和處理，例如如下的黑體字： 【用例名稱】 買單 【場景】 Who：顧客、收銀員 Where：商店的收銀臺 When：營業時間 【用例描述】 1.?顧客攜帶選擇好的商品到收銀臺； （這一步沒有異常） 2.?收銀員逐一掃描商品條形碼，系統根據條形碼查詢商品信息； 2.1?掃描儀壞了，必須支持手工輸入條形碼； 2.2?**商品的條形碼無法掃描，必須支持手工輸入條形碼；** 2.3?**條形碼能夠掃描，但查詢不到信息，需要收銀員和顧客溝通，放棄購買此產品** 3.?掃描完畢，系統顯示商品總額，收銀員告訴顧客商品總額； （這一步沒有異常） 4.?顧客將錢交給收銀員； 4.1?**顧客的錢不夠，顧客和收銀員溝通，刪除某商品**； 4.2?**顧客的錢不夠，顧客和收銀員溝通，刪除某類商品中的一個或幾個（例如買了5包煙，去掉兩包）** 4.3?**顧客覺得某個商品價格太高，要求刪除某商品；** 5.?收銀員清點錢數，輸入收到的款額，系統給出找零的數目； （這一步沒有異常） 6.?收銀員將找零的錢還給顧客，并打印小票； 7.?買單完成，顧客攜帶商品和小票離開； 【用例價值】 顧客買完單以后，就可以攜帶商品離開，而超市也將得到收入； 【約束和限制】 1.?POS機必須符合國標XXX； 2.?鍵盤使用中文，因為收銀員都是中國人； 3.?一次買單數額不能超過99999RMB； 4.?POS機要非常穩定，至少一天內不要出現故障； 有的人可能會認為第3、第5、第6步都應該有異常，例如系統壞了應該怎么處理。 但實際上我們沒有必要這么寫，因為用例分析的目的是為了詳細分析為了實現客戶價值，系統應該怎么做，如果系統本身都壞了，這個就不是用例關注的內容了。 需要注意的是：用例分析中的“異常”是指流程的異常情況，而不包含系統本身的的異常。 **【第三步：替代處理】** 在第二步的基礎上，我們增加替代處理。即：有的步驟可以換一種方式來實現。例如如下用例中的付款方式，可以有信用卡支付、會員卡支付、購物卡支付等。 【用例名稱】 買單 【場景】 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.?買單完成，顧客攜帶商品和小票離開； 【用例價值】 顧客買完單以后，就可以攜帶商品離開，而超市也將得到收入； 【約束和限制】 1.?POS機必須符合國標XXX； 2.?鍵盤使用中文，因為收銀員都是中國人； 3.?一次買單數額不能超過99999RMB； 4.?POS機要非常穩定，至少一天內不要出現故障； 經過上面步步為營，逐步細化和求精，我們已經得到了一個比較完善的需求了，這個過程中并沒有高深的技巧，也沒有涉及需要豐富的經驗。 有的讀者可能會有疑問：我怎么知道第4步有那些異常、那些替代方案呢？ 其實很簡單：問你的客戶！客戶是最清楚了，但如果你不問，嘿嘿，客戶倒不一定會告訴你：） 但只要我們掌握了NEA用例分析方法，即使客戶忘記了，或者沒有意識到，我們也會將需求挖出來，這樣需求就不會遺漏。 ### 【要畫圖么？】 大家可以看到，我們在前面進行用例分析的時候，并沒有看到任何圖，而是純文本！ ? 對于那些UML狂熱分子來說，這可能是難以接受的，怎么能沒有圖呢？UML中的用例圖不就是用來分析需求的么？ ? 我們當然不懷疑UML的權威性，但任何東西都有局限性，UML也不例外。UML的局限就在于UML是一個建模的語言，就像漢語、英語一樣，只是一種表達形式，而不是一種分析和創作方式。 ? 比如說你會漢語，但并不代表你就能寫小說，你會畫UML用例圖，但并不代表你就能做需求分析。相反，必須是有了需求和用例之后，才有用例圖，說白了，用例圖是用例的圖形化描述，但是它并不能取代用例。 ? 除了UML本身的局限性外，還有另外一個更重要的原因：用例是客戶和公司關于產品的一個共同認識！一般情況下，市場人員和客戶溝通交流，了解客戶的需求，然后和客戶一一確認，最后形成需求文檔。在這個過程中，主要是客戶和市場人員參與，而沒有研發的人員參與。 ? 對于客戶來說，他肯定是以自然語言，而不會用UML來描述需求；對于市場人員來說也一樣，他可能對UML一竅不通，甚至他以前可能都是賣醫療器械，甚至有可能是狗皮膏藥的，他還管你什么軟件工程，什么UML？ ? 所以，采用用例方法分析需求的時候，我們都是采用純文本來描述需求的，而不會采用用例圖來分析需求