功能点分析方法在软件需求管理中的应用

关键词： 需求管理 需求变更 功能点  项目管理 软件度量

1.  背景  

相对于传统行业的项目而言，在软件项目中经常会发生工期拖延、费用超支、质量低下、用户不满意等负面情形[1]，其原因可能包括客户要求不合理、过程管理不规范、质量意识淡漠等多种因素，但不能否认的是软件本身的特点是问题产生的根源。

相对于其他行业而言，例如土建、制造等传统行业，软件更为抽象和不易衡量，同时软件还具有容易变更的特点。再加上软件不容易量化的特点使得软件项目的计划与跟踪粒度过粗、不能及时发现项目中存在的问题，从而导致软件项目的管理往往流于形式化，不能起到应有的作用。

软件项目管理主要从四个方面关注项目的进展状况[2]，它们依次是项目的范围、时间、成本和质量，如图一所示。其中项目范围作为主要的变量，对其他三个指标产生明显的影响。而软件项目范围的不确定性则会直接导致项目工期、项目成本和项目质量的不确定性。
 

其中，数据功能需求区分为应用内部逻辑数据和应用外部的接口数据；事务功能区分为对数据的外部输入、输出和查询。数据功能的 复杂性由数据元素类型（DET ）和记录元素类型（RET ）决定 ；而事务功能的复杂性由数据元素类型（DET ）和文件引用类型（FTR ）决定 。将功能转换为对应的复杂程度，再根据复杂程度转换为对应的功能点数值[3]，这样就将用户的业务功能需求表述为一个用数值表示的软件需求规模。完整的功能点计数过程如图三所示[3]。 

表一中各字母表示的含义如下：
M：事务功能必须执行的处理逻辑
M*：事务功能必须执行其中的至少一个
C：事务功能可以执行，但并不是必须执行的处理逻辑
N：事务功能不能执行的处理逻辑
至此，可以将软件需求变更归类为遗漏性需求变更和追加性需求变更。而对每一性质的变更又可区分为新增、删除和变更三种类型。下一节进一步描述不同需求变更类型的功能点算法。

3.2. 需求变更的影响分析

正如图一中项目管理三角形描述的那样，采用功能点衡量需求变更的程度，是为了更好地评价需求对项目的工期、成本以及质量的影响。首先涉及到的问题就是如何对需求变更后的项目规模重新评价，在上一节描述了对单次需求变更（包括增加、修改和删除）的识别，在此基础上可以根据下面的公式计算变更后的项目功能点规模。

CAFP=(CBFP+DEL)*VAFB+(ADD+CHGA+CFP)*VAFA                          （1）

其中

CAFP：变更后项目功能点总数（表示每次需求变更后对项目功能点的计数）
CBFP：变更前项目功能点总数 （最初的项目功能点数通常在需求规格说明书批准后得到，又称为项目的初始基线功能点）
DEL：删除需求的功能点总数
VAFB：修改前调整系数
ADD：增加需求的功能点总数
CHGA：修改后需求的功能点总数
CFP：数据转换的功能点数（如果系统中涉及到遗留系统数据迁移时会有此类型功能点）     
VAFA：修改后调整系数    

需要说明的是，在软件需求变更的过程中，VAFB和VAFA通常是一致的，因为单次需求变更往往对于系统的非功能性需求没有明显的影响。

因为每次需求变更后可以重新确定项目的功能点，所以可以在此基础上重新确定项目的工期、成本和质量[2]，[4-8]。

对于后续阶段提出的需求变更与项目前期提出的需求变更所引发的工作量的评估看起来会有比较大的不同，感觉上好像后续的变更引发的工作量更大。这是因为后续阶段提出的新需求可能会涉及到对技术架构体系的修改，这样就会涉及到很多工作量。但如果不涉及到技术架构的话，需求在前期与后期提出对于引发的工期、成本和质量应该区别不大。

4. 采用功能点方法约束软件需求

不同于软件项目的追加性需求，软件项目的遗漏性需求是应该并且也可能避免的。在需求的获取阶段可以标准功能点作为需求的约束标准，避免产生遗漏性需求。具体来说，对于每一项客户提出的业务功能都应该以图二所描述的模型作为约束标准。每一项功能都必须有对应的数据功能，而每一个数据功能也必须有对应的事务功能。而对于每一项数据功能自然可以联想到维护数据功能的三种事务功能，输入功能（通常包括新增、删除和修改三种功能）、输出功能和查询功能。而每一项事务功能通常至少与一个内部逻辑文件或外部接口文件关联。

而对于具体每项需求（包括数据功能与事务功能）描述的详细程度也可以参考功能点约束标准。对于每项数据功能，识别它们所包含的DET和RET；对于每项事务功能，识别它们的对应的DET、FTR以及所采用的处理逻辑（处理逻辑即上文所描述的十三种处理逻辑）。如果客户不能确定对应的DET、RET、FTR或处理逻辑，那么也应该将这些不能确定的内容作为需求风险识别出来，在后续的阶段应加以确认和跟踪，及早确认这些不确定项。

相关资源：c#编写的鸡兔同笼程序