功能点分析方法在软件需求管理中的应用
2008-04-16 作者：曹济 刘黎明 王宁（caoji） 来源：项目管理者联盟
软件项目面临的一个普遍困难就是需求的不确定与频繁变更，有效管理软件需求要解决的一个基本问题是确定变更的粒度大小以及对项目的影响程度。本文使用功能点标准度量需求的规模，使得采用量化方式管理软件需求成为可能，从而对功能点在软件项目管理方面的应用进行扩充。
关键词： 需求管理 需求变更 功能点 项目管理 软件度量
1. 背景
相对于传统行业的项目而言，在软件项目中经常会发生工期拖延、费用超支、质量低下、用户不满意等负面情形[1]，其原因可能包括客户要求不合理、过程管理不规范、质量意识淡漠等多种因素，但不能否认的是软件本身的特点是问题产生的根源。
相对于其他行业而言，例如土建、制造等传统行业，软件更为抽象和不易衡量，同时软件还具有容易变更的特点。再加上软件不容易量化的特点使得软件项目的计划与跟踪粒度过粗、不能及时发现项目中存在的问题，从而导致软件项目的管理往往流于形式化，不能起到应有的作用。
软件项目管理主要从四个方面关注项目的进展状况[2]，它们依次是项目的范围、时间、成本和质量，如图一所示。其中项目范围作为主要的变量，对其他三个指标产生明显的影响。而软件项目范围的不确定性则会直接导致项目工期、项目成本和项目质量的不确定性。
图一：项目管理三角形软件项目范围的不确定性通常表现为如下两个方面：
1. 项目前期需求不明确。前期需求不明确导致项目范围不确定，而基于范围基础之上的工期、成本与质量目标显然也带有很大的不确定性。正是因为需求不明确，许多项目倾向于采用固定价合同计价模式。当后期发生追加需求时，甲方可以避免追加合同金额的情形（甲方申请由追加需求产生的额外费用是比较困难的，因为他往往缺乏有效的方法说服自己的上司追加费用与额外需求之间明确的对应关系）。可想而知，固定价合同模式对项目的乙方会产生什么样的影响。乙方只好做些力所能及的被动适应性工作，例如无可奈何的加班、质量方面的下降、工期方面的顺延等等。
2. 需求变更时无法做出可信的量化影响分析。 因为需求规模的单位比较模糊，例如一个需求、需求模块等笼统提法，导致变更的需求规模描述不容易被接受。尤其是对于客户而言，基于变更的需求所推导出的对应的工期变更、成本变更和质量变更也缺乏说服力。所以当需求变更后，项目计划的修改往往是不够准确的。
在软件项目的需求管理中引入功能点分析方法可以有针对性地解决上述的问题[3]。在软件项目中引入功能点分析方法有助于：
约束需求的详细程度
对需求变更的影响程度综合分析
区分需求变更及其对应的种类
2. 功能点方法概述
一个软件的大小可以通过交付给用户的功能点数来度量，就如一间房子的大小通过提供给用户的建筑面积或使用面积来度量一样。根据ISO的标准表述，功能点分析方法的目的是量化表述用户功能性需求的软件规模（A size of the software derived by quantifying the Functional User Requirement）
目前被纳入ISO标准的功能点分析方法总共有四种，分别是
IFPUG 功能点标准
Mark II 功能点标准
Nesma 功能点标准
COSMIC FFP 功能点标准
IFPUG（International Function Point User Group）功能点标准是目前软件行业采用最广泛的功能点分析方法 。功能点分析方法是从用户的角度将所有的用户业务功能需求区分为驻留数据的功能需求和处理数据的事务功能需求[3]，如图二所示。
其中，数据功能需求区分为应用内部逻辑数据和应用外部的接口数据；事务功能区分为对数据的外部输入、输出和查询。数据功能的 复杂性由数据元素类型（DET ）和记录元素类型（RET ）决定 ；而事务功能的复杂性由数据元素类型（DET ）和文件引用类型（FTR ）决定 。将功能转换为对应的复杂程度，再根据复杂程度转换为对应的功能点数值[3]，这样就将用户的业务功能需求表述为一个用数值表示的软件需求规模。完整的功能点计数过程如图三所示[3]。
因为功能点分析方法是一个确定软件需求规模的标准方法，所以它可以界定需求的有效粒度。从而有助于约束需求的详细程度，并采用统一的尺度衡量软件需求规模。
3. 采用功能点方法管理软件需求变更
3.1. 基于功能点分析方法的需求变更分类
何谓软件需求变更？从功能点分析的角度就是需求发生了变化，而这种变化的判定依据可以参考功能点的识别规则。需求的变更相对于原有的需求而言无非就是三种类型：新增需求、修改需求和删除需求。新增需求和删除需求相对容易判断，而修改需求的判断就不是那么直接了。在实际的软件项目中，需求的变更通常存在下列的情形：
第一种是需求不明确的前提所提出的变更，即在需求定义时用户没有能力或时间定义需求，或定义的需求不够详细，因而在需求确认后提出变更，通常包括新增需求和变更需求；
第二种是在需求明确的前提下所提出的变更，通常是因为当前的业务与最初提出的需求已经发生了变化或者原有的功能已经不适用，通常包括新增需求、删除的需求和变更的需求。
我们将第一种需求称为遗漏性需求变更，而将第二种需求变更称为追加性需求变更。下面分析的结果对于遗漏性和追加性的需求变更都适用。
3.1.1. 数据功能的需求变更分类
对于新增和删除的数据功能容易识别，例如在原有需求的基础之增加或删除发票信息或价格规则信息，则易判断发票信息或价格规则信息为增加或删除的数据功能。对于修改的数据功能则比较困难。
判断修改的数据功能时应注意：如果修改仅包含逻辑文件中新纪录的增加或者已存在字段中新值的增加，那么不能认为数据功能被修改；如果数据功能中添加了新字段，而这个新字段却并没有被应用所使用，那么该数据功能也不能认为是被修改的数据功能。一个数据功能被算作被修改的功能，通常其结构要发生改变（如：增加或删除一个字段或者修改了字段特征）[3]。
所以对于数据功能的需求变更可以区分为增加、修改和删除。
3.1.2. 事务功能的需求变更分类
类似于数据功能的判断，对于新增和删除的事务功能也容易识别。例如在原有需求的基础之增加或删除价格规则维护功能，则易判断价格规则维护功能为增加或删除的事务功能。通常，当判断有新增或删除的数据功能时，事务功能也会有新增或删除。而当新增或删除事务功能时，数据功能却不一定发生变化。例如，增加或删除了价格规则这样的数据功能时，则对应的应该有新增或删除的事务功能。否则，如何维护对应的数据功能？反之，则不必然。
对于修改的事务功能判断相对困难。判断EI/EO/EQ类型的事务功能是否被修改，则可参考事务功能的唯一性判定原则。如果以下三个条件任一条件满足，则说明事务功能发生了变化，需求应被当作变更的需求处理。判断事务功能是否变更的三个条件如下：
事务功能的DET是否发生变化，例如增加、删除或修改DET
事务功能关联的FTR是否发生变化，例如FTR增加、减少或修改
事务功能对应的处理逻辑是否发生变化，例如处理逻辑增加、减少或修改
什么是处理逻辑？功能点分析方法通过枚举方式列出十三种逻辑[3]，如表一所示。需要注意的是，区分事务功能的唯一性时，可以不考虑处理逻辑13，即重新分类或重新排列数据逻辑；而当判断一个事务功能是否被修改时，则所有的处理逻辑都在考虑的范围，哪怕事务功能仅仅只是对处理逻辑13 做了修改，也应视作修改的事务功能。
表一：事务功能的13种处理逻辑
表一中各字母表示的含义如下：
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]。
对于后续阶段提出的需求变更与项目前期提出的需求变更所引发的工作量的评估看起来会有比较大的不同，感觉上好像后续的变更引发的工作量更大。这是因为后续阶段提出的新需求可能会涉及到对技术架构体系的修改，这样就会涉及到很多工作量。但如果不涉及到技术架构的话，需求在前期与后期提出对于引发的工期、成本和质量应该区别不大。
需求变更影响分析在合同管理方面有着重要的意义，软件项目合同的项目约束条件（工期、费用和质量要求）与项目的范围有直接的对应关系。当软件需求如果比原有需求增加、修改和删除时，项目的约束条件应该也随之发生变化。因为在很多软件项目中存在需求前期不明确、不完整的情形，所以软件需求变更管理应该充分考虑这一因素，因而本文将其区分为遗漏性需求与追加性需求。上述的公式（1）主要适用于项目组内部对于需求规模的评价，而客户方与开发方组织对于需求规模的评定应充分考虑遗漏性需求发生的可能性，因为遗漏性需求不应该排除在项目的合同范围之外，也即意味着客户无需为遗漏性需求支付额外的费用或降低其他约束标准。
4. 采用功能点方法约束软件需求
不同于软件项目的追加性需求，软件项目的遗漏性需求是应该并且也可能避免的。在需求的获取阶段可以标准功能点作为需求的约束标准，避免产生遗漏性需求。具体来说，对于每一项客户提出的业务功能都应该以图二所描述的模型作为约束标准。每一项功能都必须有对应的数据功能，而每一个数据功能也必须有对应的事务功能。而对于每一项数据功能自然可以联想到维护数据功能的三种事务功能，输入功能（通常包括新增、删除和修改三种功能）、输出功能和查询功能。而每一项事务功能通常至少与一个内部逻辑文件或外部接口文件关联。
而对于具体每项需求（包括数据功能与事务功能）描述的详细程度也可以参考功能点约束标准。对于每项数据功能，识别它们所包含的DET和RET；对于每项事务功能，识别它们的对应的DET、FTR以及所采用的处理逻辑（处理逻辑即上文所描述的十三种处理逻辑）。如果客户不能确定对应的DET、RET、FTR或处理逻辑，那么也应该将这些不能确定的内容作为需求风险识别出来，在后续的阶段应加以确认和跟踪，及早确认这些不确定项。
5. 结论
本文通过分析软件需求变更的特点，将软件功能点分析方法引入软件需求变更管理过程中。对于软件需求变更首先将其区分为遗漏性需求或追加性需求，然后再区分需求是新增、修改还是删除，尤其是分析了判断修改需求的界定标准，给出了判定修改需求的三个条件。在此基础上，讨论需求变更的影响分析，并给出了需求变更后的项目功能点公式。最后建议采用功能点标准作为客户需求的约束标准，提高软件需求的完整性和详细程度。功能点分析方法作为确定软件规模的基础方法，可以有效提升软件量化管理水平，还可以广泛应用于软件项目管理、质量管理等相关领域。
文章来源于领测软件测试网 https://www.ltesting.net/
