Function points

8 units, 18 lessons and 34 questions on Function points. Includes a full-length CFPS mock exam drawn in the published domain weights, marked with a per-domain breakdown. Free, and open without an account.

The exam it prepares for: IFPUG Certified Function Point Specialist (CFPS), pass 90% overall and at least 80% in each of the three sections.

What is in it

What is being measured

A size that does not change when you change language.

  • Functional size, not effort — Function points measure the functionality delivered to the user. The same requirement counts the same whether it is written in COBOL or Kotlin, which is what makes the number comparable across projects.
  • The boundary — The application boundary separates what you are counting from everything else. It is drawn from the user's point of view, not from how the code is deployed.

Data functions

What the application stores, and what it merely reads.

  • ILF and EIF — An Internal Logical File is data maintained inside the boundary. An External Interface File is data referenced by the application but maintained by another one. The test is who maintains it, not where it is stored.
  • RET and DET — A DET is a unique, user-recognisable, non-repeated field. A RET is a user-recognisable subgroup of DETs within a file. Together they place a data function on the complexity matrix.
  • The data function weights — ILF: low 7, average 10, high 15. EIF: low 5, average 7, high 10. The rating comes from the RET and DET counts on the IFPUG matrix.

Transactional functions

What crosses the boundary, and in which direction.

  • EI, EO and EQ — An External Input processes data coming in and usually maintains an ILF. An External Output sends data out and involves derived data or processing logic. An External Inquiry retrieves and presents without deriving anything.
  • FTR and DET for transactions — An FTR is a file type referenced by the transaction — read or maintained. DETs are the fields crossing the boundary. Those two numbers place the transaction on its matrix.
  • The transactional weights — EI: low 3, average 4, high 6. EO: low 4, average 5, high 7. EQ: low 3, average 4, high 6.

From count to number

Adding it up, and the adjustment that is now optional.

  • Unadjusted function points — Classify every function, rate each one low, average or high, multiply by its weight and add. That total is the UFP, and it is what ISO/IEC 20926 standardises.
  • The value adjustment factor — Fourteen general system characteristics are each rated 0 to 5. VAF = 0.65 + 0.01 × the sum, so it ranges from 0.65 to 1.35. Adjusted FP = UFP × VAF. Current practice often skips it.

Using it honestly

Where the method helps and where it is being misused.

  • Size is not effort — Effort comes from size multiplied by a productivity rate measured in your own organisation. Borrowing someone else's hours per function point is where estimates go wrong.
  • Never measure people with it — Function points per developer per month is a metric that gets what it rewards: inflated counts, split functions and no refactoring. It is a sizing method, not a performance review.
  • When something else fits better — IFPUG grew up around data-rich business applications. Real-time, embedded and heavily algorithmic software is sized more faithfully by COSMIC, which counts data movements instead.

Section 1 · Definitions

The vocabulary the CPM defines precisely, and where everyday usage differs from it. This section is marked on its own, so a weak grasp here fails the exam even with a good case study.

  • The five function types — Two data functions — Internal Logical File and External Interface File — and three transactional functions — External Input, External Output, External Inquiry. Everything counted is one of these five.
  • DETs, RETs and FTRs — A DET is a unique, user-recognisable, non-repeated field. A RET is a user-recognisable subgroup within a data function. An FTR is a file referenced by a transaction. These three drive every complexity rating.

Section 2 · Implementation

Applying the rules: boundaries, counting scope, complexity matrices and the arithmetic. Also marked on its own.

  • Boundary and counting scope — The boundary is drawn from the user's view, not the technology's. Counting scope says which functions are included in this count; the boundary says which side of the line they sit on. Both are decided before anything is counted.
  • From counts to function points — Each function gets low, average or high complexity from its matrix, and each complexity has a fixed weight — an average EI is 4, an average ILF is 10. The unadjusted total is the sum.

Section 3 · Case study

A described system to be counted end to end. Judgement about intent, not recall — and the section that most often decides the result.

  • Deciding intent in an ambiguous case — Most case-study marks turn on primary intent: is this transaction maintaining data, presenting derived data, or retrieving it? Read what the user is trying to achieve, not what the screen does mechanically.

Open the Function points course · sit the CFPS mock exam · try 10 practice questions first