Function Point Analysis (FPA) is a method to measure the functional size of an information system. FPA measures the functional size by looking at the (functional) transactions and (logical) data files that are relevant to the user in the business.

The unit of measurement is “function points”; the functional size of an information system is expressed by a number of function points.

Function points are a good measure of the functional size of an information system; the unit of measurement “function points” can be utilized in various ways.

FPA is often used to budget a system development project. The development costs for an information system are related to its size: the bigger the system, the more expensive the development will be.
Based on experiences in earlier projects an organization knows, how many hours (on average) one needs to realize one function point: the productivity rate.
Size (number of function points) x productivity rate (hours per function point) is a basis for the project budgeting process.

FPA can be applied for development, as well as for enhancement projects.

FPA is a fast method, which does not require knowledge of computers. Assuming suitable documentation, it does not take much time to perform an FPA. It is estimated that for a system which needs one thousand development hours, An FPA can be performed in about one hour.

What does FPA offer?

“Function points” are the one and only measurement unit that offers the possibility to talk concretely and objectively about the size of an information system to be developed. A statement like “the system has a size of about 314 function points” gives more information than “it is quite a big system”.

Thanks to this, the measurement unit “function points” offers, among other things, the following opportunities:

Better and earlier project cost estimating and budgeting.
Using the functional user requirements, one determines the functional size (the number of function points) of the information system. Using practical experiences in completed projects in the past, one determines the expected productivity rate (hours per fp) for the project. By multiplying size and expected productivity rate, one gets a basis for the project budget for the system development process.

Better controlling projects.
Changes in the functional user requirements can be expressed/sized in function points, so that they are concrete, quantified and controllable.
Better communications about the system development project
If two persons carry out a function point analysis and determine a different number of function points, this is inevitably caused by a different interpretation of the functional user requirements, of the system to be build. Unclear or incomplete functional user requirements become visible when carrying out an FPA.

Measuring productivity.
The number of spent development hours, divided by the number of function points of the constructed and implemented information system, results in the project productivity rate. One may compare this with the standard productivity rate. Differences may be analyzed and may result in concrete control and improvement measures for future projects.

Measuring information system quality.
The number of errors per function point per unit of time is an indicator for the quality of an information system.

Improving the quality of the system development process.
Reducing miscommunications and introducing new control measures as a result of productivity and quality analyses improves the quality of the software development process.

What doesn’t FPA offer?

  • FPA is not a project management method
  • FPA does not automatically deliver error free project estimates; it does provide important support in the project budgeting process
  • FPA is not a project planning method.

In which phases of a project one can perform an FPA?

One can perform an FPA, as soon as the functional user requirements of the information system are known on a high level. Essential are the number of functional user transactions and the conceptual data model.

This may be the case in the Proposal/Feasibility phase, or in the Requirements/Analysis phase, but it is certainly the case in the Functional Design phase. In earlier stages of the project life cycle, one might need to perform an FPA estimate, using indicative or estimated function point counts, because all necessary information to perform a (detailed) FPA might not be available.

Which project phases may be estimated using FPA?

FPA can estimate the development effort for each phase in the system development life cycle. Indeed, based on experiences in projects in the past, one knows for each project phase how many hours per function point on an average were needed in the past to complete the phase.

For the Construction phase, FPA gives very good estimates because the activities in that phase are very concrete and relatively similar between projects.

In the operational phase of an information system, one may use FPA to estimate the operational costs of information systems: a certain number of hours per function point per year.

For what kinds of projects one may use FPA?

One may use FPA for development or for enhancement projects.

In enhancement projects, it may happen that implementing functionality demands extra technical effort, because the way the system is technically constructed makes it difficult to construct the enhancement.

However, in these cases FPA also indicates how much functionality is actually delivered. The extra needed technical modifications are taken into account by decreasing the project’s expected productivity rate (more hours per function point), compared to the standard delivery rate.