## 连载：面向对象葵花宝典：思想、技巧与实践（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| 打印交易清单| 取款、存款| 有的同学可能会问：有了用例后，为什么还要将功能点单独提取出来呢？直接看用例不就可以了么？ 这个问题要从多方面来回答： 首先，从美学的角度来看，看一个功能列表的表格，肯定比看一长篇用例文档，然后在脑袋里组织功能列表要方便很多；   其次，从项目管理的角度来看，功能列表更易于管理，例如任务分配时不可能基于用例进行分配的，因为不同用例间可能存在大量重复的功能点；   再次，从开发角度来说，开发是基于功能点的，而不是基于用例的； 最后，从测试的角度来说，虽然最后的验收测试是基于用例的，但产品测试主要还是基于功能点进行测试的