功能点识别控制要点—通用要求-成都东契奇科技有限公司

通用要求作为功能点识别的基础性规范，贯穿于整个度量过程的始终，为数据功能和事务功能的识别提供了总体框架和约束条件。通用要求的控制点分别从有序性、可追溯性、增量性和业务性四个角度，对功能点识别过程提出了基本约束。这些约束看似简单，但在实际操作中往往被忽视，导致后续数据功能和事务功能的识别出现系统性偏差。本文将逐一分析，并通过详细示例说明其在实际场景中的应用。

01 按顺序依次度量，防范重复度量

功能点识别过程中依据相关材料按顺序依次度量，防范重复度量和非功能度量，容易引起重复度量疑问的功能必须备注度量原因。

按顺序度量是功能点识别的基本方法论要求，其核心目的在于建立一套有序、可追溯的度量流程，避免因随意跳读需求文档而导致的遗漏或重复计数问题。

以某人事管理系统为例，假设需求文档中包含以下功能模块：

3.1员工基本信息录入
3.2员工信息修改
3.3员工信息查询
3.4员工离职处理

正确做法：

严格按照文档章节顺序依次识别：

3.1 → 识别为 EI（外部输入）：员工信息录入
3.2 → 识别为 EI（外部输入）：员工信息修改
3.3 → 识别为 EQ（外部查询）：员工信息查询
3.4 → 识别为 EI（外部输入）：员工离职处理（涉及状态变更）

在这个过程中，员工信息修改与员工离职处理可能存在功能重叠的疑问——离职处理同样涉及修改员工状态。此时必须在备注中说明：员工离职处理涉及离职审批流程和状态变更，与基本信息修改属于不同业务场景，故单独计数。

错误做法：

不按顺序随意跳读需求文档。例如先识别了3.2的修改功能，后续在其他章节看到员工状态变更又重新计数一次，导致同一功能被重复度量。

在实际操作中，建议建立需求条目与功能点的双向追溯矩阵，确保每条需求有且仅有一个功能点与之对应。对于大型项目，可采用分模块、分章节的流水线式度量方式，每完成一个模块即进行交叉校验，从制度层面防范重复度量的发生。

02 备注说明与映射关系

功能点识别应有必要的备注说明，涉及多个送审基准评估材料的，应建立每项识别的数据功能和事务功能与送审评估材料中相应的功能描述之间的映射关系。

备注说明和映射关系是功能点识别可追溯性的核心保障，尤其在涉及多份送审材料的复杂项目中，映射关系的建立直接决定了度量结果的可验证性和可评审性。

以某政务系统项目为例，该项目提供了三份送审材料：材料A《业务需求说明书》、材料B《系统设计规格书》、材料C《接口需求文档》。在识别公民信息登记功能时：

材料A 第4.2节描述了业务流程："公民提交身份信息，工作人员审核后录入系统"
材料B 第6.1节描述了数据结构："公民信息表包含姓名、身份证号、地址等32个字段"
材料C 第3节描述了接口："与公安部身份核验系统对接，验证身份证号有效性"

此时应建立如下映射关系：

当送审材料之间存在描述不一致时——例如材料A说公民信息包含20个字段，材料B说32个字段——应在备注中明确说明以哪份材料为准，以及差异处理的原因。这种映射关系不仅是质量控制手段，更是后续评审答辩的重要依据，能够有效支撑度量结果的可信度。

03 升级改造项目既有功能不计数

升级改造项目中既有的、没有任何改变的逻辑文件（ILF/EIF）以及事务功能（EQ/EI/EO）等不应纳入功能点计数范围。

升级改造项目的功能点度量应严格区分新增、变更和既有不变三类功能，仅对新增和变更部分进行计数，这是增量性原则的核心体现。

以某银行核心系统升级改造项目为例，原系统包含以下功能：

账户信息表（ILF）—— 既有，本次无变更
存款交易（EI）—— 既有，本次无变更
贷款审批流程（EI）—— 既有，本次新增了反欺诈校验规则
客户风险评级（EO）—— 既有，本次无变更
新增：智能推荐模型（ILF + EO）—— 全新功能

正确计数：

错误做法：

将贷款审批流程整体作为新功能计数，而实际仅新增了反欺诈校验部分。正确做法是仅对变更部分进行增量计数。

对于没有任何改变的判定标准，应以逻辑处理和数据结构是否变更为依据，而非界面样式或技术实现的变化。例如将账户信息表从Oracle迁移到MySQL但字段结构和业务逻辑完全不变，则仍属于无变更；反之如果在迁移过程中新增了账户风险等级字段，则该ILF应纳入计数。建议在实际操作中用不同颜色标记新增、修改、既有不变的功能，确保计数范围准确无误。

04 菜单结构的计数规则

应用程序中菜单结构通常不纳入功能点计数范围，但是对于用户自己可维护菜单结构及信息，可根据功能点识别规则进行计数。

菜单是否纳入计数的核心判断标准在于菜单是否承载了独立的业务数据功能——如果菜单仅是静态导航结构则不计数，如果菜单本身作为业务数据被管理则需正常计数。

示例1：

某OA系统，其主界面包含固定菜单：首页、公文管理、会议管理、通讯录、系统设置。这些菜单仅是功能的导航入口，本身不处理数据，也不构成独立的业务功能，因此不应识别为功能点。菜单下的具体功能如公文起草、会议安排才需要计数。即使菜单支持权限控制——不同角色看到不同菜单——也不应单独计数，权限控制功能应在系统管理模块中单独识别。

示例2：

某企业门户系统允许管理员自定义菜单结构，管理员可以新增、修改、删除菜单项，可以设置菜单的层级关系和显示顺序，菜单项可以关联不同的功能模块。此时菜单配置功能应识别为：ILF（菜单配置信息表，包含菜单名称、URL、排序号、父菜单ID等）、EI（菜单信息维护，新增修改删除菜单项）、EQ（菜单列表查询）。

判断菜单是否计数的核心标准是用户是否对其有数据维护行为。如果菜单本身作为业务数据被管理，如CMS系统的内容导航管理，则应按数据功能和事务功能的规则正常计数。

05 总结

通用要求的控制点构成了功能点识别的元规则体系，分别对应有序性、可追溯性、增量性和业务性四大核心原则。通过要求按顺序度量，防范了漏计和重计的基本问题；通过要求备注说明和映射关系，确保了识别依据的可追溯性；通过要求排除既有不变功能，防止了升级改造项目中的规模虚增；控制点4通过明确菜单结构的计数边界，避免了将非业务元素误计为功能点。

在实践中，建议从以下方面落实通用要求：第一，在项目启动阶段就建立功能点识别的规范文档，明确流程、模板和检查清单；第二，实行双人交叉评审制度，一人度量、一人复核，重点检查重复度量和遗漏；第三，保留完整的度量记录，包括每条功能点的识别依据、映射来源和备注说明；第四，升级改造项目严格区分增量，用可视化手段标记新增、修改和既有不变的功能。

功能点的测算可使用“软件造价喵”：平台集成国内各省市60余个计费标准，支持一键测算，自动生成符合测算要求的造价评估结果，大幅缩短预算编制周期，确保功能点识别的准确性。

通用要求是整个功能点度量质量保障体系的基石。只有在通用要求层面打好基础，建立规范化的度量流程和可追溯的识别记录，才能确保后续数据功能和事务功能的识别准确可靠，最终交付可信的度量结果。