Metrics Minute:  IFPUG Function Points

Audio Version on SPaMCAST 145


IFPUG Function Points are a measure of the functionality delivered by the project or application being counted based on a set of rules documented in the IFPUG Counting Practices Manual. The measure of delivered functionality is a proxy for size which can be used in estimating and measuring work. An analogy for function points is the measure of the number of square feet (or square meters) of a house. Knowing the number of square feet provides one view of the house but not other attributes such as price and number of bedrooms.Knowledge of functional size is a step in understanding development and / or maintenance effort.


Denominator: Size is a descriptor that is generally used to add interpretive information to other attributes or as a tool to normalize other attributes. When used to normalize other measures or attributes, size is usually used as a denominator. Effort per function point is an example of using function points as denominator.

Estimation: Size is a partial predictor of effort or duration. Estimating projects is an important use of software size. Effort can be thought of as a function of size, behavior and technical complexity.

Reporting: Many measures and metrics are collected and used in most organizations to paint a picture of project performance, progress or success. Organizational report cards may also be leveraged, again with many individual metrics, any one of which may be difficult to compare individually.  Use function points as a denominator to synchronize many disparate measures so that they may be compared and reported.

Control: Understanding performance allows project managers, team leaders and project team members to understand where they are in an overall project or piece of work and therefore take action to change the trajectory of the work. Knowledge allows the organization to control the flow of work in order to influence the delivery of functionality and value in a predictable and controlled manner.

IFPUG Function Point Overview:

IFPUG Function Points are determined by classifying functionality found in an application into five categories. Three that relate to transactions and two that relate to data. All applications, whether they are performing a standard business function (like human resources or accounting) or are an embedded system have the same five components.

IFPUG function points classify whole transactions (elementary processes) into three categories. The first is an external input.  An external input brings information into the application and then stores that information in logical groups of data called internal logical files. External outputs and external inquiries are the second and third types of transactions. Both of these types of transactions transport information out of the application. The difference between the two types of transactions is that external output requires more processing logic than direct retrieval which is reflective of an external inquiry. Each transaction has a prescribed weight based on a low, average, high scale. Placement of an individual transaction on the scale is determined by counting the number of fields and logical files required to generate the transaction.

Data is classified into two categories, internal logical files and external interface files. Both groupings of data are user recognizable entities that represent holistic business concepts, such as customer and order. The primary difference between the two categories is that an internal logical file is maintained within the application being counted and an external interface file is maintained elsewhere. Each holistic grouping of data can be comprised of more than one subgroup. For example in the logical group customer, customer name and demographics might be one subgroup and customer address a second logical subgroup. The number of subgroups and fields are used to determine the weighting based on a similar low, average, high scale as mentioned earlier.

A function point count for a project will identify and size all logical files and transactions that have been added, changed or deleted and any required conversion functionality.  A count of an application identifies and sizes all functionality that existed within the boundary of the application when the count was done. Determining the unadjusted function point count begins by the summing components categorized into buckets using the low, average, high scale noted earlier by component type.  The IFPUG methodology provides weights for each of the buckets which are then summed to the unadjusted function point count. Optionally the count can be adjusted by applying a correction factor called the value adjustment factor. The value adjustment factor is determined by rating 14 general system characteristics on a scale of zero to five. The general system characteristics rate characteristics from ranging for data communications to the ability of the users being able to change the system. This is sometimes wrongly thought of as complexity. I would suggest that the value adjustment factor is a reflection of nonfunctional requirements for the application. Reviewing the original documentation defining function points reveals that the general system characteristics and value adjustment factor was originally created to adjust between online and batch applications.  This portion of the methodology is currently defined as optional. Once calculated the value adjustment factor is multiplied by the unadjusted function point count to create the adjusted function point count.  The value adjustment factor can adjust a function point count by plus or minus 35%, ranging from .65 to 1.35 (general business applications are around 1).

The IFPUG methodology provides a set of formulas for an application count, an enhancement project count and a development project count.  The formulas are used to determine the count.  The type of count does not change the rules for determining the components or their weight.


Counting function points takes effort. The activity of function point counting requires some degree of expertise and effort both from the counter and the subject matter experts that are required to describe the application or project. The effort is inversely proportional to the quality of the project document or application documentation. Integrating the counting process into the project activities like analysis or design reviews minimizes the extra effort and maximizes the value of the process by shining a light on what is being built and how the work is being done.

Function points count functionality delivered, not complexity. Size is related to complexity; however technical complexity is driven by many other factors other than size. Factors influencing technical complexity can include algorithms, math and complexity of the data, reuse and other constraints. The lack of a direct and complete linkage between size and complexity causes complaints such as size and effort seem disconnected. Adjusting for complexity in estimation or measurement analysis requires a separate step to measure technical complexity.

Related Measures:

  • COSMIC Function Points
  • Mark II Function Points
  • NESMA Function Points
  • Use Case Points


Function points do not measure everything required to understand the effort required to maintain or build software. IFPUG Function Points measure functional size and nothing else. Projects and applications can involve significant amounts of non-functional and technical requirements which do not register on the function point scale. The same criticism can be leveled in terms of the understanding of performance and the analysis of results. This criticism is valid. In order to create a full measurement profile of any project or application a larger pallet of metrics is needed, size is the foundation. Estimation tools generally provide a mechanism for adjusting other attributes such as nonfunctional requirements or technical complexity. Measurement programs must include a pallet of metrics to fully describe performance because size is only a single attribute albeit important.

Function points were defined in 1979, some of the words used to describe the methodology have not aged well. This criticism is true but somewhat disingenuous because all methods that have longevity will have this problem. Terms like “file” are not as ubiquitous as they once were; however, the concept of a logical group of data is just as valid today as it was in 1979. Finding the translation path between the words in the methodology and any specific platform or technology is a task that all counters must perform (it is also why the Counting Practice Manual is much larger than the 38 pages of rules that define IFPUG Function Points). The process of translation between the methodology and new platforms and technologies is a step that will be required for all sizing techniques if they stand the test of time and are used more than a few years and outside of the single technology area.

A final criticism is that training and expertise is required for function point analysis that is outside of the normal training required for analysis, design, coding or testing.  Again, this criticism is true but again not outside of the ordinary specialization found in information technology. Training and expertise is required to ensure consistency. IFPUG provides a test driven certification program as a marker to ensure consistency to the IFPUG Function Point rules (Certified Function Point Specialist or CFPS).