Function point¶

A standardized unit estimating software functional size from user-visible inputs, outputs, inquiries, data groups and interfaces.

Version: v2 · 2026-09-19 · History
Domain-specific #: 4640
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Software Measurement → Computer Science & Software Engineering
Aliases: Function point analysis, FPA

Core Idea¶

IFPUG, COSMIC, Mk II, NESMA and FiSMA methods count different functional components and complexity weights; function points measure delivered functionality, not source lines or effort directly. Analysts define an application boundary, inventory externally meaningful transactions and data functions, classify or weight them under a counting standard and sum adjusted or unadjusted points for benchmarking. The abstraction is therefore identified by a declared carrier, a transformation or constraint over that carrier, and an invariant that tells an analyst whether the named structure is genuinely present.

How would you explain it like I'm…

Counting What It Does

Instead of measuring a toy robot by how many screws it has, you could count how many things it can do for you: walk, talk, light up. Function points count how many useful things a computer program does for the people using it. It's not about how long the program's instructions are.

Software Usefulness Points

Function points measure how much useful work a piece of software gives its users. Instead of counting lines of code, people draw a boundary around the program and list the things users can do with it, like entering data, getting reports, or storing information. Each item gets points depending on how complicated it is, and you add them up. There are several different counting rulebooks, so you have to say which one you used. The total helps compare projects, but it isn't the same as how much effort it took to build.

Functional Size Measurement

A function point is a unit for measuring the functionality software delivers to its users, not its source lines or the effort to build it. An analyst defines the application's boundary and the user's point of view, lists the externally meaningful transactions (like inputs, outputs, queries) and data functions (stored data groups), weights each by complexity under a counting standard, and sums the points, sometimes with adjustment factors. Several standards exist—IFPUG, COSMIC, Mk II, NESMA, FiSMA—and they count different components with different weights, so numbers from different methods aren't directly comparable. A proper count states the standard and version and acknowledges counting uncertainty. Converting points to effort estimates is a separate step that must be stated if attempted.

Function points measure delivered software functionality from the user's perspective, not source lines or effort directly. Counting proceeds by defining the application boundary and user viewpoint, inventorying externally meaningful transactions and data functions from the functional user requirements, classifying and weighting each under a counting standard, and summing unadjusted points, optionally applying adjustment factors. Standards differ: IFPUG, COSMIC, Mk II, NESMA and FiSMA count different functional components with different complexity weights, so the standard and version must be specified. A legitimate count states the boundary, standard, requirements basis, inventory, weighting rules, adjustments, total, and counting uncertainty. Any conversion to effort or cost is an additional modeling step that must also be made explicit. Totals support benchmarking and comparison, but only between counts made under compatible conventions.

Scope of Application¶

Function point belongs to software measurement and is useful where the analyst can specify the typed software measurement carrier, including objects, relations, parameters, conventions, evidence, boundaries, and comparison targets, then evaluate the software boundary and user perspective, counting standard and version, functional user requirements, transaction and data-function inventory, complexity or weighting rules, adjustment factors, total points, counting uncertainty and conversion to effort if attempted are explicit. The scope is broad within that domain but bounded by the need for the software boundary and user perspective, counting standard and version, functional user requirements, transaction and data-function inventory, complexity or weighting rules, adjustment factors, total points, counting uncertainty and conversion to effort if attempted are explicit.

Clarity¶

The abstraction clarifies a crowded vocabulary by making the software boundary and user perspective, counting standard and version, functional user requirements, transaction and data-function inventory, complexity or weighting rules, adjustment factors, total points, counting uncertainty and conversion to effort if attempted are explicit the center of the account. A claim should name the carrier, the governing operation or relation, the applicable assumptions, and the recognition test.

Manages Complexity¶

Without the abstraction, an analyst must reason directly over many local details: the carrier roles, admissibility assumptions, competing conventions, derived invariants, boundary cases, and proof or validation obligations specific to Function point. Function point compresses them into the roles in the structural signature. That compression permits comparison across instances without erasing the variables that determine validity. It also exposes which details may be varied safely and which are constitutive.

Abstract Reasoning¶

Identify the carrier. State what the elements, states, objects, or observations are: the typed software measurement carrier, including objects, relations, parameters, conventions, evidence, boundaries, and comparison targets. Reject examples whose alleged carrier belongs to a different problem.
Lock the constitutive rule. Express the software boundary and user perspective, counting standard and version, functional user requirements, transaction and data-function inventory, complexity or weighting rules, adjustment factors, total points, counting uncertainty and conversion to effort if attempted are explicit independently of one notation or implementation.

Knowledge Transfer¶

Knowledge transfers strongly among subfields of software measurement because they reuse the typed software measurement carrier, including objects, relations, parameters, conventions, evidence, boundaries, and comparison targets, Analysts define an application boundary, inventory externally meaningful transactions and data functions, classify or weight them under a counting standard and sum adjusted or unadjusted points for benchmarking., and type the carrier, state every parameter and convention in the definition, test that the software boundary and user perspective, counting standard and version, functional user requirements, transaction and data-function inventory, complexity or weighting rules, adjustment factors, total points, counting uncertainty and conversion to effort if attempted are explicit, compare the nearest accepted identity, and report counterexamples, uncertainty, and limiting cases.

Relationships to Other Abstractions¶

Current abstraction Function point Domain-specific

Parents (1) — outgoing typed relations

Function point is a kind of Measurement Prime

It remains its own entry because its identity is fixed by the software boundary and user perspective, counting standard and version, functional user requirements, transaction and data-function inventory, complexity or weighting rules, adjustment factors, total points, counting uncertainty and conversion to effort if attempted.

Hierarchy path (1) — routes to 1 parentless root

Function point → is a kind of Measurement

Neighborhood in Abstraction Space¶

Function point sits in a crowded region of the domain-specific corpus (17^th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Software Architecture & Modeling Methods (23 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25