Function Point Analysis
Function Point Analysis and Software Sizing · Also known as: FPA, function points, IFPUG sizing
Function point analysis (FPA) quantifies software size by counting business functions and user interactions independent of technology or programming language. Introduced by Albrecht (1979), FPA measures delivered functionality, enabling effort estimation, productivity benchmarking, and software value assessment. Organizations use FPA for project contracts, vendor comparison, and portfolio management.
Read the full method
Sign in with a free account to read this section.
Method map
The neighbourhood of related methods — select a node to explore.
When to use it
Apply FPA early in requirements phase when business functions are known but implementation details are undefined. Particularly valuable for fixed-price contracts, vendor selection, and data-intensive systems. Effective for software maintenance estimation and productivity tracking. Less suitable for real-time, safety-critical systems with complex algorithms. Requires domain expertise to count accurately.
Strengths & limitations
- Language-independent, enabling fair comparison across technologies and vendors
- Focused on delivered functionality, aligning with business value assessment
- Extensive historical databases enable calibrated productivity metrics and benchmarking
- International standard (IFPUG) ensures consistency and credibility
- Counting function points requires significant expertise and subjective judgment
- High variability across counters; training and standards reduce but do not eliminate bias
- Less effective for modern software patterns: mobile apps, microservices, cloud-native systems often resist neat function categorization
- Value adjustment factors are controversial; some practitioners question their validity and statistical basis
Frequently asked
What is the difference between function points and story points?
Function points measure absolute system size (language-independent, industry-standard); story points measure relative complexity (team-specific). Function points suit contracts and cross-organizational comparison; story points suit agile planning. Function points require trained counters; story points use planning poker and team consensus. For long-term productivity tracking, use function points; for sprint planning, use story points.
How accurate are function point estimates?
Well-trained counters achieve ±10% consistency on same code. Cross-counter variability reaches 20–30%. Estimation of new systems (before build) using requirements has ±20% accuracy. After implementation, counting actual delivered functions achieves ±10% accuracy. Productivity estimates (function points to effort) vary 30–50% across organizations due to differences in technology, team, and process.
How do I establish productivity baselines for my organization?
Collect 5–10 completed projects: count delivered function points, record actual effort (person-hours), document technology and process context. Compute effort/FP ratio per project. Average across projects, excluding outliers. Use this baseline for new project estimation. Update periodically (quarterly/annually) as team evolves. Track actual vs. estimated effort to refine baseline.
What should I do if function point counting produces highly variable results?
Invest in training: ensure counters understand IFPUG standards. Use counting standards checklist to standardize judgments. Count sample project with multiple independent counters; reconcile differences and document reasoning. Use average of multiple counters rather than single estimate. Consider hiring external certified FP analyst for high-stakes projects where accuracy matters most.
Sources
- Albrecht, A. J. (1979). Measuring application development productivity. In Proceedings of the IBM Applications Development Symposium (pp. 83–92). link ↗
- International Function Point Users Group (2010). Function Point Analysis Counting Practices Manual. IFPUG. link ↗
- Jones, C. (2008). Applied Software Measurement: Global Analysis for Improving Software Productivity and Quality (3rd ed.). McGraw-Hill. link ↗
How to cite this page
ScholarGate. (2026, June 3). Function Point Analysis and Software Sizing. ScholarGate. https://scholargate.app/en/software-engineering/function-point-analysis
Which method?
Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.
- Agile Velocity TrackingSoftware Engineering↔ compare
- Software Complexity MetricsSoftware Engineering↔ compare
- Technical Debt MeasurementSoftware Engineering↔ compare
- Use Case Point EstimationSoftware Engineering↔ compare