Measuring software by lines of code is like measuring a building by the number of bricks used: the figure tells you more about the construction technique than about the building. Functional Size Measurement (FSM) solves exactly this problem by shifting the point of observation away from implementation and onto the Functional User Requirements.
Two methods dominate industrial practice: IFPUG Function Point Analysis and COSMIC. Both are full ISO standards. Yet they do not measure quite the same thing, and choosing between them is not a neutral decision. This article covers their counting mechanics, their normative grounding, and applies both to a single banking scope to show the gap in concrete terms.
1. The governing framework: the ISO/IEC 14143 family
Before comparing methods, one has to understand the standard that defines what an FSM method is. The ISO/IEC 14143 series measures nothing itself: it establishes the meta-framework that any candidate method must conform to.
| Part | Scope |
|---|---|
| ISO/IEC 14143-1:2007 | Definition of FSM fundamental concepts |
| ISO/IEC 14143-2 | Conformity evaluation of measurement methods |
| ISO/IEC 14143-3 | Verification of FSM methods |
| ISO/IEC 14143-4 | Reference model |
| ISO/IEC 14143-5 | Determination of functional domains |
| ISO/IEC 14143-6:2012 | Guide for use of the series and related standards |
Part 1 introduces two structuring concepts. FUR (Functional User Requirements) are the requirements describing what the software must do for the user, independently of how it does it — quality, performance and technology requirements are explicitly excluded. The BFC (Base Functional Component) is the elementary unit of FUR that a given method identifies and counts. This is where methods diverge: each defines its own BFCs.
A frequently misunderstood point: ISO/IEC 14143-1 prescribes no counting rules and recommends no method. It serves as a conformity test. That is why several competing ISO standards coexist for the same object.
The five ISO-standardised FSM methods
| Standard | Method | Status |
|---|---|---|
| ISO/IEC 20926:2009 | IFPUG FSM Method | Very widely deployed |
| ISO/IEC 19761:2011 | COSMIC | Steady growth, strong in embedded and real-time |
| ISO/IEC 20968:2002 | Mk II Function Point Analysis | Residual use, mainly UK |
| ISO/IEC 24570 | NESMA FPA v2.1 | IFPUG-compatible variant, Dutch origin |
| ISO/IEC 29881 | FiSMA 1.1 | Finnish origin, limited diffusion |
Alongside these five sits ISO/IEC 19515 (OMG Automated Function Points), which specifies an automatable count derived from source code, aligned with IFPUG rules. It is not an FSM method in the 14143 sense but an automation specification.
2. IFPUG Function Point Analysis — ISO/IEC 20926
The method traces back to Allan Albrecht’s work at IBM in the late 1970s. The International Function Point Users Group, founded in 1986, has maintained it since. ISO standardisation happened in two stages: ISO/IEC 20926:2003 covered version 4.1; the second edition, ISO/IEC 20926:2009, cancels and replaces it.
A practical caveat: the ISO standard covers only the unadjusted count. The Counting Practices Manual (CPM), currently at release 4.3.1, reproduces the normative content and supplements it with detailed rules and worked examples. The CPM is what practitioners actually use, and it underpins the CFPS certification.
Five component types
Data functions — what the system stores:
- ILF (Internal Logical File): a logically related group of data maintained inside the application boundary.
- EIF (External Interface File): a group of data referenced by the application but maintained by another application.
Transactional functions — what the system does:
- EI (External Input): processing of incoming data that maintains an ILF or alters system behaviour.
- EO (External Output): data sent outside the boundary involving additional processing logic — calculation, derivation, data creation.
- EQ (External Inquiry): data retrieval sent outside the boundary without processing logic and without maintaining an ILF.
The EO/EQ distinction is the single most common source of error among newcomers. The discriminating criterion is the presence of derived data or a state change.
Complexity weighting
Each component is rated low / average / high by cross-referencing DETs (unique user-recognisable fields), RETs (subgroups within a logical file) and FTRs (logical files referenced by a transaction). The grid is fixed:
| Function type | Low | Average | High |
|---|---|---|---|
| ILF | 7 | 10 | 15 |
| EIF | 5 | 7 | 10 |
| EI | 3 | 4 | 6 |
| EO | 4 | 5 | 7 |
| EQ | 3 | 4 | 6 |
The sum of the weights yields the UFP (Unadjusted Function Points) — the only quantity covered by ISO/IEC 20926.
The VAF: a legacy to drop
The historical model applied a Value Adjustment Factor, derived from 14 general system characteristics, varying the total within a ±35% range. That factor blends functional size with non-functional characteristics, contradicting the very definition of FSM. It is excluded from the ISO standard and considered obsolete.
To cover the non-functional dimension, IFPUG developed a separate instrument: SNAP (Software Non-functional Assessment Process), whose Assessment Practices Manual is at version 2.4. SNAP produces SNAP points, counted separately from function points — the two must never be added together.
Structural limitations
The weighting scale is capped. An ILF with 200 DETs and one with 20 DETs both score 15 points once past the high-complexity threshold. This compression penalises algorithmically dense software. Beyond that, the model was designed for business systems, where most of the value lies in manipulating logical files — an assumption that transfers poorly to real-time and embedded software.
3. COSMIC — ISO/IEC 19761
COSMIC — Common Software Measurement International Consortium — emerged in the late 1990s from an international effort explicitly designed to move past the limits of so-called “first-generation” methods. It was standardised as ISO/IEC 19761:2003 (then called COSMIC-FFP), and revised as ISO/IEC 19761:2011. The Measurement Manual is at version 5.0, published in separate parts. A notable difference: this manual is freely downloadable, whereas the IFPUG CPM is a paid product.
A single BFC: the data movement
Where IFPUG counts five weighted component types, COSMIC recognises exactly one: the data movement. The underlying principle is that a functional process reduces to a set of movements of a single data group.
| Movement | Description |
|---|---|
| Entry (E) | A data group crosses the boundary from a functional user into the process |
| Exit (X) | A data group crosses the boundary from the process out to a functional user |
| Read (R) | A data group is read from persistent storage |
| Write (W) | A data group is written to persistent storage |
Each movement counts as 1 CFP (COSMIC Function Point). No weighting, no complexity grid, no ceiling.
Key concepts
- Functional user: any sender or receiver of data with respect to the software being measured. It may be a human, but equally another piece of software, a sensor, or an actuator. This generalisation is what makes the method applicable to real-time and embedded systems.
- Functional process: a set of movements triggered by a single triggering event. It always contains at least one Entry plus one Exit or Write — a floor of 2 CFP.
- Boundary: separates the measured software from its functional users.
- Layer: an architectural partition; each layer is measured separately and sizes are then summed.
- Measurement strategy: a preliminary phase fixing purpose, scope, functional users and granularity. Part 3a of the manual documents standard strategies ensuring like-for-like comparisons.
The additivity property
A direct consequence of the absence of weighting: COSMIC sizes are strictly additive. The size of a whole equals the sum of the sizes of its parts, and the size of a change equals the sum of movements added, modified and deleted. This considerably simplifies incremental measurement and agile project tracking.
4. Structured comparison
| Criterion | IFPUG (ISO/IEC 20926) | COSMIC (ISO/IEC 19761) |
|---|---|---|
| Generation | First | Second |
| Unit | UFP | CFP |
| BFC types | 5 (ILF, EIF, EI, EO, EQ) | 1 (data movement, 4 subtypes) |
| Weighting | Fixed low / average / high grid | None — 1 movement = 1 CFP |
| Scale ceiling | Yes (15 max for an ILF) | No |
| Additivity | Imperfect | Strict |
| User | Primarily human | Human, software, sensor, actuator |
| Preferred domains | Business systems, enterprise IS | Real-time, embedded, middleware, mobile, IS |
| Reference manual | CPM 4.3.1 (paid) | Measurement Manual v5.0 (free) |
| Certification | CFPS / CFPP | COSMIC certification (Parts 1 and 2) |
| Non-functional | SNAP APM 2.4, counted separately | Out of scope by design |
| Historical data | Very large (ISBSG) | More recent but growing |
5. Banking case study: a consumer credit origination module
Nothing beats a real scope measured twice. Take a consumer credit origination module, made up of application capture, a scoring engine, offer generation and fund release. We measure it first with IFPUG, then with COSMIC.
Scope and boundary. The module interacts with the customer master data (CRM), maintained by another application, with the payment incident register, and with the payment system that executes transfers. All three sit outside the boundary.
5.1 IFPUG count
Data functions
| Component | Type | Complexity | Weight |
|---|---|---|---|
| Credit application file | ILF | High | 15 |
| Decision and scoring history | ILF | Average | 10 |
| Rate schedule | ILF | Low | 7 |
| Customer master data (CRM) | EIF | Average | 7 |
| Payment incident register | EIF | Low | 5 |
| Data subtotal | 44 | ||
Transactional functions
| Component | Type | Complexity | Weight |
|---|---|---|---|
| Create or amend a credit application | EI | High | 6 |
| Upload a supporting document | EI | Low | 3 |
| Record an override decision | EI | Average | 4 |
| Instruct fund release | EI | Average | 4 |
| Generate the loan offer (APR, schedule) | EO | High | 7 |
| Return the score and rejection reasons | EO | Average | 5 |
| Monthly production report | EO | Average | 5 |
| View an application status | EQ | Low | 3 |
| Search applications by customer | EQ | Average | 4 |
| View the current rate schedule | EQ | Low | 3 |
| Transaction subtotal | 44 | ||
Functional size: 44 + 44 = 88 UFP.
Note how the three outputs are classified. Generating the loan offer is an EO rather than an EQ because it computes the APR and produces the repayment schedule: derived data is created. Viewing the rate schedule, by contrast, is a plain EQ — it retrieves without calculating. That is precisely the boundary discussed earlier.
5.2 COSMIC count of the same scope
The functional users here are the relationship manager, the CRM, the incident register and the payment system. Each functional process decomposes into movements.
| Functional process | E | X | R | W | CFP |
|---|---|---|---|---|---|
| Create a credit application | 1 | 1 | 2 | 1 | 5 |
| Amend an application | 1 | 1 | 1 | 1 | 4 |
| Upload a supporting document | 1 | 1 | 0 | 1 | 3 |
| Compute the score | 1 | 1 | 3 | 1 | 6 |
| Record an override decision | 1 | 1 | 1 | 1 | 4 |
| Generate the loan offer | 1 | 1 | 3 | 1 | 6 |
| View an application status | 1 | 1 | 1 | 0 | 3 |
| Search applications by customer | 1 | 1 | 1 | 0 | 3 |
| View the current rate schedule | 1 | 1 | 1 | 0 | 3 |
| Instruct fund release | 1 | 1 | 1 | 1 | 4 |
| Return rejection reasons | 1 | 1 | 1 | 0 | 3 |
| Produce the monthly report | 1 | 1 | 2 | 0 | 4 |
| Total | 48 CFP | ||||
Fund release illustrates what COSMIC adds: the Exit to the payment system counts as a movement in its own right, because that system is a functional user just as a human would be. IFPUG folds it into an EI without distinguishing the recipient.
5.3 What the gap tells us
On this scope, 88 UFP correspond to 48 CFP — a ratio of roughly 1.8. That ratio does not transfer. It depends entirely on the structure of the software measured: a module rich in logical files and thin on interactions pushes the ratio up, a heavily transactional one pushes it down. The conversion formulas circulating in the literature give acceptable results on conventional business systems and degrade markedly elsewhere. A conversion is never a measurement: if the result will underpin a contractual commitment, recount.
5.4 From count to effort estimate
Functional size is not an estimate: it is an input. To obtain an effort figure, combine it with a productivity ratio drawn from the organisation’s own history. If the bank historically observes 1.4 person-days per function point on this type of development, the initial estimate lands at 88 × 1.4 ≈ 123 person-days.
Three caveats attach to that figure. The productivity ratio must come from comparable projects in technology, team and domain — a ratio borrowed from another organisation has no predictive value. Non-functional requirements (availability, regulatory compliance, security, performance under load) are not in the 88 UFP; in a banking context, where compliance weighs heavily, they are assessed separately, via SNAP or an internal model. And the figure is a negotiation baseline, not a commitment: it is best expressed as a range and revised at each increment.
6. Selection criteria
Choose IFPUG when:
- the scope is a conventional business information system;
- the organisation already holds productivity history expressed in function points;
- contractual or regulatory context requires it — several public procurement bodies explicitly reference IFPUG;
- access to a pool of CFPS-certified counters is decisive;
- estimation relies on mature external benchmarks such as ISBSG.
Choose COSMIC when:
- the software is real-time, embedded, or has no direct human user;
- the architecture is heavily distributed or multi-layered;
- the approach is incremental and strict additivity is a prerequisite;
- the objective is measuring evolutive maintenance, counting impacted movements;
- the setup budget is constrained — the manual is free and the learning curve shorter.
In either case, some non-negotiable principles. Never mix units: a portfolio measured partly in UFP and partly in CFP produces no usable data. Document the measurement strategy — scope, boundary, functional users, granularity — without which a measurement is neither reproducible nor auditable. Separate functional from non-functional. And measure early: a measurement produced at project end has no decision-support value left.
Conclusion
IFPUG and COSMIC are not in opposition: they answer adjacent questions from distinct conceptual models. IFPUG brings historical depth, a mature ecosystem and solid contractual grounding in the business-systems world. COSMIC brings a simpler, more general and mathematically better-formed model, particularly suited to modern architectures and to software with no human user.
The ISO/IEC 14143 framework guarantees that both genuinely measure functional size in the normative sense. The rest — method choice, rigour of the measurement strategy, consistency over time — is a matter of organisational discipline. And it is that discipline, far more than the choice of method, that determines the real value of a measurement programme.
Normative references
- ISO/IEC 14143-1:2007 — Functional size measurement — Part 1: Definition of concepts
- ISO/IEC 14143-6:2012 — Part 6: Guide for use of the ISO/IEC 14143 series
- ISO/IEC 20926:2009 — IFPUG functional size measurement method 2009
- ISO/IEC 19761:2011 — COSMIC: a functional size measurement method
- ISO/IEC 20968:2002 — Mk II Function Point Analysis
- ISO/IEC 24570 — NESMA functional size measurement method v2.1
- ISO/IEC 29881 — FiSMA 1.1 functional size measurement method
- ISO/IEC 19515 — OMG Automated Function Points (AFP) 1.0
- IFPUG — Function Point Counting Practices Manual, release 4.3.1
- IFPUG — SNAP Assessment Practices Manual, release 2.4
- COSMIC — Measurement Manual for ISO 19761, version 5.0 (Parts 1, 2 and 3a)
Leave a Reply