Introduction to COSMIC Function Points

Home » Introduction to COSMIC Function Points


COSMIC function points are the unit of measure of software functional size.  The process of measuring software size is called functional size measurement (FSM).  COSMIC functional size measurement is applicable to business, real-time and infrastructure software at any level of decomposition (from a whole software system down to a single re-usable component or a user story).  It is independent of the technology or processes used to develop the system.  It is an ISO standard.  It is a refined improvement over its predecessors (IFPUG and Mark II FP).  The unit of size is the COSMIC Function Point or CFP


Once you have measured (or estimated) the size in COSMIC Function Points you can then use this as the base metric to :

  • Estimate development effort
  • Estimate project duration
  • Estimate project quality achievement
  • Estimate test effort
  • Control scope creep
  • Assess the value a software asset
  • Estimate maintenance and replacement costs
  • Assess the achievement of quality (defect removal rates)
  • As the basis for fixed price contracts
  • and more..
Engineering Standard

COSMIC is an international standard for measuring software size: ISO/IEC 19761:2011.

Based on Principles

The COSMIC Function Point sizing method of measuring software requirements is based on two main principles:

1. The ‘Software Context Model’

Defines the software to be measured

  • Software is bounded by hardware and typically structured into layers.
  • The scope of any piece of software to be measured shall depend on the purpose of the measurement and shall be confined wholly within a single layer.
  • The functional users of a piece of software to be measured shall be identified from its Functional User Requirements (FUR) as the senders and/or intended recipients of data to/from the software respectively.
  • A precise COSMIC size measurement of a piece of software requires that its FUR are known at a level of granularity at which its functional processes and sub-processes may be identified.
  • An approximate COSMIC size measurement is possible if its FUR are measured at a high level of granularity by an approximation approach and scaled to the level of granularity of the functional processes.

2. The ‘Generic Software Model’

Generic concepts applicable to all software

  • A piece of software interacts with its functional users across a boundary, and with persistent storage within the boundary.
  • The FUR of a piece of software can be mapped into unique functional processes.
  • Each functional process is started by its triggering Entry data movement. The data group moved by the triggering Entry is generated by a functional user in response to a triggering event.
  • A functional process shall include at least one Entry data movement and either a Write or an Exit data movement. There is no upper limit to the number of data movements in a functional process
    Cosmic Function Points are measured using the generic software model

    The Generic Software Model

  • Each functional process consists of sub-processes, data movements (DMs) and data manipulations.
  • As an approximation for measurement purposes, the COSMIC method assumes that the functionality of any data manipulation is accounted for by the data movement with which it is associated.
  • There are four data movement types, Entry, Exit, Write and Read.
  • A data movement moves a single data group, which consists of a unique set of data attributes that describe a single object of interest.
Cosmic Function Points and the Software Context Model

Context Model


COSMIC is principle-based, so it works on any type of software.

Three Steps to Counting Cosmic Function Points

1 Measurement Strategy – Determine the purpose of the measurement as per the Software Context defined above

e.g. are we measuring an entire application or just a single component / layer.  Who are the functional users interacting with the software.

2 Determine the parameters of the ‘Generic Software Model’ from the Functional User Requirements (FUR)

  1. Triggering Events
  2. The Functional Processes
  3. Objects of Interest (and Data groups)
  4. Data movements

3. Count the Data Movements

For a new application: count the new Data movements (DMs)

For system modifications : Add the new DMs , changed DMs and removed DMs.

And that’s it, the sum of the DMs is the CFP total!

Measuring an application

Most commonly we will measure an entire application treating each layer independently, so just count up all the new functionality and you have the total size.

The Smallest Functional Process

A functional process must have at least 2 CFP: a triggering Entry and a Exit (or a Write)


Keyword Definition
Functional Process A set of data movements … for the software being measured, that is unique within those FUR and that can be defined independently of any other functional process in those FUR.

Each functional process starts processing on receipt of a data group moved by its triggering Entry data movement.

The set of all data movements of a functional process is the set that is needed to meet its FUR for all the possible responses to its triggering Entry.

Functional User the ‘senders or intended recipients of data’ (can be human or connected systems or devices such as sensors)
Functional User Requirement (FUR) Statements of functional requirements, eg. software specification or user stories.
Object of Interest any ‘thing’ (physical or conceptual) in the world of the functional user, about which the software being measured must process or store/retrieve data
Data Group consists of one or more data attributes that all describe a single object of interest
Triggering Event Each functional process is started by its triggering entry data movement. The data group moved by the triggering Entry is generated by a functional user in response to a triggering event.


Taming software requirements and bringing certainty to software development.

Interpreting software requirements