Function points tool, IFPUG Function Points Software,Software Measurement
header image for, ILF and EIF - Identification and Counting Guidelines

Reduce project risk

and optimize the

cost effectiveness

of your software


Total Metrics  >  Function Point Frequently Asked Questions  >  ILF and EIF - Identification and Counting Guidelines

Function Points FAQs

ILF and EIF - Identification and Counting Guidelines


Issue Description

Functional Overview

General Discussion and Resolutio


When reference data is sourced from another system but physically resides within the boundary of an application should it be counted as an ILF or EIF?



This situation most commonly occurs with files that are classified as Reference Data.

There is a valid business requirement for the Reference Data to be accessed by both the source and receiving application, and potentially other applications also. The source application is the owner of the reference data and therefore has primary responsibility for maintaining this data. The data is physically loaded into the receiving application, and transactions in this application reference this physical file.



The Reference Table file is always counted as an ILF by the source application. The Reference Table file in the receiving application may be counted as either an ILF or EIF depending on the particular combination of the following factors:

  1. The data content of the files on the source and receiving systems
  2. The content of the data transfer file that is passed from the source to the receiving system to update it
  3. The nature of the table load/update processing in the receiving system
  4. The requirement to reference other files within the receiving system as part of the load/update processing.

These characteristics are explored in the following table:




Data content of ‘Source’ and ‘Receiving’ files

  • Data attributes and values identical and required to be so.
  • Data attributes of ‘receiving’ file are a subset or a super set of the ‘source’ file.
  • Data values may differ for example, expanded fields descriptions, translated code values.
  • Data content of Transfer file

    • Update records are of one type only.
    • All sites receive exactly the same data.
  • Records are of more than one type and contain a record/transaction type.
  • Individual sites may receive site specific maintenance records.
  • Table Load Processing

    • Simple copy/load process of all records.
    • May involve minor reformatting of data. Reformatting is a requirement of technical platform differences (e.g. Different DBMS).
  • Load processing may involve validation, data extraction, translation of data values, reformatting, aggregation, comparison to existing records to derive update transactions or new fields.



    Reference to other data during processing

    • Load process overwrites existing records without referencing the records. All existing records are overwritten.
    • Table records are changed without reference to any other ‘receiving’ system files.
  • Load process references existing records to identify those impacted by the update.
  • In the process of updating table records, other ‘receiving’ system files are referenced to validate the change or assess the impact of the change. For example, products cannot be deleted if there are outstanding orders for them.

  • For the Reference Table under review, assess each of these characteristics using the guidelines for the data function types. Assign type (ILF or EIF) based on the best profile match for the Reference Table.

    Based upon the determination of file type, count the following functions for the source and receiving systems (assuming both these systems are being function point counted).




    External Interface File


    • 1 ILF for the ‘source’ file.

    Do not count:

    • Download function which transfers data between ‘source’ and ‘receiving’ systems

    Note: Where the source system is unaware of how the download will be used by receiving systems, an EO will usually be counted.


    • 1 EIF for the ‘source’ file that is being referenced.
    • The EIF as an FTR on all transactions that reference the data.

    Do not count:

    • Upload/Copy function that copies data into the ‘receiving’ system file.
    • Transfer file

    Internal Logical File


    • 1 ILF for the ‘source’ file.
    • 1 or more EOs for the transactions passed to the receiving system via the transfer file. Check for unique logical processing.


    • 1 ILF for the ‘receiving’ system file.
    • 1 or more EIs for the processes that load the ‘receiving’ file records. Check for unique logical processing of record types.
    • ILFs/EIFs for any translation/reference tables that are accessed in the load process.
    • The Reference Table ILF as an FTR on all transactions that reference the data.

    Further References

    • Issue External Interface Files – Sample Scenarios
      This description addresses the same issue from a different perspective.


    Issue Description

    Functional Overview

    General Discussion and Resolution

    Legal Notice | Privacy Statement | Feedback | Sitemap | Contact us | Search