 | Function-Point | FPA-Transactional-Functions |  |
The Building Blocks of FPA |
Transactions that allow users to feed data into the application.
Reports or messages sent outside the system.
Interactive, read-only requests combining inputs and outputs.
Logical groups of data stored and maintained within the system.
Data used by your system but maintained by external application.
This Section dives into the first half of the FPA count: Data Functions. These represent the logical groups of data that a system maintains (ILFs) or references (EIFs). We will learn how to identify them and, crucially, how to determine their complexity based on their structure. The process begins by identifying all the logical data groups that are meaningful to the user. This is typically done by reviewing user requirements, screen designs, and reports, looking for nouns and objects that the user interacts with. A key principle is that a data function must be "user-identifiable" – meaning the user recognizes it as a distinct set of information. It's not a technical detail like a database table name, but a business concept like 'Customer Records' or 'Sales Orders'.
An ILF is a user-identifiable group of logically related data or control information that resides entirely within the application and is maintained through one or more of the application's transactional functions (e.g., a "Customer" file in an accounting system where you can add, edit, and delete customers). An EIF is also a user-identifiable group of logically related data, but it is used by the application for reference purposes only and is maintained by another application (e.g., a "Product Catalog" file that an e-commerce site reads from a separate inventory system; the e-commerce site can't change the product data itself). The key distinction is who maintains the data: the application itself for an ILF, or an external system for an EIF. This distinction is critical because an ILF implies a greater level of development effort for create, read, update, and delete functionality, which is reflected in its higher weight during the calculation.
The complexity of a Data Function (ILF or EIF) is determined by two factors: **Data Element Types (DETs)** and **Record Element Types (RETs)**. A **DET** is a unique, user-recognizable, non-repeated field (e.g., 'Customer Name', 'Address', 'Order Date'). The count of DETs represents the number of unique data fields presented to the user. A **RET** is a user-recognizable subgroup of data elements within an ILF or EIF (e.g., in a 'Customer' ILF, 'Shipping Address' and 'Billing Address' could be two separate RETs, each with its own set of DETs like Street, City, State, and Zip). The number of RETs indicates how many logical sub-groups the user can identify in the data file. The more DETs and RETs a data function has, the more complex it is considered. The logic here is that a file with many different data fields or multiple logical subdivisions is inherently more complex to design and manage than a simple one with only a few fields.
The matrix below shows how complexity is determined by the number of Record Element Types (RETs) and Data Element Types (DETs). To use the matrix, you find the intersection of the RET and DET counts for a given function to determine if it is Low, Average, or High complexity. This complexity level then corresponds to a specific weight used in the UFP calculation. For example, a file with 4 RETs and 25 DETs would be classified as 'High' complexity, and an ILF of this complexity would be assigned a weight of 15, reflecting its significant size and effort.
| RETs / DETs | 1-19 | 20-50 | 51+ |
|---|---|---|---|
| 1 | Low | Low | Average |
| 2-5 | Low | Average | High |
| 6+ | Average | High | High |
| | Function-Point | FPA-Transactional-Functions | |