Skip to content
Integronauts
← Tools
Integration & APIs

Function Point estimator

IFPUG function point counting, with the five components restated for integration rather than for screens — and every step of the arithmetic shown.

IFPUG counting was designed for transactional applications, so the five components are restated below in integration terms. The arithmetic is unchanged — the value of Function Points is that two people can disagree about a count and still agree about the method.

Inbound messages processed

External Input · 3/4/6

24

Each distinct inbound transaction the interface accepts and acts on — an inbound 850, a REST POST, a file drop that updates something.

Outbound messages produced

External Output · 4/5/7

21

Each distinct message sent out that involves derivation — a transformed 810, an enriched event, a calculated summary.

Synchronous lookups

External Inquiry · 3/4/6

10

Request–reply calls that retrieve without changing anything — a stock check, a status enquiry, a validation call.

Internal stores maintained

Internal Logical File · 7/10/15

17

Data the integration layer itself owns — staging tables, correlation stores, cross-reference tables, audit stores.

External data referenced

External Interface File · 5/7/10

17

Data owned elsewhere but read by this interface — a partner catalogue, an ERP master table, a reference feed.

General system characteristics — rate 0 to 5

4

How many protocols and how much of it is real-time rather than batch.

3

Work spread across systems, regions or tenants.

3

Whether response time or throughput is an explicit requirement with consequences.

2

Constrained infrastructure the interface must fit inside.

3

Peak volumes, and how sharp the peaks are.

1

Interactive input, error screens, human-in-the-loop steps.

1

How much the design is shaped by usability rather than throughput.

3

Updates to internal stores that must be immediate and recoverable.

4

Multi-step logic, exception handling, compensation, heavy transformation.

3

Built to be reused across interfaces rather than for one purpose.

2

Conversion, cutover and migration effort designed in.

3

Start-up, backup, recovery and monitoring done properly.

2

Multiple countries, entities or business units with local variation.

3

Designed so business rules and partners can be changed without redeploying.

9

The figure worth arguing about, so it is an input rather than a hidden constant. Low-code platforms on a mature estate sit at the bottom of this range; code-heavy work on an estate nobody has mapped sits at the top. If you have historical actuals, use those — they beat any published benchmark.

Estimate

102person-days817 hours · ≈ 5.1 person-months
Unadjusted FP
89
TDI
37 / 70
VAF
1.02
Adjusted FP
90.8
How this number was reached
  • · Unadjusted 89 FP from the component counts and standard IFPUG weights.
  • · TDI 37 of a possible 70 gives VAF 1.02 — the adjustment band is deliberately only ±35%.
  • · Adjusted 90.8 FP × 9 hours/FP = 817 hours.
  • · Hours per FP is the figure to argue about. It varies by platform, team maturity and how much of the estate is already understood — it is an input here rather than a hidden constant.
  • · This sizes build and unit test. It excludes requirements, business testing, partner certification and cutover.

This sizes one interface, or one coherent piece of work. For a whole estate, count the interfaces first — the catalogue builder does that, and the migration assessor adds platform friction on top.

Standard IFPUG weights and the fourteen general system characteristics, with the component definitions restated for integration rather than for screens and reports. Every step of the arithmetic is shown, because an estimate you cannot argue with is not an estimate — it is a number someone will hold you to. Nothing is transmitted or stored.

Other tools

These exist because the underlying problem is real. If the numbers you just put in look uncomfortable, that is usually worth a conversation.

Tell us what you're running