整理的功能点计算法
功能点计算方法
来填写上面的表格
分数（0-5） 0 3 3 3 3 3 3 0 3 3 3 3 0 3 33 116
理由
FP转换成SLOC
注意: 1.如果你可以用历史数据，我们建议你使用它。例如，当你设定影响因数时，你可以参考一些 史的项目。 2.如果你的项目可以分成几个子项目，那你应对每个子项目分别来填写上面的表格
复杂个数 0 0 0 0 10 100
大小估算 - FP
操作 外部输入（EI） 外部输入（BO） 外部查询(EQ) 内部逻辑文件(ILF) 部接口文件(EIF 未调整FP个数(UFP)
简单个数 1 0 0 0 0 3
一般个数 0 1 0 1 0 15
事物 Data Communications(数据通信 Distributed Functions(分布式数据处理 Performance(系统响应速度及处理能力) Heavily Used(大量使用) Transaction Rate(事务比率) Online Data Entry(在线数据输入) End-user Efficiency(用户友好度) Online Update(在线升级) Complex Processing(复杂处理) Reusability(复用性) Installation Ease(易安装性) perational Ease(易运行性) Multiple Sites(多站点支持) Change(易改变性) 总分 调整的FP合计 根据公式计算： VAF = (TDI*0.01)+0.65 FP=UFP*VAF TDI：总的影响程度UFP：未调整的功能点 VAF：价值调整因素
简单系数 一般系数 复杂系数 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10
功能点法测算
功能点法测算
功能点分析法是一种用于测量软件规模和复杂度的方法，它基于软件功能的角度来估算工作量、成本和时间等。
以下是功能点法测算的一般步骤：
1. 识别和定义功能：首先，需要明确软件系统要实现的功能和特性。
这些功能可以通过需求文档、用户故事、用例等方式进行描述。
2. 确定功能点类型：根据所识别出的功能，将其分类为不同的功能点类型。
常见的功能点类型包括：外部输入、外部输出、内部逻辑文件、外部接口文件等。
3. 计算功能点数：针对每个功能点类型，根据其复杂度和特性，使用相应的计算规则来确定功能点数。
这些规则通常基于功能的数量、数据类型、处理逻辑等因素。
4. 调整功能点数：根据项目的具体情况，可以对计算得到的功能点数进行调整。
这可能涉及考虑诸如技术复杂度、用户体验、可靠性要求等因素。
5. 汇总和分析功能点数：将各个功能点的数量汇总起来，得到整个软件系统的总功能点数。
然后，可以使用功能点数来估算项目的规模、工作量、成本和时间等。
需要注意的是，功能点法是一种相对抽象的估算方法，它主要关注功能的数量和复杂度，而不直接涉及具体的技术实现细节。
在实际应用中，需要结合项目的特点和团队的经验进行适当的调整和验证。
功能点法的优点是可以提供一种相对客观和一致的方式来测量软件规模，但它仍然存在一定的不确定性和主观性。
因此，在使用功能点法进行测算时，建议结合其他估算方法和实际经验进行综合判断。
软件工程功能点计算公式
软件工程功能点计算公式是一种用于估算软件项目工作量的方法。
功能点是软件功能的一种度量单位，根据软件项目的特性，将功能点转换为人力、时间等其他资源的需求。
功能点计算公式如下：
功能点= (未调整功能点数量× 软件类别调整因子) × 复用系数
其中，未调整功能点数量可以通过预估或估算的方式得出。
预估功能点计数方法包括内部逻辑文件数量(ILF)、外部接口文件数量(EIF)、外部输入数量(EI)、外部输出数量(EO)、外部查询数量(EQ)。
估算功能点计数方法也有类似的计算公式。
软件类别调整因子和复用系数则根据软件的复杂程度、复用程度等因素进行取值。
例如，对于定制软件开发内容包含多种软件类型的情况，原则上按照主体功能的类型取值；对于在已有软件系统或功能模块基础上进行优化完善或调整改造的，复用度调整系数默认取值为2/3。
在实际应用中，功能点计算公式可以结合具体的项目需求进行调整和优化。
功能点估算法介绍及应用
一、功能点估算法识别项目范围和数据复杂度功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：•功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法，则误差会比较大。
•使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
•功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。
•通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括：1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。
功能点计算方法[学习内容]
![功能点计算方法[学习内容]](https://img.taocdn.com/s3/m/891503e81eb91a37f1115cde.png)
对EI\EO\EQ复杂度的计算可理解对为业务实现复杂度的计算，
复杂性由数据元素类型（DET）和文件引用类型（FTR）
17
决定
识别数据功能和识别事务功能
特选内容
事务功能 外部输入EI 外部输出EO 外部查询EQ
Application A file file file
Application B file
特选内容
数据功能（Data Function）
ILF
1 to 19 DET
20 to 50 DET 51 or more DET
1RET
Low（7）
Low（7）
Average（10）
2 to 5 RET
Low（7）
Average（10） High（15）
6 or more RET Average（10） High（15）
特选内容
功能点计算方法
1
特选内容
1
功能点概述
2
功能点分析
3
功能点计算
2
特选内容
1
功能点概述
3
特选内容
IFPUG起源
IFPUG起源
1979 IBM提出需求：以一种独立于计算机语言的方法来 评估软件开发成果
20世纪80年代初，正式的FP使用指南发布 20世纪80年代末，IFPUG成立 1988 FP CPM release 2.0 1990 FP CPM release 3.0 1994 FP CPM release 4.0 1999 FP CPM release 4.1 2003 加入ISO/IEC标准 2004 FP CPM release 4.2
升级项目
对现有应用程序修改：新增、删除和改变功能 也可能含转换功能点
功能点分析法IFPUG
功能点分析法IFPUG功能点分析法(IFPUG)是一种常用的软件功能点评估方法，用于对软件开发中的各个功能点进行评估和估算。
它是由国际功能点用户组织(IFPUG)提出和推广的一种评估方法，是目前业界使用最广泛的功能点分析方法之一首先是鉴别功能点。
在这个步骤中，需要识别出软件系统中的各个功能点。
一个功能点是用户对系统的一个可视功能需求，它可以是一个输入项、一个输出项、一个查询项或一个用户界面。
通过分析需求文档和与客户的沟通，可以确定系统中的功能点。
接下来是计算功能点。
在这个步骤中，需要根据功能点类型的不同来计算功能点的数量。
对于输入项、输出项和查询项，可以根据其数量来计算功能点的数量。
对于用户界面，可以根据其复杂程度和用户思维的变化来计算功能点的数量。
通过计算功能点的数量，可以对软件开发的工作量进行估算。
然后是功能点评估。
在这个步骤中，需要对鉴别出的功能点进行评估。
评估功能点的复杂程度和难度，以确定其对开发工作的影响。
评估结果可以用来调整功能点的数量和开发工作的时间和资源，以更准确地完成开发任务。
最后是功能点估算。
在这个步骤中，需要根据功能点的数量和评估结果来进行功能点的估算。
通过将功能点的数量乘以每个功能点的工作量，可以得到整个软件开发任务的工作量。
根据团队的能力和资源，可以确定开发任务的时间表和资源分配。
1.精确度高：功能点分析法(IFPUG)可以通过对软件系统的功能点进行细致的评估和估算，从而得到比较准确的开发工作量和时间估算结果。
2.简洁易懂：功能点分析法(IFPUG)的方法和计算公式相对简单明了，易于理解和操作，可以快速进行功能点的评估和估算。
3. 适用性广泛：功能点分析法(IFPUG)不仅适用于传统软件开发，也适用于Web应用、移动应用和嵌入式系统等各种类型的软件开发项目。
总之，功能点分析法(IFPUG)是一种有效的软件功能点评估方法，通过对软件系统的功能点进行评估和估算，可以更加准确地确定开发工作量和时间表，提高软件开发的效率和质量。
功能点估算法
功能点是基于软件信息领域的可计算的(直接的)测量及对其复杂性的评估而导出的。
功能计算如图1所示。
针对每个功能确定了外部输出数、外部输入数、文件数、用户查询数和外部接口数等五个信息域特征，每个信息域特征值按下列方式定义。
1)用户输出数计算每个用户输出，外部输出是为用户提供的面向应用的输出信息，这些信息通常包括报告、屏幕信息、错误信息等方面的内容。
每一个外部输出数据都要进行计数，获得外部输出数。
2)用户输人数计算每个用户输入，它们向软件提供面向应用的数据。
外部输入是每个用户输入的面向不同应用的输入数据，输入应该与查询区分开来，分别计算。
3)文件数计算每个逻辑的主文件。
逻辑文件是软件修改或保存的逻辑记录集合，它可以是一个大的数据库的一部分，也可以是一个独立的文件。
4)用户查询数一个查询被定义为一次联机输入，它引发软件以联机方式产生某种即时响应，是软件以联机输出方式产生的独立查询信息。
每一个不同的查询都要计算。
5)外部接口数外部接口是所有用来将信息与其他系统进行交互或共享的端口(如磁带或磁盘上的数据文件)，利用这些接口可以将信息从一个系统传送到另一个系统。
收集到以上五个信息域特征值后，就将每个计数与一个复杂度值(加权因子)关联上。
采用功能点的组织建立了一个标准，以确定某个特定条目是简单的、平均的还是复杂的。
不过复杂的确定多少有些主观。
每个功能的总计数值可以作为这个功能的功能点使用，以估算该功能的成本和工作量。
整个项目的估算还应考虑一些全局性的因素，并不是所以功能总计数值的简单相加。
整个项目的功能点计算采用下面的公式：总FP=∑每个功能的总计数值×(0.65+0.01×∑Fi)其中，Fi(i=1，2，…，14)是基于对图2中问题的回答而得到的“复杂度调整值(0～5)”。
等式中的常数是根据经验确定的。
Fi的取值在0～5之间：Fi：(1)系统需要可靠的备份和复原吗?(2)需要数据通信吗?(3)有分布处理功能吗?(4)性能很关键吗?(5)系统在一个已有的、很实用的操作环境中运行吗?(6)系统需要联机数据项吗?(7)联机数据项是否需要在多个屏幕或多个操作之间切换以完成输入?(8)需要联机更新主文件吗?(9)输入、输出、文件或查询很复杂吗?(10)内部处理复杂吗?(11)代码需要被设计成可复用的吗?(12)设计中需要包括转换及安装吗?(13)系统的设计支持不同组织的多次安装吗?(14)应用的设计方便用户修改和使用吗?一旦计箕出功能点，则可以使用它以规范软件生产率、质量及其他属性的测量和估算，也可以类似于LOC的方法来对每个功能点的错误数、每个功能点的缺陷数、每个功能点的成本、每个功能点的文档页数、每人月完成的功能点数进行估算。
功能点估算法介绍及应用
一、功能点估算法识别项目范围和数据复杂度功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：•功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法，则误差会比较大。
•使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
•功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。
•通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括：1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
整理的功能点计算法功能点描述功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要，如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及，对软件项目范围的估算有很多种方法，常见的就是LOC代码行和FP功能点法，它们之间的区别和关系如下：1、FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。
2、使用FP功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法与软件开发技术密切相关。
3、FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算的。
4、通过一些行业标准或企业自身度量的分析，FP功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测，在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同，因此在项目结束时还需要对项目的范围情况进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点的公式：●功能点的原始计算公式：FP Count =UFP * VAF●新开发项目有时新开发的软件项目也需要与其他现存的软件系统进行整合，例如：一个企业新开发的MIS 内部管理系统经常会与财务系统进行整合。
这个时候除了考虑本身项目的功能点个数外，还要考虑系统整合或数据迁移部分的工作量，因此其功能点计算公式如下：FP Count =（UFP+CFP）* VAF●二次开发的项目有时新开发的软件项目是在原有基础上进行二次开发的，只是为了增加一些新的功能，因此其功能点计算公式如下：FP Count = ADD * VAFUFP：未调整的功能点个数1、人机交互（程序复杂度）（1）、EI: External Input外部输入（2）、EO: External Output外部输出（3）、EQ: External Inquiry外部查询2、数据存储（数据库复杂度）1、ILF：Internal Logical File内部逻辑文件2、EIF: External Interface File外部接口文件识别功能点的重要原则ILF、EIF要与EI、EO、EQ分开计算。
对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。
对EI、EO、EQ复杂度的计算可以理解为对程序开发复杂度的计算。
一般软件项目都是由数据和程序构成的，因此计算ILF、EIF和计算EI、EO、EQ之间没有任何关系。
参数介绍：数据单元类型（Data Element Type, DET ）用户可识别的无递归、不重复的信息单元。
记录单元类型（Record Element Type,RET ）在ILF或EIF中，用户可识别的数据域的子集，可以通过检查数据中的各种逻辑分组来识别它们。
引用文件类型（File Type Referenced,FTR ）被事务功能读取或维护的内部逻辑文件(ILF)，或者是被事务功能读取的外部接口文件(EIF)。
（1）EI、EQ和EO的技术复杂的计算复杂性取决于FTRs和DETs的数量。
FTR是被一个事物操作读取或维护的一个ILF，或者是被一个事物操作读取的一个EIF。
EI中识别FTR规则●每一个ILF应该算做一个FTR。
●通过EI读取操作的每个ILF或EIF都应该被计算为一个FTR。
●即被EI维护又被读取的ILF仅计算一个FTR。
EI中识别DET规则●在EI的过程中，以用户角度识别的，通过应用系统边界输入系统内部的非重复的字段，那么该字段应算一个DET。
●如果在EI过程中，只要没有通过系统边界输入，就算它存在于系统内的一个ILF中，也不能算为一个DET。
✓例如外贸订单系统中，订单的金额是被单价和数量自动计算的，那么金额是没有通过系统边界输入的，因此在EI操作中就不应该算做一个DET。
●在应用程序的EI操作时，系统提示的错误信息或完成操作的信息，应该被分别计算为一个DET。
✓例如在网站注册用户信息时，由于输入错误系统会显示提示信息，那么这些提示信息应该被逐个计算为一个DET。
✓当EI操作完成时系统提示并显示出来的信息，应该被计算为DET。
●在EI操作中如果遇到主外键的字段，应该算作一个DET。
EO和EQ计算FTR的规则●通用规则：每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR●EO额外的FTR计算规则✓在EO处理过程中每个被维护的ILF算一个FTR✓在EO处理过程中既被读取又被维护的ILF算一个FTREO和EQ计算DET的通用规则●用户可识别的非重复的字段，进入应用边界并且指明处理什么，何时处理或处理方式，并且由EO/EQ 返回或产生，那么这样的每个字段算一个DET✓例如在报表中的每个字段都是一个DET●在应用边界内以用户角度识别的，非重复字段算一个DET。
✓例如在报表上起到解释或备注作用的文字信息，不管它是一个字、一个词或一段话，都当作一个DET✓例如某种编号或日期，就算它被物理存储在不同字段中，但从用户角度来看是一个整体的信息，因此被算作一个DET✓例如在饼图中百分比和分类算作不同的DET。
●在EO或者EQ操作中，如果对系统进行输入或读取操作时，相同的字段只计算一个DET。
✓例如在报表查询时，输入的字段在报表上也有显示，那么将算作同一个DET●在应用程序的EO或EQ操作时，系统提示的错误信息或完成操作的信息，应该被计算为DET。
✓例如用户查询一个列表时被拒绝，那么拒绝的提示信息就算为一个DET。
●在EO或EQ操作中如果遇到主外键的字段，应该算作一个DET。
●如果在EO或EQ过程中，只要没有通过系统边界输入，就算它存在于系统内的一个ILF中，也不能算为一个DET。
✓在公司发工资的时候，员工对应的状态信息被更新，但这个状态信息的更新是没有通过系统边界输入的，因此也不能算做一个DET。
●页面的标题等类似的信息不计算DET●系统字段生成的记号不能被算作一个DET。
✓例如：页码、位置信息、时间、上一页、下一页等信息。
EI复杂度计算矩阵DET识别规则用户可识别，非重复的字段，通过基本流程处理ILF/EIF时获得。
eg: 如果员工号在一个ILF或EIF中出现两次，一次是作为员工记录的主键，一个是作为家属信息的外键，员工号记为一个DET.当两个应用程序维护或引用相同的ILF、EIF，但是各自使用不同的DET，那么仅计算它使用到的DET。
eg: 应用程序A使用到的地址信息包括：street address, city, state, zip code. 应用程序B 可能把地址当做一个整体而未细化到个体，因此应用程序A计数有4个DET，而应用程序B计数有1个DET。
每个被用户用来和其他ILF或EIF建立关系的数据也是一个DET。
eg: 在HR系统中，员工信息是一个ILF，员工职位名称也算作是员工信息的一部分，被算作一个DET，因为它可以把员工和职位联系起来，这类DET成为外键。
RET识别规则RET是指一个EIF/ILF中用户可以识别的DET的集合。
如果把DET简单理解为字段的话，那RET就可以简单地理解为数据库中的表。
如：订单内部逻辑文件由于存在订单头和明细关联引用，RET应该算2个（2）内部逻辑文件与外部接口文件ILF内部逻辑文件内部逻辑文件是指一组以用户角度识别的，在应用程序边界内且被维护的逻辑相关数据或控制信息。
ILF的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。
EIF外部接口文件外部接口文件是指一组在应用程序边界内被查询，但它是在其他应用程序中被维护的，以用户角度来识别的，逻辑上相关的数据。
因此一个应用程序中的EIF必然是其他应用程序中的ILF。
EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。
EIF所遵循的规则：从用户角度出发识别的一组逻辑数据。
⏹这组数据是在应用程序外部，并被应用程序引用的。
⏹计算功能点的这个应用程序并不维护该EIF⏹这组数据是作为另一个应用程序中的ILF被维护的。
ILF和EIF复杂性计算ILF和EIF的复杂性是取决于RET（Record element type）和DET（Data element type）的数量。
DET是一个以用户角度识别的，非重复的有业务逻辑意义的字段。
DET计算的规则：●通过一个基本处理过程的执行，对ILF进行维护或从ILF/EIF中返回一个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个DET。
✓例如：添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”，那么对于ILF订单来说它的DET就是4个。
✓例如：保存订单时还会保存订单的明细，订单的明细往往作为一个子表进行保存，那么“订单号码”在主表和子表中都同时存在（主外键），但以用户角度来识别时，存盘操作是一个最小的单位，那么订单号码只能算做一个DET。
●当两个应用程序维护和/或引用相同的ILF/EIF，但是每个应用程序分别维护/引用它们相应的DET时，这些DET在这两个应用程序的维护或引用中将单独计算。
✓例如一个应用程序的两个“Elementary Process”基本处理过程都需要使用到“地址”的信息，地址的信息又可以细分为“国家、城市、街道、邮编”。
那么对于其中一个基本处理过程来说，他将整个地址信息作为一个整体进行处理，那就只算一个DET，另外一个基本处理过程使用每个地址的详细信息，那么DET 就是4个。
➢RET计算的规则如下：RET是指一个EIF/ILF中用户可以识别的DET的集合。
如果把DET简单理解为字段的话，那RET就可以简单理解为数据库中的表。
RET在ILF/EIF中分为两种类型：可选的（Optional）和必选的（Mandatory）。
计算RET的规则为以下两点：●在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。
或者●如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个RET。
✓例如：在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。
那么订单系统ILF中RET为：1、订单信息（必选的）2、客户信息（必选的）3、部门信息（可选的）因此ILF中RET的个数为3个。
➢ILF/EIF复杂度的矩阵如下外部输入EI的DET识别规则：规则1：在EI的过程中，以用户角度识别的、通过应用系统边界输入系统内部的非重复字段，算作一个DET。