連載：面向物件葵花寶典：思想、技巧與實踐（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？
所以，採用用例方法分析需求的時候，我們都是採用純文字來描述需求的，而不會採用用例圖來分析需求
================================================
轉載請註明出處：http://blog.csdn.net/yunhua_lee/article/details/21372929
================================================