完成了用例之后，需求分析的工作基本上已经完成，接下来我们需要趁热打铁，完成另外一个事情：提取功能点！
有了用例之后，提取功能可以说是一个水到渠成的事情，基本上只是一个文字工作，我们只需要将用例中那些需要系统完成的事情——更简单的说：是动词——提取出来，就成为了系统的功能。
以前面的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
================================================