连载：面向对象葵花宝典：思想、技巧与实践（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机为例：

有的同学可能会问：有了用例后，为什么还要将功能点单独提取出来呢？直接看用例不就可以了么？

这个问题要从多方面来回答：

首先，从美学的角度来看，看一个功能列表的表格，肯定比看一长篇用例文档，然后在脑袋里组织功能列表要方便很多；

其次，从项目管理的角度来看，功能列表更易于管理，例如任务分配时不可能基于用例进行分配的，因为不同用例间可能存在大量重复的功能点；

再次，从开发角度来说，开发是基于功能点的，而不是基于用例的；

最后，从测试的角度来说，虽然最后的验收测试是基于用例的，但产品测试主要还是基于功能点进行测试的