事务功能（EI/EO/EQ）是功能点度量中直接反映用户操作行为的部分，与数据功能（ILF/EIF）共同构成完整的功能点计数体系。外部输入（EI）代表对数据的写入操作，外部输出（EO）代表经过处理的数据输出，外部查询（EQ）代表直接的数据检索。事务功能的识别难点在于：同一业务操作可能通过多种方式触发、同一逻辑可能表现为多种界面形式、后台服务与前台操作的边界模糊，这些问题都是导致度量偏差的常见原因。
针对事务功能识别中的典型问题，从原子性、唯一性和业务视角三个角度提出了明确的约束规则。这些规则的核心思想是：站在业务用户的视角，识别不可再分的基本过程，避免因触发方式、处理分支、使用位置或命名差异而导致的重复计数。
01 基本过程的原子性与唯一性
每个事务功能必须满足基本过程的定义要求，即基本过程是指一组用户可识别的、业务上不能再进一步拆分的原子操作。确认每个事务功能（基本过程）必须是唯一的，不应重复度量。
以某采购系统中的采购申请提交功能为例，
正确做法：
用户可识别：用户明确知道"提交采购申请"这一操作
原子性：该操作完成"填写申请单→校验→保存→提交审批"的完整流程，业务上不可再拆分
唯一性：在整个系统中仅计数一次
错误识别示例：
将"采购申请提交"拆分为以下独立事务功能：
"填写申请单"（输入表单）
"数据校验"（校验逻辑）
"保存草稿"（数据存储）
"提交审批"（流程触发）
这种拆分违反了"业务上不能再进一步拆分"的原则。从用户视角来看，"提交采购申请"是一个完整的业务操作，不应被技术性地拆解。
判断"原子性"的标准应站在业务用户的视角，而非开发人员的视角。开发人员可能将一个业务操作拆分为多个技术步骤（前端校验→后端处理→数据库写入→消息推送），但这不意味着每个技术步骤都是独立的事务功能。
02 不同触发方式不重复计数
不应重复计算可通过菜单、按钮等不同方式触发的同一事务功能。
以某CRM系统为例，客户信息查询功能可通过以下方式触发：主菜单进入客户管理再进入客户查询、快捷工具栏的查询按钮、客户列表页面的右键菜单查询详情、首页快捷搜索框输入客户名称回车。
正确做法：
以上均为"客户信息查询"的不同触发入口，仅识别为 1个EQ。
错误做法：
将4种触发方式分别识别为4个EQ，导致功能点虚增300%。
此规则在移动端和Web端混合开发场景中尤为重要。同一功能可能同时存在于App、小程序、H5页面和PC端，如果各端的业务逻辑完全一致（只是界面适配不同），应计为1个事务功能。但如果不同端的业务逻辑存在差异（如App端支持离线操作、PC端不支持），则可能需要分别计数。判断的核心始终是业务逻辑是否相同，而非界面入口是否不同。
03 处理分支不拆分为独立基本过程
不应将一个基本过程的多个处理逻辑、处理分支、具体操作识别为独立的基本过程即相关事务功能（EQ/EI/EO）。
以某保险系统的理赔审核功能为例，该功能包含以下处理逻辑：金额不超过5000元时自动审核通过、金额在5000至50000元之间时需主管审核、金额超过50000元时需风控委员会审核、材料不全时退回补充。
正确做法：
将"理赔审核"识别为 1个EI，包含上述所有处理分支。
错误做法：
将其拆分为：
"小额理赔自动审核"（分支1）
"中额理赔主管审核"（分支2）
"大额理赔风控审核"（分支3）
"理赔退回处理"（异常处理）
这4个识别结果实际上是同一基本过程的不同处理分支，不应独立计数。
对比场景：
如果理赔申请和理赔审核是两个独立的业务操作（由不同角色在不同时机执行、有独立的业务含义），则应分别识别为2个EI。区分的关键在于两个操作是否具有独立的业务语义，而非处理步骤的数量。
04 多处使用的同一事务功能仅计一次
同一事务功能在一个应用的多处位置使用的，只能被计数一次。
以某办公系统为例，附件上传功能被以下模块调用：公文管理中上传公文附件、会议管理中上传会议资料、项目管理中上传项目文档、知识库中上传知识文章附件。
正确做法：
将附件上传识别为1个EI，不因被4个模块调用而计数4次。
错误做法：
分别识别为公文附件上传、会议资料上传、项目文档上传、知识文章上传4个独立的EI。
判断是否为同一事务功能的标准是业务逻辑是否完全一致。如果附件上传的业务逻辑完全一致（选择文件、上传、关联到业务实体），只是关联的目标实体不同，则它是同一事务功能。但如果不同模块的上传逻辑存在本质差异（如公文上传需要数字签名、会议资料上传需要格式转换），则可能是不同的事务功能。
05 列表与筛选选项的计数规则
应用中供用户可选择的列表整体作为一个事务功能进行计数，任何可用的筛选选项不应作为独立事务功能重复计数。
以某商品管理系统中的商品列表页面为例，该页面展示商品列表（含分页），支持按商品名称筛选、按商品分类筛选、按价格区间筛选、按上架状态筛选、按创建时间排序。
正确做法：
将商品列表查询识别为1个EQ，所有筛选条件和排序选项都是该查询功能的参数，不单独计数。
错误做法：
拆分为：
"商品列表展示"（EQ）
"按名称筛选"（EQ）
"按分类筛选"（EQ）
"按价格筛选"（EQ）
"按状态筛选"（EQ）
"按时间排序"（EQ）
这种拆分将一个查询功能的多个参数维度误识别为独立的事务功能。
但需注意，如果筛选本身是一个独立的、复杂的业务功能——如高级检索支持用户自定义检索条件组合、保存检索方案等——则可能需要作为独立的EQ计数。判断的关键在于：筛选是查询功能的参数，还是一个独立的业务操作？
06 不同名称但相同逻辑的事务功能仅计一次
不同名称但具有相同处理逻辑的事务功能，只能被计数一次。
以某政务系统为例，不同部门提出了看似不同的功能需求：民政局的低保户信息登记、人社局的就业困难人员登记、残联的残疾人信息登记。经分析，这3个功能的处理逻辑完全一致：填写人员基本信息（姓名、身份证号、联系方式等）、填写分类信息（困难类型、认定日期等）、附件上传（证明材料）、提交审核。
正确做法：
虽然名称和业务背景不同，但处理逻辑相同，识别为 1个EI（命名为"特殊人群信息登记"或类似）。
错误做法：
因为名称不同就识别为3个独立的EI。
在实际操作中，处理逻辑完全相同的情况并不常见，更常见的是大同小异——80%的逻辑相同、20%有差异。此时应根据差异的性质判断：如果差异仅在参数配置层面（如不同部门使用不同的字段标签），仍可视为同一功能；如果差异涉及不同的业务规则（如不同的审批流程），则应分别计数。建议执行改名测试：对疑似重复的事务功能，尝试将其名称改为相同的名称，如果改名后逻辑描述完全一致，则它们是同一功能。
07 后台功能的事务功能识别
可以将批处理、接口、服务等后台功能根据其主要的业务目的识别为相应的事务功能。
功能点度量关注的是功能本身，而非功能的触发方式。后台批处理、API接口等同样是系统的业务功能，不应因为不是用户直接操作就排除在计数范围之外。
以某金融系统为例，系统包含以下后台功能：
正确做法：
根据后台功能的业务目的，识别为对应的事务功能类型：
写入/更新数据 → EI（外部输入）
生成输出/报表 → EO（外部输出）
响应查询请求 → EQ（外部查询）
错误做法：
认为"后台功能不是用户直接操作的，不应计入功能点"。实际上，功能点度量关注的是"功能"本身，而非"功能的触发方式"。后台批处理、API接口等同样是系统的业务功能。
在微服务架构下，后台服务的功能识别尤为重要。每个微服务API都可能构成一个独立的事务功能。识别时应注意：同一业务逻辑的API（如RESTful的Create和Update）可能属于同一个EI；纯技术性的健康检查、日志接口等不应计数；内部服务间调用如果服务于同一业务目的应合并考虑。
08 总结
事务功能识别的7条控制点可以归纳为三大核心原则：原子性原则，要求站在业务用户视角识别不可再分的基本过程，避免过度拆分业务操作；唯一性原则，要求对同一业务逻辑只计数一次，不因触发方式、使用位置或命名差异而重复计数；业务视角原则，要求以业务目的而非技术实现来判定事务功能的类型和边界。
在实践中，建议从以下方面落实事务功能的质量控制：第一，建立事务功能识别矩阵，将需求文档中的每个功能点映射到EI/EO/EQ类型，检查是否存在重复；第二，绘制功能调用关系图，识别同一功能在不同模块中的复用情况，避免重复计数；第三，对批处理、定时任务、API接口等后台功能建立独立的评估清单；第四，执行改名测试，对疑似重复的事务功能尝试统一命名后比对逻辑一致性；第五，在多端开发场景下重点评估各端业务逻辑是否一致，而非仅看界面差异。
功能点的测算可使用“软件造价喵”：平台集成国内各省市60余个计费标准，支持一键测算，自动生成符合测算要求的造价评估结果，大幅缩短预算编制周期，确保功能点识别的准确性。
事务功能是功能点度量的操作层表达，其识别质量直接反映了度量人员对业务需求的理解深度。只有在事务功能层面做到精准识别、不重不漏，才能确保功能点计数真实反映系统的功能规模，为项目管理和决策提供可靠的量化依据。
