What is a COSMIC function point, and how is it different from estimating hours?
Mesterséges Intelligencia Központ Kft. is a software development company based in Budapest, Hungary. We measure software size in COSMIC function points: the size is then a property of the software, not the estimator's feeling, so it can be checked, re-measured and used to compare two offers.
In short: COSMIC (ISO/IEC 19761) measures the functional size of software: every data movement (Entry, Exit, Read, Write) is worth 1 COSMIC function point (CFP). An estimate in hours tells you how much work the estimator expects; the measured size tells you how big the task is. That makes it checkable and repeatable, and it lets you compare two offers; the effort can then be derived from the size and from productivity measured in practice.
What is functional size measurement?
Software size can be expressed in many ways: in lines of code, in hours, in points. Functional size measurement (FSM) measures what the software has to do from its users' point of view, not how it is implemented. Its core concepts are set out in ISO/IEC 14143-1:2007; according to the standard's description, the aim is precisely to shift the focus away from how the software is implemented to the functions the user requires.
The basis of the measurement is the set of Functional User Requirements (FUR): the part of the user requirements that describes which tasks and services the software has to perform. Performance, security and the chosen technology do not belong here; we cover them below, under the limits.
There are several standardised functional size measurement methods. The best known are COSMIC (ISO/IEC 19761:2011) and the IFPUG method (ISO/IEC 20926:2009); ISO has standardised other methods too (NESMA, FiSMA, Mk II). All of them work from the requirements, but with different rules and different units, so numbers measured with different methods cannot be compared directly.
What is COSMIC?
COSMIC stands for the Common Software Measurement International Consortium: a not-for-profit organisation that maintains the method and runs the certification of measurers. The method evolved in the late 1990s as a rework of earlier function point methods, became an ISO standard in 2003, and the current edition is ISO/IEC 19761:2011. The detailed description of the method, the COSMIC Measurement Manual version 5.0, can be downloaded free of charge; its first part was issued in 2021 and its second in 2024.
According to the standard, the method is suitable for measuring application software (business systems, for example), real-time software and hybrids of the two, so an ERP, CRM or webshop system can be measured with it, and so can control software.
The concepts of the COSMIC model
COSMIC describes software with a simple model: the software exchanges data with its functional users across its boundary, and within the boundary it reads from and writes to persistent storage.
| Concept | What it means | Example |
|---|---|---|
| Functional user | whoever or whatever sends data to the software or expects data from it: a person, another piece of software or a device | the clerk, the invoicing system |
| Boundary | a conceptual interface between the measured software and its functional users | the web interface and the interfaces open to other systems |
| Triggering event | an event in response to which a functional user starts a process | a new customer signs up |
| Functional process | an elementary, independently executable unit of the requirements, a cohesive set of data movements | “record a new customer” |
| Data group | a set of data attributes that describe one thing the software has to handle data about | the Customer: name, address, tax number, email |
| Data movement | the movement of a single data group; there are four types | see below |
The four data movements:
- Entry: a data group arrives from a functional user across the boundary into the process.
- Exit: a data group goes from the process across the boundary to a functional user.
- Read: the process reads a data group from persistent storage.
- Write: the process writes a data group to persistent storage; deleting also counts as a Write.
A few of the measurement rules that determine the count:
- Every data movement is 1 CFP. The size of a functional process is the sum of its data movements, and the size of the software is the sum of the sizes of its processes.
- Every functional process has at least two data movements: a triggering Entry and at least one Exit or Write.
- Within a process, one type of movement of the same data group counts only once, however many fields it has.
- All error and confirmation messages of a process together count as a single Exit.
- Size depends on types, not occurrences: whether ten or ten thousand customers are recorded a day makes no difference to the size.
- The method does not measure data processing (calculation, validation) separately: it is part of the data movement concerned.
The result is on a ratio scale, which means sizes can be added up and compared: two parts of 40 CFP make 80 CFP together, and subtotals can be shown per group of functions.
A worked example: “record a new customer”
Take a simple requirement: “The clerk records the details of a new customer (name, address, tax number, email). The system checks that the customer is not already registered, saves the record and reports success or an error.” The measurement steps:
- The functional user is the clerk, and the triggering event is that a new customer signs up.
- The data group is the Customer; the four attributes describe the same thing, so they form one group.
- The data movements are identified from the sentences of the requirement, and each one is counted.
| Step | Data movement | Data group | Size |
|---|---|---|---|
| The clerk submits the form | Entry | Customer | 1 CFP |
| The system checks whether the customer already exists | Read | Customer | 1 CFP |
| The system saves the new customer | Write | Customer | 1 CFP |
| Feedback on success or any error | Exit | error and confirmation message | 1 CFP |
| Total | four data movements | one data group | 4 CFP |
The “create employee” example in the guide published on the COSMIC website is built the same way. Changes to the requirement show up in the size like this:
- If the system also has to pass the new customer to the invoicing system, that is another Exit to another functional user: 5 CFP.
- If the postcode has to be checked against a table of towns, that is another Read, because it concerns a different data group: another 1 CFP.
- If the form asks for twelve fields about the customer instead of four, the size does not change, because the data group is the same.
- If an existing process has to be changed, the size of the change is the sum of the added, modified and deleted data movements.
The example also shows why the measurement can be checked: behind every CFP there is a named requirement, a data group and a rule. If someone disputes it, you can point to exactly which row is in question.
Measure early, refine later
A COSMIC measurement starts by fixing the purpose and scope of the measurement: what we measure, what is included and what the result will be used for. An exact measurement needs requirements detailed enough to identify the functional processes and their data movements. At the start of a project these often do not exist yet; for this case COSMIC publishes approximation techniques for early sizing, and once the requirements have been worked out, the exact measurement can follow.
The method's guidelines also warn that many requirements that first look non-functional (response time or ease of use, for example) turn into software functions as the project progresses, which makes the size appear to grow. This is not a flaw in the measurement; it shows that the requirement has become more precise. In practice it is therefore worth writing the specification item by item, re-measuring changes with the same method and showing the size of each change separately. That way scope growth does not happen silently but can be seen in numbers.
Comparison: hours, story points, IFPUG and COSMIC
| Aspect | Estimate in hours | Story points | IFPUG function points | COSMIC function points |
|---|---|---|---|---|
| What it expresses | the work the estimator expects | the team's relative estimate; it is not always clear whether of size, effort or time | functional size | functional size |
| Standardised | no | no | yes, ISO/IEC 20926:2009 | yes, ISO/IEC 19761:2011 |
| What it depends on | the estimator's experience, caution and team | the particular team; it means something different in each team | the requirements | the requirements |
| Can outsiders check it | only from the estimator's explanation | hardly, outside the team | yes, by published rules | yes, by published rules that are freely available |
| Unit | hour | the team's own point | IFPUG function point | CFP, 1 CFP = 1 data movement |
| Best suited for | planning short, well-understood tasks | the team's own sprint planning | measuring size, comparison | measuring size, comparison, a basis for offers and schedules |
An estimate in hours is not a bad tool; it simply measures something else: the expected work, which depends not only on the size of the task but also on the team's skills, tools and caution. Story points are useful for planning within a team, but according to the guide published on the COSMIC website they are subjective and their meaning varies from team to team. IFPUG and COSMIC are both standard functional sizes, but with different rules, so the numbers of the two methods are not interchangeable.
Why is measured size a more reliable basis?
To answer the question in the title precisely: COSMIC does not estimate hours more accurately; it measures how big the task is, and that makes the effort estimate more reliable. The reasons:
- It measures the requirement, not the implementation. Functional size follows from the requirements alone, so it is independent of the technology, the process and who develops the software.
- It can be re-measured by published rules. The rules are public and the measurement result has to be documented, so another measurer can check it from the same specification.
- Size and productivity are kept apart. The effort estimate follows from the size and a productivity figure measured in practice (effort = size / productivity). That shows which factor changes and why.
- Measuring improves the requirements. According to the COSMIC guide, early measurement helps identify ambiguous, inconsistent or missing requirements.
- It is comparable. Two offers for the same specification get the same size, so the prices refer to the same scope.
The COSMIC guide refers to several studies in which size measured in CFP tracked actual effort more closely than estimates in story points. The same guide also warns that an effort estimate derived from size is reliable when the development process is reasonably repeatable and effort is driven mainly by size. Measured size is therefore a better starting point, but a good estimate also requires knowing the productivity.
What does COSMIC not measure?
COSMIC size measures functions, and the method's description says so openly. What it does not express:
- Complex algorithms. According to the standard, the method was not designed to measure software characterised by complex mathematical algorithms or specialised and complex rules (for example expert systems, simulation, self-learning software, weather forecasting).
- Processing of continuous signals. Audio and image processing, and such parts of computer games, for example, are also outside the scope of the standard.
- True non-functional requirements. Under the method, technology, performance and project constraints should be recorded, but they are not measured in CFP.
- Creative work. According to the COSMIC guide, purely creative tasks, such as producing artistic works, are not what the method sizes; the work of graphics and custom visual design is therefore not expressed by the size.
- Implementing a ready-made package. If the requirements are largely covered by configuring an existing product, it is better to estimate the effort in a way specific to that package.
That is why a good offer shows separately, alongside the measured size, what the size does not express: integrations, non-functional requirements, a custom interface and graphics, several platforms, data migration, complex computation and real-time behaviour. Our offers list these items this way, and our Pricing page explains how.
How do we use it in our own work?
We measure the functional size of a development in COSMIC function points. For the measurement we built our own AI-assisted workflow, and a person checks the result in a review round. The steps:
- Itemised specification: we break the development down into groups of functions and describe each with the same template: goal, actors, data, functions, AI functions and what is out of scope (see How we work).
- Several independent counts: several language models count every group of functions several times; the spread of the counts shows the uncertainty.
- Reconciliation round: it ensures that every functional process counts exactly once, even if it appears in several descriptions.
- Review: we check the measurement, clear up uncertain points and, where needed, overrule the automatic merges by hand.
- Locking: the finished measurement can be locked as an unchangeable version, and that becomes the basis of the contract.
When an existing system is extended, the existing part is described separately, so only the new part counts towards the size. The measurement also flags what the functional size does not express.
How does size become an offer and a schedule?
The price of the offer follows from the measured size, plus the items the size does not express. Because we see the size per group of functions too, we build the schedule on it: the order of the stages, the content of the demos and the deadlines. If a new requirement comes up along the way, we measure it the same way, and you can see how much the scope changes and what that means for the price and the schedule. That is why we give a concrete price and deadline only after the measurement, not on the basis of a first conversation.
Comparing two offers by size
If you ask several developers for an offer, size helps you decide whether they are quoting for the same task. A good way to go about it:
- The same specification: every bidder receives the same itemised description.
- The size and the list of processes: ask what size and which functional processes the price was given for.
- The reasons for differences: if two offers differ, check whether they differ in size, in the items the size does not express, or in the price per unit of size.
- Separate items: ask what is listed as a separate line (integration, data migration, operation) and what the price does not include.
- Handling changes: ask how changes made along the way are measured and priced.
If a bidder does not measure functional size, its offer can still be compared if it priced the same itemised list of processes. We cover the other aspects of choosing a developer in How to choose a software development company; and whether you need custom development at all is the subject of Custom software or an off-the-shelf solution?.
Frequently asked questions
What is a COSMIC function point?
A COSMIC function point (CFP) is the unit of the functional size of software under ISO/IEC 19761. One CFP is one data movement: an Entry, Exit, Read or Write of a data group in a functional process. The size of the software is the sum of the data movements of its processes.
How does it differ from an estimate in hours?
An estimate in hours states the expected work, and it depends on the estimator and the team. COSMIC measures the size of the task from the requirements, using published rules, so someone else can reach the same result from the same specification. The hours can then be derived from the size and from productivity measured in practice.
What does COSMIC not measure?
According to the standard, it was not designed to measure complex mathematical algorithms or the processing of continuous signals (audio, images), and it does not express true non-functional requirements, such as performance or technology constraints, in CFP either. A good offer shows these as separate items.
Who measures it, and can the measurement be checked?
The measurement is done by a measurer who knows the method; in our case an AI-assisted workflow does the counting and a person reviews the result. The rules are public and the measurement is documented process by process, so another specialist who knows the method can check it from the same specification.
How does size become an offer?
The price follows from the measured size, plus what the size does not express: integrations, non-functional requirements, custom graphics, several platforms, data migration. The schedule is built on the size per group of functions, and we measure changes the same way. The details are on our Pricing page.
How we can help
If you are planning custom software, we write the itemised specification together, measure its size in COSMIC function points and base the offer and the schedule on it. We sign a non-disclosure agreement (NDA) on request, and after handover we also take on operation and maintenance. The contract governs source code and usage rights. The first consultation is free: write to us using the details on the Contact page.
Sources
- COSMIC: Measurement Manual v5.0, Part 1: Principles, Definitions and Rules (PDF)
- COSMIC: Measurement Manual v5.0, Part 2: Guidelines (PDF)
- COSMIC: A Guide to Software Size Measurement (PDF)
- COSMIC Measurement Manual: downloads
- ISO: ISO/IEC 19761:2011 (COSMIC: a functional size measurement method)
- ISO: ISO/IEC 14143-1:2007 (Functional size measurement, Part 1: Definition of concepts)
- ISO: ISO/IEC 20926:2009 (IFPUG functional size measurement method)