連載：面向物件葵花寶典：思想、技巧與實踐（19）
完成了用例之後，需求分析的工作基本上已經完成，接下來我們需要趁熱打鐵，完成另外一個事情：提取功能點！
有了用例之後，提取功能可以說是一個水到渠成的事情，基本上只是一個文字工作，我們只需要將用例中那些需要系統完成的事情——更簡單的說：是動詞——提取出來，就成為了系統的功能。
以前面的POS機為例，我們看看如何提取功能，如下粗體字即為提取的功能：
【用例名稱】 買單 【場景】 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機要非常穩定，至少一天內不要出現故障； |
我們將提取的功能列出來：
功能編號 | 功能描述 | 備註 |
001 | 掃描商品條形碼 | NA |
002 | 手工輸入條形碼 | 在用例的幾個步驟中有體現 |
003 | 刪除某商品 | 在用例的幾個步驟中有體現 |
004 | 刪除某類商品中的一個或幾個 | NA |
005 | 顧客使用信用卡支付 | 這三個功能點比較大，如有需要，可以繼續拆分。 |
006 | 顧客使用購物卡支付 | |
007 | 顧客使用會員卡積分支付 | |
008 | 計算找零的數目 | 用例中是“給出”，對應系統功能是我們改為“計算”，因為這更加符合計算機的描述術語。 |
009 | 列印小票 | NA |
注意用例中可能同一個功能在不同的步驟中出現了多次（例如“手工輸入條形碼”、“刪除某商品”），最後提取的時候要合併。
除了同一用例中某些功能要合併外，不同的用例中相同的功能也需要合併，我們以ATM機為例：
功能編號 | 功能描述 | 涉及用例 |
001 | 銀行卡驗證 | 取款、存款、查詢餘額 |
002 | 密碼驗證 | 取款、存款、查詢餘額 |
003 | 點鈔 | 取款、存款 |
004 | 驗鈔 | 存款 |
005 | 列印交易清單 | 取款、存款 |
有的同學可能會問：有了用例後，為什麼還要將功能點單獨提取出來呢？直接看用例不就可以了麼？
這個問題要從多方面來回答：
首先，從美學的角度來看，看一個功能列表的表格，肯定比看一長篇用例文件，然後在腦袋裡組織功能列表要方便很多；
其次，從專案管理的角度來看，功能列表更易於管理，例如任務分配時不可能基於用例進行分配的，因為不同用例間可能存在大量重複的功能點；
再次，從開發角度來說，開發是基於功能點的，而不是基於用例的；
最後，從測試的角度來說，雖然最後的驗收測試是基於用例的，但產品測試主要還是基於功能點進行測試的
================================================
轉載請註明出處：http://blog.csdn.net/yunhua_lee/article/details/21550893
================================================