例如处理逻辑增加、减少或修改
什么是处理逻辑？功能点分析方法通过枚举方式列出十三种逻辑[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. 采用功能点方法约束软件需求
不同于软件项目的追加性需求，软件项目的遗漏性需求是应该并且也可能避免的。在需求的获取阶段可以标准功能点作为需求的约束标准，避免产生遗漏性需求。具体来说，对于每一项客户提出的业务功能都应该以图二所描述的模型作为约束标准。每一项功能都必须有对应的数据功
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
