更新时间：2026-07-14 09:41:57
本文针对GB/T 18491.5-2010 国家标准开展解读。该标准等同采用 ISO/IEC TR 14143-5:2004，属于GB/T 18491 功能规模测量系列配套规范，提供了功能域确定的方法和原理，通过功能域划分 + FSM方法特性比对，为判定各类FSM方法的适用范围提供分类基础。例如IFPUG和NESMA方法主要适用于以数据持久化、事务处理为核心的信息系统类项目，而COSMIC方法则适用于实时控制、科学计算等非数据主导型软件。整套 GB/T 18491 系列形成完整度量体系，覆盖术语、测量方法、验证、基准、功能域、落地指引六大模块，适用于功能规模测量方法设计方与选型方、软件造价评估机构、基准数据运维方、第三方信息化评审单位等相关主体。下文依据标准依次阐释核心概念、两套功能域判定方法、方法对比、适用性判定及整体应用价值。
同系列延伸阅读：
《信息技术软件测量功能规模测量第2部分：软件规模测量方法与GB/T 18491.1—2001的符合性评价》（GB/T 18491.2-2010）标准解读
GB/T 18491.3-2010《信息技术 软件测量 功能规模测量 第 3 部分：功能规模测量方法的验证》标准解读
《信息技术软件测量功能规模测量第6部分：GBT18491系列标准和相关标准的使用指南》 标准解读
01 核心概念与基础规则
（一）关键术语定义
功能用户需求（FUR）：用户需求的子集。软件必须实现的用户业务惯例和过程,以满足用户的要求。不包括质量需求和任何技术需求
FUR特性：FUR可区分的属性，对标识FUR所属指定集的功能域是重要的；
功能域：基于与功能规模测量有关的用户功能需求特性的软件类。
功能域归类（FDC）：识别符合标准中要求的功能域的过程。
（二）功能域的通用要求
一个功能域应：
唯一性--区别于其他所有的功能域；
例如：信息系统与控制系统二者FUR特性区分清晰，前者核心为业务数据长期存储、查询统计，后者核心为外部设备实时交互、定时中断调度，二者分属完全独立的功能域。
定义依据--由一组与功能规模相关的特性描述；
例如：纯计算系统仅依托数学运算、算法类FUR特性界定，不会将系统响应速度、服务器硬件配置等非功能内容纳入定义依据。
命名规范--使用信息技术业界公认的术语命名，扩展时注明出处；
例如：数据驱动控制系统、科学信息系统等均为行业通用标准命名，若结合项目场景新增自定义混合功能域，必须标注命名依据，避免直接使用实时、MIS、过程控制这类混杂性能、技术实现含义的俗称作为功能域名称。
兼容性--一组FUR可被归属于多个功能域。
例如：银行ATM系统的FUR既包含账户数据的持久化存储（信息系统特征），也包含超时响应和中断处理（控制系统特征），因此可同时归属于多个功能域。
（三）功能域特性的约束
一个功能域的特性应：
继承性--继承GB/T 18491.1中功能规模的所有特性（即功能规模不能由开发、支撑软件所需工作量推导得出，与软件开发、软件运维的实施方法相互独立，同时不受软件物理载体、技术实现部件的影响）；
来源约束--由功能用户需求展示；
技术无关--独立于软件开发方法；
非功能隔离--独立于质量和技术需求。
（四）FDC方法的要求
FDC方法即一套完整、标准化的实施流程，用于执行功能域归类的具体操作方法和规程。一个合规的功能域归类方法应满足可重复、一致、结构化且易于理解的要求，所产出的功能域描述在未来仍保持一致，并能够清晰定义功能域的特性。
02 CHAR方法--自顶向下
CHARs：用于区分、界定不同功能域的特定FUR特性，是开展功能域归类的基础判定要素。(“软件存在长期数据存储需求”“业务带有定时时序约束”“包含复杂科学运算逻辑”即“持久性”、“响应”、“科学/工程”，均属于独立CHARs)
CHAR Group：由一组相互关联的CHARs聚合形成的集合，用于综合判定软件所属大类功能域。（响应、接口、系统管理三类CHARs组合在一起，共同构成“控制和通讯占优”CHAR Group，专门用于识别各类控制系统类软件。）
从整套软件FUR全局特征入手，自上而下整体评估业务倾向性，通过特征占比打分、分组汇总，查表匹配标准预设功能域，适合快速批量分类。
完整评价过程：识别FUR（明确系统边界，梳理全部功能用户需求条目）→评价CHAR重要性等级→汇总CHAR Group等级→从功能域对照表选择功能域→归档判定结果。
1、三组CHARs与等级划分
CHAR方法定义了3组CHARs，每组包含可变数量的CHARs：
（1）控制和通讯占优
响应：FUR包含时间约束；
接口：对外部对象或其他软件的接口控制至关重要；
系统管理：软件通过对外部环境的管理检测越界或紧急数值。
（2）数据占优
复杂数据：复杂的数据或控制关系需求是FUR的重要组成部分；
持久性：数据的持久性或逻辑存储是FUR的重要组成部分。
（3）操作和算法占优
操作：数据的高效处理；
科学/工程：数学或逻辑算法要求；
适应性：软件能根据外部情况动态改变行为或逻辑。
表1 CHAR评价表
2、CHAR Group等级规则，表2
3、功能域对照表（部分），表3
4、实操范例
人力资源FUR：维护和存储职工及其家属信息；维护和存储有效的职位信息；维护和存储工作分配的信息；提供在任何地点及时访问信息的方法；将所有对工资单情况的修改记录到工资单日志中。
（1）识别全部FUR：上述FUR均为用户业务功能需求，全部纳入评价范围。
（2）CHAR评定等级
响应（时间约束）：仅包含常规业务数据维护，无定时巡检、实时中断、时限控制需求，属于批处理类业务，时间约束需求占比极低→可忽略的
接口（外设/外部设备控制）：仅为内部业务数据交互，无硬件控制、工控设备对接等外部对象控制需求→可忽略的
系统管理（超限、紧急工况检测）：仅进行日常信息管理，无运行状态监控、越界检测、紧急情况处理等逻辑→可忽略的
复杂的数据：涉及人员、岗位、薪资等多实体关联管理，数据关系具有一定复杂度，但未达到高度复杂监控场景→一般的
持久性：职工档案、职位信息、工资单日志均需长期保存，数据持久化是核心业务需求，但不属于超高优先级关键监测数据→一般的
操作：提供信息查询、筛选、台账浏览等常规数据处理功能，属于典型业务数据操作场景→一般的
科学/工程：仅为常规业务处理，无科学计算、工程仿真、专业算法建模需求→可忽略的
适应性：按固定业务规则运行，无动态调整、自适应策略、智能决策类逻辑→可忽略的
（3）汇总CHAR Group综合等级
控制和通讯占优：三项CHAR全部为可忽略的→分组等级可忽略的
数据占优：复杂的数据、持久性两项CHAR均为一般的，且数据管理与长期存储为核心业务，需求占比超50%→分组等级重要的
操作和算法占优：仅操作一项为一般的，科学/工程、适应性均为可忽略的，无复杂算法与动态适配需求→分组等级一般的
（4）对照功能域对照表匹配功能域
匹配条件：控制和通讯占优=可忽略的；数据占优=重要的；操作和算法占优=一般的，查表对应功能域：信息系统，功能域评价结果如下：
03 BFC方法--自底向上
基本功能部件（BFC）：由功能规模测量方法定义和使用的，以测量为目的的FUR基本单元。（不同FSM方法定义不同的BFC类型，在IFPUG和NESMA方法中BFC分为五类，即ILF、EIF、EI、EO、EQ）
整体逻辑与CHAR方法完全反向，自底向上拆解全部需求至最小BFC基础单元，从事务、数据、运算、存储四维统计部件组合，结合软件分层规则精准定义功能域。判定过程：剥离全部非功能需求→将FUR拆解为独立BFC基础单元→按四大维度归类统计部件→结合软件分层/分段规则区分模块特征→匹配标准功能域范例。
1、四类BFC
（1）事务种类（3种）
被动的：软件正常情况不做任何事，接收外部输入后处理，完成后恢复空闲。
半主动的：软件必须定期观察外部情况，根据探测结果决定是否响应。
可中断的：在类型1或2模式下运行，但遇到特定事件时必须中断当前操作，立即响应。
（2）认可的数据类型
数据元素类型（DET/数据属性）；
数据组（单个实体类型的数据属性集合）；
声音、图像、动态图像；
数据关联（描述两种数据类型之间意义和关联程度的规则）。
（3）信息创建功能类型
简单布尔运算、简单算术运算；
标准数学/统计学算法、二维/三维几何学；
复杂科学/工程处理、专家系统规则；
启发式或自调整算法、特定业务领域算法。
（4）数据保留需求
不保留的（事务完成后不需要保留）；
处理期间保留的（仅在软件处理期间需要）；
无限期地（长期保留）。
2、功能域定义范例，表4
实际开展评价时可借助AI智能造价工具——软件造价喵，平台基于功能点方法自动解析需求文档，识别ILF、EIF、EI、EO、EQ等功能部件，可查看功能点明细，评价人员可逐项查看，快速审阅FUR全貌，减少重复翻阅原始文档的工作量，提升执行效率。
04 两种方法的对比
05 确定功能域后的适用性判定
标准设置CHAR、BFC两类功能域归类方法的目的并非仅完成软件分类，而是依托分类结果客观评判各类FSM方法的适配程度，形成完整度量前置流程。标准明确了三层适用性比对逻辑：
识别该功能域定义时所用的FDC特性；
识别所选FSM方法认可的BFC类型中涵盖哪些特性；
将功能域特性与FSM方法认可的特性进行比较：
若功能域特性是FSM方法认可的子集→适用；
若功能域特性是FSM方法认可的超集→部分适用（需补充修正系数）；
若完全不匹配→不适用。
06 总结
GB/T 18491.5-2010提供了CHAR、BFC两套判定方法实例，同时明确其他符合要求的结构化方法同样可以采用，为统一软件分类判定标准提供了灵活可行的路径，有效解决了不同功能规模测量方法适配性缺乏客观判定依据的问题。在软件度量实际工作中，开展功能规模测算前完成标准化功能域划分，能够规避因测量方法与软件业务特征不匹配带来的规模失真，保障功能规模结果具备跨项目横向对比的有效性，为全行业软件量化评估提供统一、标准化判定依据。
