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