IM Engineer Study Notes
← Back to list
SW Engineering & Management
#기능점수#FP#IFPUG#기능규모측정#대가산정
Last updated · 2026-10-29

Function Point (FP) Analysis

1. Overview

A. Definition

Function Points (FP) are a Functional Size Measurement (FSM) method that quantifies the amount of functionality a piece of software delivers to its users, independently of the implementation language, technology, or platform. By identifying user requirements as data functions and transaction functions and summing weighted scores for each function's complexity, it converts "the size of the work to be built" into a number before a single line of code is written.

The starting point of function points is the fundamental question of "what do we measure software size with." Traditional LOC (Lines of Code) counts the volume of finished code, but the same function written in assembly runs to thousands of lines and in a high-level language to dozens, producing the paradox that higher productivity makes the size look smaller. Moreover, code can only be counted after development is complete, which conflicts with estimation's original purpose of "predicting before kickoff." Function points resolve this paradox by shifting the basis of measurement from "code" to "functionality the user perceives." From the user's perspective, the value delivered by "register customer" or "view monthly sales" is identical regardless of implementation technology, so measuring size by function yields a technology-neutral, comparable scale.

The significance of this shift is large. Function points are not a mere estimation aid but a metaphor for treating software as a "measurable engineering object." They make it possible to compare the productivity (FP/Man-Month) or defect density (defects/FP) of two systems built in different languages or frameworks on the same yardstick, and they replace the wasteful disputes between client and vendor over "how big a project is this" with the common language of objective size. This is precisely why domestic public informatization projects adopted function points as the legal standard for cost estimation.

B. Background and Necessity

Function points were proposed in 1979 by Allan J. Albrecht of IBM. At the time, IBM had no common scale to compare the development productivity of applications built in different languages, and the contamination of LOC-based comparison by language differences was a serious problem. Albrecht devised function points from the insight that measuring "the amount of functionality delivered to the user" yields a language-independent productivity metric; subsequently, in 1986, the IFPUG (International Function Point Users Group) was formed and standardized and refined the counting rules. IFPUG's counting rules are currently maintained as the CPM (Counting Practices Manual) and have been internationally standardized as ISO/IEC 20926.

Domestically, the necessity of function points became even more prominent as budget appropriateness and procurement transparency in public software projects became central issues of audit and supervision. Past Man-Month-based cost estimation grounded itself on "how long people were committed," producing the perverse incentive and disputes where lower productivity meant higher cost. In response, the government established function-point-based estimation of development cost through the SW Project Cost Estimation Guide, creating a structure that rewards productivity gains by tying cost to the size of the deliverable (functionality). In other words, function points are both a technical measurement technique and an institutional infrastructure underpinning fair trade order.

C. Essential Properties of Function Points

For function points to serve as a good size metric, they must possess several properties, and they are indeed designed that way. First, technology independence — the object of measurement is user requirements, not implementation, so it is not swayed by language, DBMS, or architecture. Second, early applicability — measurement can begin from the analysis stage when requirements and functional specifications are organized, providing a basis at the time of procurement and contracting. Third, repeatability — because the counting rules are documented, different counters converge on similar results even when they measure independently (though this is not perfect objectivity, and variance due to counter skill does exist).

On the other hand, the limitations are clear. Because function points measure functionality visible to the user, they poorly capture non-functional requirements such as performance, security, and availability, or the internal difficulty of complex algorithms (e.g., video compression, numerical analysis). When the apparent function is a simple "single computation" but the algorithmic effort inside it is enormous, function points underestimate that effort. To fill this gap, complementary and alternative techniques such as SNAP (non-functional size measurement) and COSMIC (specialized for real-time/embedded), discussed later, have emerged.

2. The Overall Structure of FP Counting and the Measurement Procedure

Function point measurement follows a systematic procedure that identifies software functionality by dividing it into data functions and transaction functions, evaluates the complexity of each, and sums the weights. The overall structure is as follows.

flowchart TB
  FP["Function Points(FP)"] --> DF["Data Function<br/>size of data stored/maintained"]
  FP --> TF["Transaction Function<br/>size of processes handled/moved"]
  DF --> ILF["Internal Logical File(ILF)<br/>data the system maintains"]
  DF --> EIF["External Interface File(EIF)<br/>data others maintain, only referenced"]
  TF --> EI["External Input(EI)<br/>input that alters data"]
  TF --> EO["External Output(EO)<br/>processed/calculated output"]
  TF --> EQ["External Inquiry(EQ)<br/>simple retrieval/search"]
  style DF fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style TF fill:#fff3e0,stroke:#e8890c,stroke-width:2px

The five types above are the result of decomposing software along two axes: "the vessel that holds data (file)" and "the work that handles that data (transaction)." Data functions count the clusters of data the system is responsible for maintaining. If the system takes responsibility for creating, modifying, and deleting that data internally, it is an ILF; if another system maintains it and we only read it, it is an EIF. Transaction functions count the processing units that cross the boundary, distinguishing changing data as EI, processing/calculating and sending out as EO, and showing it as-is without calculation as EQ. The elegance of this classification lies in reducing the vague concept of "function" to five measurable categories.

Measurement proceeds through the following steps. The overall flow is to first decide the measurement type and boundary, then identify and classify functions, score complexity to obtain the unadjusted function points, and if necessary apply the adjustment factor to finalize.

flowchart LR
  A["decide measurement type/purpose"] --> B["set measurement Boundary"]
  B --> C["identify data/transaction functions"]
  C --> D["evaluate each function's complexity<br/>(Low/Average/High)"]
  D --> E["sum weights = unadjusted FP(UFP)"]
  E --> F["apply adjustment factor(VAF)"]
  F --> G["finalize adjusted FP(AFP)"]
  style E fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style G fill:#e6f4ea,stroke:#1e8e3e,stroke-width:2px

A. Deciding the Measurement Type and Setting the Boundary

The first step of measurement is deciding "what to measure." IFPUG distinguishes three measurement types: new development (Development), functional enhancement (Enhancement), and existing application (Application). New development counts all functions being built for the first time, enhancement counts only functions added/changed/deleted, and application counts all functions the currently operating system provides. Because the "size of the current system" is needed when assessing maintenance cost or redevelopment feasibility, application measurement is very frequently used in practice.

Next, the measurement boundary (Application Boundary) is set. The boundary is a logical line separating "the system being measured" from "its outside (users and other systems)," and function types are determined by whether data and processing cross this boundary. For example, if our system directly manages some data, it is inside the boundary as an ILF; if it only references data managed by another organization's system, it becomes an EIF outside the boundary. Because the same function can be counted as a different type depending on where the boundary is drawn, boundary setting is the most important design decision governing the measurement result. A wrong boundary causes double-counting or omission of functions, so it must be drawn consistently based on the user's perspective and the locus of business responsibility.

The practical difficulty of boundary setting stands out in microservice- and API-centric architectures. When a single business function is scattered across several services, the count of EIFs and internal calls changes depending on whether each service is viewed as an independent boundary or as a single application. In such cases, it is wise to take "the unit perceived by the user as one application" as the boundary while aligning it with the dividing lines of organizational, contractual, and operational responsibility, which reduces disputes.

B. Data Functions (ILF, EIF)

Data functions count the logical data groups the system handles. The qualifier "logical" is key here: it means counting the clusters of data perceived as a single meaningful unit from the user's perspective, not the number of physical tables. For instance, even if "customer" is split by normalization into three tables — customer-basic, customer-contact, customer-grade — to the user it is a single "customer information," so it is counted as one ILF. Thanks to this principle, function points are not swayed by physical design (level of normalization, indexing strategy).

An Internal Logical File (ILF) is a data group that the system being measured creates, modifies, deletes, and maintains on its own. "Order," "product," and "member" in an order system are representative. In contrast, an External Interface File (EIF) is a case where data maintained as an ILF by another system is only referenced (read) by our system. For example, if the order system only queries the payment system's "card issuer code" table, that is an EIF. The important point is that the same data is split into ILF and EIF according to the locus of responsibility (who maintains it). One system's ILF becomes an EIF for another system that references that data.

The complexity of a data function is determined by two indicators. DET (Data Element Type) is the number of unique fields (attributes) the user recognizes, and RET (Record Element Type) is the number of subgroups (subsets) within that data group. For example, if "customer" has two subtypes, individual-customer and corporate-customer, then RET=2. The more DETs and the more RETs, the higher the complexity, and the combination of the two determines Low/Average/High. The reason data functions are given higher weights (ILF 7–15) is the empirical rule that maintaining data entails greater effort in terms of design and integrity than simple processing.

C. Transaction Functions (EI, EO, EQ)

Transaction functions count the elementary processes that cross the boundary. An elementary process is the smallest complete activity meaningful to the user — a unit that is "business-incomplete if only partially performed." Just as "member registration" means nothing if interrupted midway, one complete piece of business is one transaction function.

An External Input (EI) is processing in which data or control information enters from outside the boundary and alters an ILF (create/modify/delete) or changes system behavior. "Register product," "cancel order," and "change password" are typical EIs. An External Output (EO) is output that sends data outside the boundary but includes calculation, processing, or derivation logic. If it creates and sends out sums, ratios, or derived values — like a "monthly sales summary" or an "income statement" — it is an EO. An External Inquiry (EQ) is processing that retrieves and displays stored data as-is without calculation. "View member detail" and "search product list" are EQs. The decisive criterion separating EO from EQ is "the presence or absence of derived data or calculation logic," and when this distinction is ambiguous, variance between counters is greatest.

The complexity of a transaction function is determined by FTR (File Type Referenced, the number of files referenced) and DET (the number of data elements involved in the processing). The more files a single process references and the more fields it handles, the higher the complexity. For example, if a "create order" EI references four ILFs — order, product, inventory, member — then FTR=4, approaching the High end. The transaction functions' lower weights relative to data functions (EI 3–6, etc.) reflect the design philosophy that maintaining data structures is a more fundamental effort than any individual piece of processing logic.

3. Complexity Evaluation and Function Point Calculation

A. The Complexity Matrix and Weights

Each identified function receives the following weight according to its complexity (Low/Average/High). This table holds values IFPUG set by regression-analyzing data from numerous projects, quantifying the empirical fact that data functions require greater effort than transaction functions, and High more than Low.

Function type Low Average High Note
ILF (Internal Logical File) 7 10 15 complexity by DET·RET
EIF (External Interface File) 5 7 10 reference-only, lower than ILF
EI (External Input) 3 4 6 determined by FTR·DET
EO (External Output) 4 5 7 includes calculation/processing
EQ (External Inquiry) 3 4 6 simple retrieval

The relative magnitude of the weights itself tells us much. An ILF's High (15) is five times an EQ's Low (3), which is the empirical rule that "a complex master responsible for managing data" requires five times the effort of "a simple inquiry screen." The counter applies this table mechanically, but because how each function is classified by complexity governs the result, consistent criteria must be maintained in assessing DET·RET·FTR.

In practice, complexity is determined by mapping a data function's DET and RET combination into a three-level complexity matrix. For instance, an ILF with 1–19 DETs and a single RET is Low, while many DETs or multiple RETs rise to Average or High. Transaction functions likewise use a combination table of FTR and DET. What matters is not memorizing the thresholds themselves but understanding the principle that "complexity is determined by two axes — the reference scope (files, records) and the volume of data elements." The same "member registration" EI becomes High if it handles dozens of fields and updates multiple files, and Low if it puts a few fields into a single file.

The reason this complexity distinction matters in practice is that a substantial share of the total function points comes from a small number of High functions. Rather than dozens of simple inquiries (EQ Low), a few core business masters (ILF High) often govern size and effort. Therefore, to raise measurement quality, it is more efficient to concentrate verification capacity on identifying and judging the high-complexity core functions than to spread equal attention across all functions.

B. Unadjusted Function Points (UFP) and the Adjustment Factor (VAF)

The sum of the weights of all identified functions is the Unadjusted Function Point (UFP). The UFP represents purely the functional size, and ISO/IEC 20926 defines precisely this UFP as the official "functional size."

The IFPUG method optionally multiplies this by the Value Adjustment Factor (VAF) to obtain the Adjusted Function Point (AFP). The VAF is calculated by rating 14 General System Characteristics (GSC) — data communications, distributed processing, performance, heavily used configuration, transaction rate, online data entry, end-user efficiency, online update, complex processing, reusability, installation ease, operational ease, multiple sites, and facilitate change — each on a 0–5 scale. The formula is VAF = 0.65 + 0.01 × ∑(14 GSC scores), so if all characteristics are average (each marginal), the VAF converges to ≈1, allowing adjustment of up to ±35%. AFP = UFP × VAF is the final function point.

However, the VAF is contentious. The 14 characteristics were created on the premise of the 1980s technology environment (mainframe, batch) and do not fit today's cloud/web environment, and there is much criticism that lumping non-functional requirements into "14" is scientifically weak. For this reason, the ISO FSM standard and Korea's SW Project Cost Estimation Guide do not use the VAF and adopt only the UFP (unadjusted function points) as size, handling non-functional elements with separate adjustment coefficients or SNAP. In a professional engineer's answer, it is important to accurately distinguish that "the VAF is merely IFPUG's optional adjustment, whereas the domestic standard is UFP-based."

C. The Standard (Detailed) Method and the Simplified Method

In practice, the way function points are counted splits into two branches according to precision and timing of measurement. The difference between the two lies in "whether each function's complexity is evaluated individually, or an average value is applied uniformly."

Category Standard (Detailed, IFPUG) method Simplified (domestic cost estimation) method
Complexity evaluation individual Low/Avg/High per function via DET·RET·FTR uniform application of average complexity weights
Precision high low (approximation)
Timing after design is somewhat concrete early, at requirements level
Effort/cost large (requires counting expertise) small (rapid)
Domestic use detailed verification/settlement standard for budgeting/procurement stage

The simplified method applies average weights per type (e.g., ILF average, EI average) without scrutinizing each function's complexity one by one. It can rapidly estimate size once only the requirements are organized, so it suits the budgeting and project procurement stage before detailed design. The reason Korea's SW Project Cost Estimation Guide adopted the simplified method as the basis for public project budgeting is precisely this early applicability. In contrast, the standard (detailed) method analyzes DET·RET·FTR for each function to judge complexity individually, so it is precise but can only be measured after the design is concrete, requiring expert personnel and time. In practice, a two-stage operation is common: estimate the budget with the simplified method at procurement, then settle and verify with the standard method after design is complete.

Let us get a feel with a simple numeric example. If a system is measured with the simplified method and, on average-weight basis, identified as 5 ILFs (avg 10) = 50, 2 EIFs (avg 7) = 14, 20 EIs (avg 4) = 80, 10 EOs (avg 5) = 50, 15 EQs (avg 4) = 60, then UFP = 50+14+80+50+60 = 254 FP. In domestic cost estimation, this 254 FP is multiplied by the per-function-point unit price (FP unit price) published annually by the Korea Software Industry Association and by various adjustment coefficients (scale, interface, performance, operating environment, etc.) to derive the development cost. Because the unit price is renewed annually to reflect price and wage changes, in an answer it is safer to state "the current year's unit price published by the association is applied" rather than asserting a specific amount.

4. Comparison and Application Cases

To understand the standing of function points, comparison with competing and alternative metrics is necessary. Versus LOC, function points' core advantages are technology independence and early applicability. LOC can only be counted accurately after development is complete and is contaminated by language and productivity, whereas FP is measured at the requirements stage independently of language. Conversely, LOC is easy to aggregate automatically and admits no counter subjectivity, whereas FP has the weakness that results can swing by around 10% depending on counter skill. So the two metrics complement each other in the form of "productivity (LOC/FP, per-language conversion coefficient)," and Capers Jones's per-language LOC/FP table is the representative conversion tool.

Versus COCOMO (an LOC-based model), function points differ in role between "size measurement" and "effort conversion." COCOMO is a model that takes size (KLOC) as input and calculates effort, whereas FP is a method of measuring size itself. In fact, COCOMO II sometimes takes FP as early-stage input and converts it to LOC (backfiring). That is, the two are combined not as competitors but as a pipeline of "measure size with FP → convert to effort with the model."

Versus COSMIC (ISO/IEC 19761), function points differ in application domain. IFPUG FP is strong for data-centric management information systems (MIS), but COSMIC, which measures size solely by data movement (Entry·Exit·Read·Write), is better suited to real-time, embedded, and control software. In communication/control systems where apparent data is scarce but internal data movement is frequent, IFPUG FP tends to underestimate size, so COSMIC is preferred.

As a concrete industrial application case, in building domestic public next-generation systems, simplified-method FP is counted against the requirements definition document (RFP) to fix the project budget, and function points are recounted at the time of design completion to quantitatively settle scope changes (increases/decreases). In the financial sector, FP-normalized indicators such as "development productivity = delivered FP / invested Man-Month" and "quality = number of defects / FP" are used as KPIs to evaluate the performance of different languages and teams on the same yardstick. In global outsourcing contracts, performance-based contracts of the "price-per-FP" type replace Man-Month-based contracts, used as an incentive structure that returns the gains of productivity improvement to the client.

5. Deep Dive — Non-functional Size Measurement and Automation Trends

Function points' most fundamental limitation lies in that they "measure only user-visible functionality." FP barely captures non-functional requirements such as performance, security, scalability, and availability, or work that requires enormous effort without a change in functionality, such as architecture transition or large-scale refactoring. To fill this gap, IFPUG released SNAP (Software Non-functional Assessment Process) in 2013. SNAP measures the non-functional requirements of four categories — data operations, interface design, technical environment, and architecture — in SP (SNAP Points), used as a separate metric complementary to function points (FP). FP measures "what it does," while SNAP measures "how, and how robustly, it does it." Recent domestic cost-estimation discussions are also examining the introduction of SNAP as a compensation system for non-functional requirements.

Automation of measurement is also an important trend. Traditional FP measurement had the chronic problem of large cost and counter variance because an expert reads the specification and counts by hand. To solve this, OMG established the Automated Function Points (AFP) standard, which automatically counts function points from source code and transaction structures, with static analysis tools reverse-extracting data functions and transactions from code to calculate FP. However, because automated measurement measures "what has been implemented," it cannot be used for early estimation at the requirements stage and cannot fully replace the counter's business judgment (elementary process identification, boundary setting).

The most recent change is AI/LLM-based size estimation. Research and tools are emerging that analyze requirements documents or user stories with natural language processing to automatically identify data and transaction functions and estimate FP, and models trained on past projects' FP-effort data are utilized to reduce estimation error. However, AI estimation carries the problems of training-data bias and explainability, so for the time being it is expected to remain in the role of assisting and verifying expert measurement. In agile environments, the relative size of story points is used instead of FP, but because organization-level budgeting and benchmarking still need the absolute scale of FP, hybrid approaches attempting mutual conversion of "story points ↔ FP" are also appearing.

6. Considerations and Implications

From a professional engineer's perspective, the strategies and implications to consider when applying and operating function points are as follows.

  • Two-stage operation of measurement timing and method: At the procurement stage, fix the budget with the simplified method, which measures rapidly from requirements alone; after design is complete, recount with the standard method to settle scope changes — this dual strategy is desirable. Early estimation has large ± error along the "cone of uncertainty," so it should not be fixed with a single measurement but refined through staged re-measurement.
  • Securing measurement consistency and governance: Because FP results swing with counter skill, boundary-setting and complexity-judgment criteria must be documented as an organizational standard, and cross-verification by a certified counter (CFPS) or a skilled practitioner must be in place to earn trust. Leaving the measurement basis (identification details, complexity judgments) traceable is key to audit and dispute response.
  • Separate compensation for non-functional and high-difficulty requirements: The performance, security, and algorithmic difficulty that FP underestimates must be complemented by SNAP or separate adjustment coefficients. In particular, for real-time, embedded, and AI systems, fixing size with IFPUG FP alone severely distorts effort, so consider the joint use of a domain-fit metric such as COSMIC.
  • Incentive design of performance-based contracts: The price-per-FP method returns the gains of productivity improvement to the client, but it also creates the perverse incentive for the vendor to "inflate FP by adding unnecessary functions." Therefore, it must be operated in combination with verification of functional necessity (scope appropriateness review) to maintain fairness.
  • Outlook and related technologies: In the long run, measurement automation (OMG AFP) and AI estimation will reduce measurement cost and variance, and in agile/DevOps environments, through conversion with story points, FP will re-establish itself as an organization-level benchmarking and portfolio management indicator. However, since automation cannot fully replace the counter's business judgment, the combination of "automated measurement + expert verification" is the realistic direction.

References

In one line: Function points (FP) are a functional size measurement method that identifies and weight-sums the functionality software delivers into data functions (ILF·EIF) and transaction functions (EI·EO·EQ) to measure size independently of implementation technology — the standard for Korea's SW project cost estimation and an engineering metric extending to non-functional (SNAP), automation (AFP), and AI estimation.