Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26564 — IFPUG Functional Size Measurement in Software Engineering
A Practical Guide to Function Point Analysis for Estimating, Benchmarking, and Managing Software Projects
ISO/IEC 26564: Applying IFPUG Functional Size Measurement to Software Engineering
ISO/IEC 26564 defines the application of IFPUG (International Function Point Users Group) Functional Size Measurement (FSM) within the context of software engineering. Function point analysis quantifies the functionality delivered by a software application from the end user’s perspective, independent of the technology used to implement it. This technology-neutral measurement makes function points invaluable for benchmarking, estimating, and comparing productivity across different development approaches and technology stacks.
Unlike lines of code (LOC), which measure implementation size and vary wildly between programming languages, function points measure the “what” — the functional value delivered to the user. A function point count remains stable whether the implementation uses assembly, C++, Python, or a low-code platform for the same functionality.
ISO/IEC 26564 adapts the IFPUG Counting Practices Manual (CPM) to the specific needs of software engineering organizations. It defines five function types: External Inputs (EI), External Outputs (EO), External Inquiries (EQ), Internal Logical Files (ILF), and External Interface Files (EIF). Each function type is assigned a complexity level — low, average, or high — based on the number of data element types (DETs) and file types referenced (FTRs for transactional functions, RETs for data functions).
| Function Type | Abbreviation | Description | Example |
|---|---|---|---|
| External Input | EI | Data entering the application boundary (forms, imports, sensor readings) | User registration form submission |
| External Output | EO | Data leaving the application boundary with derived or calculated information | Monthly sales report with totals |
| External Inquiry | EQ | Data retrieval without derived data; simple read-only access | Customer account balance lookup |
| Internal Logical File | ILF | Data maintained within the application boundary | Product inventory database table |
| External Interface File | EIF | Data referenced from another application’s ILF | Reference customer data from CRM system |
Function point counting is most reliable when performed early in the requirements phase, before implementation decisions bias the count. Counting from a well-structured requirements specification or user story map yields the most consistent results across different counters.
Counting Process and Complexity Determination
The ISO/IEC 26564 counting process follows a structured sequence: first, determine the counting scope and application boundary; second, identify and catalog all data functions (ILF and EIF); third, identify and catalog all transactional functions (EI, EO, EQ); fourth, assign complexity ratings to each function; and finally, calculate the unadjusted function point count. Optionally, value adjustment factors (VAF) — based on 14 general system characteristics — can be applied to derive the adjusted function point count.
Complexity determination is where the most judgment is required. For transactional functions, the number of DETs (unique user-recognizable fields) and FTRs (files maintained or read) determine complexity. For data functions, DETs and RETs (record element types, or logical subgroups within a file) are the determining factors. ISO/IEC 26564 provides detailed decision tables to ensure consistent complexity assignments across different counters.
The most common source of counting inconsistency is the “boundary question” — what is inside versus outside the application. ISO/IEC 26564 emphasizes that the boundary must be defined from the user’s perspective, not the developer’s. A common heuristic: if the user can perceive it as a separate system, it belongs outside the boundary.
Practical Applications in Software Projects
Function point analysis under ISO/IEC 26564 enables several critical software engineering practices. For project estimation, historical productivity data (function points per staff-month) can be combined with function point counts to produce effort estimates with known confidence intervals. For benchmarking, function points provide a normalization basis for comparing productivity across projects, teams, and organizations. For contract management, function points offer an unambiguous measure of scope that is resistant to gold-plating and scope creep.
The standard also addresses the use of function points in agile development. While traditional function point counting assumes complete up-front requirements, ISO/IEC 26564 provides guidance on counting in iterative contexts where requirements evolve. The recommended approach is to count the function points delivered in each iteration and aggregate them across the release, treating the function point count as a living metric rather than a one-time estimate.
Function points are not a silver bullet. They measure functional size, not quality, performance, security, or usability. A high-function-point application that is riddled with bugs or fails to meet performance requirements may still deliver less business value than a smaller, well-crafted application. Always combine function point analysis with quality metrics for a complete picture.
Frequently Asked Questions
Q: How long does it take to become certified in IFPUG counting under ISO/IEC 26564?
A: The IFPUG certification program typically requires 3-5 days of structured training followed by a certification examination. Most practitioners achieve basic proficiency after counting 3-5 real projects under the guidance of an experienced counter.
A: The IFPUG certification program typically requires 3-5 days of structured training followed by a certification examination. Most practitioners achieve basic proficiency after counting 3-5 real projects under the guidance of an experienced counter.
Q: Can function points be automatically counted from source code?
A: Fully automated function point counting from source code is difficult because function points measure user-visible functionality, not implementation artifacts. However, tools can assist by identifying candidate functions from UI definitions, API specifications, or database schemas, which are then verified by a human counter.
A: Fully automated function point counting from source code is difficult because function points measure user-visible functionality, not implementation artifacts. However, tools can assist by identifying candidate functions from UI definitions, API specifications, or database schemas, which are then verified by a human counter.
Q: How do function points relate to the COCOMO estimation model?
A: Function points can be converted to equivalent source lines of code (using language-specific conversion tables from the International Software Benchmarking Standards Group) and then used as input to COCOMO or other parametric estimation models.
A: Function points can be converted to equivalent source lines of code (using language-specific conversion tables from the International Software Benchmarking Standards Group) and then used as input to COCOMO or other parametric estimation models.
