本篇主要介紹在功能點分析法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。