01 行业应用现状
功能点分析（Function Point Analysis, FPA）自20世纪70年代末由Allan J. Albrecht提出以来，已发展成为国际上主流的软件规模度量方法。如今，IFPUG 方法纳入 ISO/IEC 20926 国际标准，国内在2023 年也发布了多项软件功能规模测量系列国家标准：GB/T 42449-2023《系统与软件工程 功能规模测量 IFPUG方法》、GB/T 42452-2023《系统与软件工程 功能规模测量 COSMIC方法》、GB/T 42448-2023《系统与软件工程 功能规模测量 FiSMA1.1方法》、GB/T 42566-2023《系统与软件工程 功能规模测量 MkⅡ功能点分析方法》以及GB/T 42588-2023《系统与软件工程 功能规模测量 NESMA方法》。
相关标准解读：
《系统与软件工程功能规模测量IFPUG方法》（GB/T42449-2023）标准解读
《系统与软件工程 功能规模测量 NESMA方法》（GBT 42588-2023）标准解读
然而在实际应用中，功能点计数“漏数、多数、错数”的问题频发。其中一个不可忽视的原因是习惯于从“系统设计的技术开发视角”出发考虑功能点，而忽略了功能点方法最根本的起点——用户视角。以下是几类典型的错误：
错误一：把“技术实现”当成“用户功能”
业务场景：某系统的文件管理模块中，用户可通过“上传文件”功能上传各类文档。后台根据文件类型（图片、文档、视频）分别设计了独立的上传接口和存储路径，每种类型对应不同的处理逻辑
技术视角错误计数：从技术实现出发，认为系统有3种文件类型，每种类型都有独立的上传接口、存储路径和处理逻辑，因此识别为3个EI。
基于用户视角合规判定：从用户视角来看，“上传文件”是一个完整的业务操作，用户并不感知后台按图片、文档还是视频做了接口拆分。用户的操作只有选择文件、点击上传，不同文件类型在用户视角下属于同一基本过程，而非3个独立的基本过程。
错误二：把“页面跳转”当成“业务功能”
业务场景：某系统的客服模块中，为了提升用户体验，将办理的各项入口集成到客服界面中。用户在咨询相关服务时，可以通过客服界面直接点击“办理入口”按钮跳转到对应的服务办理页面，无需在平台上反复查找。
技术视角错误计数：看到系统中新增了一个“接入办理入口”功能，认为这是一个用户可操作的功能点，且需要开发接口、配置跳转链接，于是将其计为1个EI。
基于用户视角合规判定：用户点击“接入办理入口”后，系统执行的操作是页面跳转/导航——将用户从客服界面切换到服务办理页面。用户在此过程中：没有向系统输入业务数据、没有触发数据状态变更、没有收到系统输出的业务信息。此类导航/跳转类功能不应作为独立的功能点计入。
错误三：把“物理表”直接等同于“逻辑文件”
业务场景：某系统的用户管理模块中，数据库设计包含多张与用户相关的表：用户基本信息表、用户权限表、用户偏好设置表、用户登录日志表。计数人员在识别ILF时，逐一核对了这些物理表。
技术视角错误计数：打开数据库设计文档，看到4张与用户相关的物理表，认为每张表都存储了系统需要维护的数据，于是识别为4个ILF。
基于用户视角合规判定：用户知道“我的个人信息”（包含姓名、联系方式、权限等），但用户不需要知道这些数据在数据库中分几张表存储——那是物理设计层面的考量，用户不关心，也不应影响功能点计数。
错误四：混淆EO与EQ
业务场景：某系统的统计分析模块中，提供一份“月度销售统计报表”，该报表需要从订单表中汇总当月销售总额、订单数量、各类商品销售占比、环比增长率等数据，并以图表和表格形式展示给用户。
技术视角错误计数：看到这是一个“查询并展示”的功能，页面有一个“查看报表”按钮，认为系统只是从数据库中读取数据并展示，因此计为1个EQ。
基于用户视角合规判定：用户需要的是“一份经过汇总计算的月度销售统计报表”，而不是“查看订单列表”。系统在生成此报表时，需要执行加工处理，凡是包含加工处理或计算逻辑的数据输出，应计为EO。
02 不同规模度量方法的视角差异
各类度量方法从不同视角出发，均有自身适配场景，而功能点方法是以“用户视角”为核心判定逻辑，拥有统一、可对外评审、跨项目可比的标准化计数体系。
功能点方法的创立其初衷之一是让项目组和客户可以使用同一方法定义功能需求，实践证明，理解客户需求最好的办法是站在客户的角度分析软件系统产生的结果。
落地用户视角开展功能点测算时可借助AI 智能造价工具——软件造价喵，支持用户上传可研方案或设计文档，系统智能识别项目功能点，生成报告，一站式完成软件规模自动测算。
03 用户视角的核心原则
原则一：逻辑视图，而非物理视图
计数应优先参考业务需求、产品原型所呈现的逻辑业务结构，而非数据库物理表结构、API接口拆分或分布式部署等技术实现方案。
原则二：边界由用户定义，而非由技术划分
界定计数边界时，以用户完整业务领域（用户管理、客服管理、养老服务等）划分范围，不以前端、后端、微服务模块切割边界；若外部系统与本系统存在用户可感知的数据交互，需单独识别EIF，不能单纯按技术服务隔离边界。
原则三：“用户可识别”作为功能的过滤条件
无论数据功能还是事务功能，第一步判断：普通业务使用者能否理解、访问、维护该组数据或操作；后台缓存、日志、临时中转数据用户无访问权限，一般不计ILF/EIF；若日志支持用户查询导出，可单独统计。
了解更多数据功能识别要点功能点识别控制要点—数据功能
原则四：事务功能判定标尺是用户完整交互行为
区分EI/EQ/EO仅围绕三类用户行为判断：用户向系统新增/变更数据为EI；用户主动读取原始数据浏览为EQ；系统自动运算、主动输出业务成果为EO；同一页面内多类操作若具备独立业务闭环，可分别计数，不强制合并。
了解更多事务功能识别要点功能点识别控制要点—事务功能
04 识别过程中分步贯彻用户视角原则
在完整的功能点识别工作中，整体流程分为边界划定、数据功能识别、事务功能识别、复核校验四大阶段，每个阶段针对性落地对应用户视角判定原则，各阶段环环相扣。
按用户业务域划定系统边界
功能点识别应以功能用户需求为识别依据，而非直接从数据库设计文档、系统架构图、接口清单等技术产物出发。需求规格说明书、产品原型、用户故事、业务流程图才是有效输入。技术文档用于理解实现方式，而非计数。判断标准：这个功能是用户提出来的，还是开发人员为方便实现而增加的？
用“用户可识别”过滤数据功能
识别数据功能时，可以逐一用三问验证：用户能识别这组数据吗？逻辑上是一个整体吗？数据由本系统维护还是外部引用？不符合任一条件，则不应该作为ILF/EIF计入。
以用户操作行为判定事务功能
识别事务功能时，可以遍历用户操作路径图，每个操作节点用三问判断归属：用户往系统里“放”了什么？（输入数据/指令），用户从系统里“拿”到了什么？（系统输出加工计算后的信息）用户从系统里“看”到了什么？（系统检索展示已有数据）
用“业务语言测试”验证结果
对每个功能点逐条核对：排查按表、接口过度拆分问题；清理边界内技术模块；剔除日志、缓存误计项；修正EI/EQ/EO 错判，不合规项重新调整。用业务语言描述功能点，能否说清“用户做什么”。
05 结语
功能点方法发展至今已超过四十年，IFPUG 计数实践手册持续迭代更新，ISO/IEC 2092 国际标准历经版本演进，国家标准也已正式落地实施。各版本仅细化细分场景计数细则，核心底层逻辑保持统一——功能点方法是从用户视角出发，对软件规模从功能需求的角度进行度量的标准方法。用户视角是功能点方法的根本立足点，也是其区别于其他度量方法的核心特征。
