Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25437 — Software Engineering: Function Point Analysis
Standardized software sizing for estimation, benchmarking, and productivity measurement
ISO/IEC 25437 standardizes Function Point Analysis (FPA), a method for measuring the functional size of software systems from the user’s perspective. Unlike lines of code (LOC), which measure implementation volume and are language-dependent, function points quantify the functionality delivered — making them comparable across projects, languages, and development paradigms. The standard aligns with the IFPUG (International Function Point Users Group) Counting Practices Manual.
Function point counts are most valuable when tracked historically within an organization. A single count is informative; a trend over 10-20 projects is predictive. Invest in building your organization’s historical database of function point counts and corresponding effort.
The Five Function Types
ISO/IEC 25437 defines five function types that constitute the functional size of an application. These are divided into data functions (internal and external) and transactional functions (inputs, outputs, and queries):
| Function Type | Acronym | Description | Typical Examples |
|---|---|---|---|
| Internal Logical File | ILF | Data maintained within the application boundary | Customer database, product catalog, order history |
| External Interface File | EIF | Data referenced from another application | Reference tax tables, address validation service |
| External Input | EI | Data entering the system boundary | Form submission, sensor reading, API call |
| External Output | EO | Data leaving the system boundary (with derivation logic) | Reports with calculations, invoices, dashboards |
| External Query | EQ | Data retrieval without derived logic | Search results, record lookup, status check |
Each function type is assigned a complexity level — low, average, or high — based on the number of data element types (DETs) and record element types (RETs) for data functions, or file types referenced (FTRs) and DETs for transactional functions. The complexity matrix converts raw counts into unadjusted function points (UFPs).
The ILF/EIF distinction is critical for accurate sizing. A common counting error is classifying internal reference data (e.g., currency conversion tables) as ILF when it is maintained by another application and simply referenced — this overstates the sized application’s functional size by double-counting.
Value Adjustment Factor and Productivity Benchmarking
Unadjusted function points are multiplied by a Value Adjustment Factor (VAF) computed from 14 General System Characteristics (GSCs), each rated 0-5. The GSCs include data communications, distributed data processing, performance, heavy configuration, transaction rate, online data entry, end-user efficiency, online update, complex processing, reusability, installation ease, operational ease, multiple sites, and facilitate change.
The VAF adjusts raw functional size to reflect the technical complexity of the implementation environment. However, ISO/IEC 25437 cautions that the VAF introduces subjectivity — different counters may assign different GSC ratings to the same project. Many organizations now prefer to use unadjusted function points for benchmarking and reserve the VAF for internal estimation calibration.
Productivity benchmarking is one of the most powerful applications of FPA. By dividing actual project effort (person-hours) by function points delivered, organizations derive productivity rates (hours per FP) that are comparable across projects. Industry benchmarks vary widely: typical business applications range from 2-10 hours per FP, while real-time embedded systems may exceed 20 hours per FP due to additional verification and certification requirements.
Do not use function points for performance evaluation of individual developers. FPA measures functional size at the application level, not individual output. Using FP/person as a performance metric encourages counting inflation and undermines the reliability of organizational benchmarks.
Engineering Insights for FPA Adoption
Successfully adopting ISO/IEC 25437 requires attention to three areas: counter training, counting scope discipline, and tool support.
Counter training: Certified function point counting requires a structured learning program. The IFPUG Certified Function Point Specialist (CFPS) certification is the industry standard. Teams should have at least one CFPS-certified member who can conduct independent count audits and resolve boundary disputes. Counting consistency across counters is critical: inter-counter variation exceeding 10% indicates insufficient training or ambiguous counting guidelines.
Counting scope discipline: A counting scope document must be established before counting begins. This document defines the application boundary, identifies each function type instance, and documents counting assumptions. Version control of the counting scope is essential, as requirements changes during development directly impact the function point count.
Tool support: Specialized FPA tools (e.g., CAST, Understand, or integrated ALM platforms) can partially automate function point detection from requirements specifications or design models. Full automation remains challenging because FPA requires understanding of user-intended functionality, which is not fully captured in any single artifact. Semi-automated approaches — where tools identify candidate functions and human counters verify them — offer the best balance of speed and accuracy.
Function point counts must be adjusted when requirements change. If scope creep adds three new external inputs and one internal logical file mid-project, the function point count must be recalculated. Failing to update the count undermines the productivity metrics and makes post-project comparison meaningless.
Frequently Asked Questions (FAQ)
Q1: What is the difference between function point analysis and use case points?
Function points measure the functional size of delivered software based on data and transactional functions. Use case points, by contrast, measure the size of requirements expressed as use cases, incorporating technical and environmental complexity factors. FPA has broader industry adoption and more extensive benchmark databases.
Function points measure the functional size of delivered software based on data and transactional functions. Use case points, by contrast, measure the size of requirements expressed as use cases, incorporating technical and environmental complexity factors. FPA has broader industry adoption and more extensive benchmark databases.
Q2: Can function points be used with Agile development?
Yes. For Agile projects, function points can be counted from user stories or features. The key adaptation is that initial counts are typically higher-level (estimating ILFs and EIs from epic-level descriptions) and refined during iteration planning as stories are decomposed. Many organizations use function points for release-level sizing and story points for iteration-level estimation.
Yes. For Agile projects, function points can be counted from user stories or features. The key adaptation is that initial counts are typically higher-level (estimating ILFs and EIs from epic-level descriptions) and refined during iteration planning as stories are decomposed. Many organizations use function points for release-level sizing and story points for iteration-level estimation.
Q3: How do I start collecting function point data in my organization?
Start with one pilot project. Train 2-3 team members in FPA counting, complete a full count for the pilot, and capture effort data. After the pilot, calibrate your organization’s productivity rate (hours/FP) using the pilot data. Then expand to 5-10 projects before using FPA for estimation on new projects.
Start with one pilot project. Train 2-3 team members in FPA counting, complete a full count for the pilot, and capture effort data. After the pilot, calibrate your organization’s productivity rate (hours/FP) using the pilot data. Then expand to 5-10 projects before using FPA for estimation on new projects.
Q4: What are the limitations of function point analysis?
FPA does not measure algorithmic complexity, non-functional requirements (performance, security, usability), or technical difficulty directly. It measures functional size only. For systems dominated by algorithms (e.g., scientific computing, encryption), FPA may understate the true development effort and should be supplemented with other sizing methods.
FPA does not measure algorithmic complexity, non-functional requirements (performance, security, usability), or technical difficulty directly. It measures functional size only. For systems dominated by algorithms (e.g., scientific computing, encryption), FPA may understate the true development effort and should be supplemented with other sizing methods.
