本篇主要介绍在功能点分析法FPA中，如何计算一个处理元（EI/EO/EQ）有多少个功能点。ILF/EIF的功能点是根据其包含的DET和RET来确定的；EI/EO/EQ的功能点则是根据其包含的DET和FRT来确定的。计算流程也与ILF/EIF的功能点计算流程类似，分为四小步。1. 统计EI/EO/EQ中的数据元素类型FTR。
2. 统计EI/EO/EQ中的记录元素类型DET。
3. 参照FTR/DET——复杂度对照表，确定该IEI/EO/EQ的复杂度。
4. 参照复杂度——功能点对照表，确定该EI/EO/EQ的功能点数。
IFPUG根据大量的项目统计数据，分别为EI、EO和EQ给出了FTR/DET——复杂度——功能点数的对照表。我们只需按图索骥即可，不需要任何的数学计算公式。
计算EI/EO/EQ的功能点数，应当在列出所有的EI/EO/EQ后进行。本系列笔记四介绍了如何是识别EI/EO/EQ。
1. 文件类型引用FTR
FTR (File Type Referenced)在IFPUG CPM中的定义有两条：An ILF read or maintained by a transactional function; Or An EIF read by a transactional function。其实说白了就一条，在一个处理功能中涉及到的所有逻辑文件。处理功能可能是EI/EO/EQ；逻辑文件是ILF/EIF。
CPM分别讲述了在EI、EO和EQ中统计FTR的规则，归纳起来其实都一样，十分简单明了。
l 在EI/EO中每一个被维护的ILF计为一个FTR。
l 在EI/EO/EQ中每一个被读入的ILF/EIF计为一个FTR。
l 如果在一个EI/EO中，一个ILF既被读入，也被维护，只计一个FTR。
所谓“维护”，在本系列笔记的前面某篇最后中有介绍，是指创建、添加、修改或删除一个ILF。由于EQ中不可能有维护ILF的操作，所以它一定没有和维护相关的FTR。
2. 数据元素类型DET
处理功能中统计的DET，和ILF/EIF中统计的DET，定义是一样的：A data element type is a unique user recognizable, non-repeated field。它们可以算是同一个东西，只不过计数规则不同。
l 每一个满足下列所有条件的字段都要计为一个DET.
n 用户可识别的。
n 不重复的。
n 为完成相应的处理元而进入或退出系统边界的。
l 没有穿越系统边界的字段不能计为DET，这些字段通常是有两种情形：
n 由系统从ILF中获取的字段，
n 系统衍生的并保存在ILF中的字段。
n 硬编码的文本，如标题。
n 系统生成的时间戳。
n 系统生成的变量，如页码、行列号等位置信息、向前向后等导航信息。
l 如果系统具有向外界发送处理状态消息的机能，将该机能计为一个DET。处理状态消息通常用来
n 指示处理异常。
n 指示处理已完成。
n 确认处理是否继续。
l 对每一个输入的操作指令计为一个DET。只要指令要求的操作一样，无论有多少个方式输入指令，都只计一个DET。直观的看，一个按钮或菜单项就是一个DET。但键盘快捷键十有八九不是。
3. FTR/DET——复杂度——功能点数的对照表
同ILF/EIF的功能点数对照表类似，EI/EO/EQ也是按照三级复杂度来确定功能点数。EI、EO和EQ的复杂度和功能点数对照表各不相同。归纳如下面量表所示。
表格 2 处理元复杂度矩阵
| EI复杂度 | EQ/EO复杂度 | ||||||
| DET个数 RET个数 | 1 ~ 4 | 5 ~15 | >=16 | DET个数 RET个数 | 1 ~ 5 | 6 ~19 | >= 20 |
| 1 | 低 | 低 | 中 | 1 | 低 | 低 | 中 |
| 2 | 低 | 中 | 高 | 2 ~ 3 | 低 | 中 | 高 |
| >= 3 | 中 | 高 | 高 | >= 4 | 中 | 高 | 高 |
表格 3 处理元功能点计算表
| 复杂度 | 低 | 中 | 高 |
| EI/EQ功能点数 | 3 | 4 | 6 |
| EO功能点数 | 4 | 5 | 7 |
得到每一个EI/EO/EQ的功能点数后，把它们的功能点数简单加和起来，就是整个系统的处理功能点数了。
4. 案例——员工信息表
一个简单的员工信息维护界面，如下图所示，不涉及任何EIF。
图表 1 员工信息界面
l 它只有一个FTR，就是ILF员工信息。
l EI保存处理元有8个DET：六个字段，加两个按钮。取消按钮不算。
l EI上除处理元有3个DET：六个字段算一个DET，两个按钮算两个DET。