Demystifying Function Points

Clarifying Common Terminology

Manual (IFPUG 4.1) Glossary definition is:

Enhancement project function point count (EFP): A count that measures the modifications to the existing application that add, change, or delete user functions delivered when the project is complete. 

"Enhancement" in function point terminology strictly refers to logical, functional enhancements, i.e., only those modifications to the logical user requirements or elementary processes (EI, EO, EQ, ILF or EIF) of the software. As such, if an "enhancement project" in business terms does not create new logical functions, modify existing logical functions, or remove logical functions from the software--NO function points can be counted. What this means is that out of the previous list of enhancements in the business and IT context, potentially only the last point (adding new data elements to an existing report) would count ANY function points. This is because the remaining list items are not considered to be functional enhancements, and therefore, would score zero FP.

This can be very frustrating to the uninitiated Function Point practitioner who does not have an appreciation for the importance of the context in which the term "enhancement project" is used. Remember, enhancement project to the business/IT community is not necessarily considered to be an enhancement project when counting function points.

The term "file," when used by system developers, usually evokes images of mainframe, transaction-oriented processing, and the term is used interchangeably with "dataset." Associated terms such as "research files," "output files," "sort files," "batch files," "excel files," and "transaction files," are still common vernacular today.

In function point counting, the term "file" is used to represent a logical grouping of data that is a requirement of users. The CPM defines file as:

File: For data function types, a logically related group of data, not the physical implementation of those groups of data.

The confusion emerges because an Internal Logical File (ILF) and an External Interface File (EIF) in function point terms refers to a persistent data entity, not a physical file or dataset. As such, here are some examples of physical files/datasets in IT terminology that would not be Files (entities) in the context of function points:

  1. An input dataset could house transactions that will cause updates to master data in the application. (In FP this would count as one or more External Inputs because that is the logical user requirement. The physical housing of those processes happen to be in a dataset.) 
  2. An output file could contain the electronic version of multiple, distinct reports or groups of data (e.g., U.S. Tax Forms such as "W2s" and "1099s" could all be housed on a single, physical output tape). In FP this would be counted as several External Outputs or External Queries, depending on the specific logical process involved (one for each of the unique functional user requirements). It does not change the functional user requirements, whether there are several physical tapes, or one physical tape--as long as the users receive the functionality. 
  3. A physical restart file could contain incomplete, intermediate results and be used as input to an intermediate job step. This would be part of the physical implementation and would not be a logical user requirement; therefore, it would not count. 
  4. A table of user maintained data on regions. This would be counted as an Internal Logical File if it were part of the user requirements and maintained by the application being counted.

The key is to remember that the word "file" in function points refers to a logical grouping of related data. This does NOT conform to a "file" or physical dataset in IT terms.

SUMMARY
This list of commonly misunderstood words is

About the author

Carol Dekkers's picture
Carol Dekkers

Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.