A challenge in implementing function point analysis (FPA) is making it understandable to developers, cost analysts, and customers alike. Because function points are based on functional user requirements (what the software does), irrespective of the physical implementation (how the software is implemented), users of the method must think in terms of the logical functional requirements. This can be especially difficult for developers who spend their days focused on providing physical software solutions (involving how the software will be built).

Just as an architect begins by drawing a floor plan to meet the owners' needs, though, software project managers and developers begin by documenting the functional user requirements articulated by their customers. FPA examines these logical (also called functional) user requirements to determine the functional size of the software.

The difficulty that sometimes arises with developers is twofold:

·        A developer's job concentrates on the physical aspects of designing and implementing software, similar to how a master plumber or master electrician concentrates on the physical aspects of building a house

·        The function point analysis method itself uses terms that are well known in the information technology industry, but the meanings of particular words are different.

This article focuses on several key words that are the most problematic when introducing function points. By simply making your developers aware of these differences in meaning, you can achieve higher levels of measurement success and less resistance in FPA implementation.

All of the functions that are evaluated in function point counting are logical user functions,that is, they are part of the logical user requirements for the software. Readers who want further details about FP are encouraged to obtain the function point counting practices manual V4.1 from the International Function Point Users Group.

The following terms are used both within the function point method and in information technology. The confusion arises because their general use in information technology often conveys a different meaning from that used in function point counting:

·         Logical

·         User

·         Application (system)

·         Project

·         File

·         Enhancement

Each term (and the confusion it causes) is explained in the sections that follow.

The word "logical" in information technology is usually associated with logical database layouts or logical data models. However, in many situations, some physical considerations creep in to even the most logical of data models. When the term "logical" is used in function point counting, it refers to the conceptual or functional user requirements, and excludes physical implementation or design requirements. Logical user requirements are those requirements that an experienced user in the subject matter area would identify as requirements of the software. Logical or functional user requirements describe what the software must do and do not include how the software will do the functions. Function points measure the size of these functional user requirements only. Design and quality considerations, although important to the software construction, are not part of the logical size of the software, and therefore, they are not counted in function points.

This is similar to the size of a house being measured as the number of square feet or square meters contained within a floor plan, and it is not changed by how the house will be constructed. In functional size measurement, the function point count reflects only what the application must do, not how it will do it.

Confusion can arise when the word "logical" is used in conjunction with words that sound physical like "screen" or "report." A "logical screen" may consist of one or more connected physical data entry screens that support a single function. Everything in function points is counted from a logical user viewpoint, and novice counters need to think "logically" when they are counting function points.

The term "user," as typically used in information technology, refers to a physical, living, breathing person who interacts with or uses the software. This is the most frequent answer given when one asks a developer, "What is a user?" The terminology problem with the word user arises because the function point use of the word has a wider meaning. The Counting Practices Manual defines user as:  “A user is any person that specifies functional user requirements and/or any person or thing that communicates or interacts with the software at any time.”

In other words, for function point counting, users can be people, applications, departments, and other external parties--in short, anything that requires data from, or provides data to, the software. Functional user requirements include the logical business processes of many users. Users can include other software applications, physical persons, external government bodies, departments, animals (if they trigger a process in the application such as in security systems), things (such as pressure in a pipeline system)...anything that interacts by sending or receiving data across the boundary of the software application.

This difference in meaning can cause some countable functions to be overlooked by developers because they don't appear to be requirements provided for or by a physical person user.

The terms application and system in data processing are often used interchangeably and are usually tied to the physical segmentation of the software. Here are some examples of how applications or systems may be broken down by developers:

·        Based on functions performed in batch or on-line. Sometimes each mode of physical implementation of a single set of cooperative functions may be split into separate systems by developers; for example, the batch accounts receivable system, the on-line accounts receivable system

·        Based on the physical platform on which a subset of functions (or subfunctions) resides; for example, the mainframe payment system, the PC payments system

·        Based on the physical package(s) that make up a set of functions; for example, the Access database application, the InfoMaker reports application, and the data entry application. There are many other derivatives.

The term "application" within the context of function point counting is defined in the Counting Practices Manual as: “A cohesive collection of automated procedures and data supporting a business objective. It consists of one or more components, modules, or subsystems. This is frequently used synonymously with system, application system, and information system.”

This means that an application in function point terms is a collective grouping of related user functions regardless of the platform, mode of operation, and physical IT subdivision of functions. In the examples above, the batch and on-line systems would be one application for function point counting. The second example would result in one payments "application" from the user perspective, (which happens to be physically implemented across multiple platforms). The third example would likely also be a single application, with various packaged components used as part of how the software was delivered.

This difference in definition and usage of the word application can result in over counting (e.g., if an application was FP counted as two applications as an on-line count and a batch count, rather than properly as a single application), or under counting (e.g., if all of the applications on a single hardware box were counted as a single application).

It is important to remember that in function point counting, an application represents how a user would logically view the system, while in information technology, an application often represents how the system is physically implemented.

The term “project" is another term that often differs between its IT and function point meaning. When used in systems development, "project" can take on a variety of meanings, even within the same organization. "Project" can be used to describe variously:

·         The scope of work that includes enhancement or development of several discrete software applications

·         The scope of work including fixes/maintenance of existing functions plus enhancement to other functions of a single software application

·         Repairs of operating software upgrades of existing software

·         Combinations of any of the above

In function point counting, the word "project" refers to the work product associated with the development or enhancement of a single application (system). The definitions of development (project) in the IFPUG CPM glossary attests to this: “A collection of work tasks with a time frame and a work product to be delivered.”

Development project function point count (DFP): A count that measures the functions provided to the users with the first installation of the software delivered when the project is complete.

What this means to FP counters and developers is that a project in business or IT terms may actually equate to multiple function point projects and, therefore, translates into needing multiple function point counts, one per application involved. For example, if an IT project includes the development of a new hospital billing system as well as enhancements to an existing hospital admittance system, the size of the overall IT project would involve two function point project counts:

·         A development FP count of the new hospital billing system

·         An enhancement FP count of the changes to the hospital admitting system

It is also worth noting that an enhancement project, whose total size encompasses the added, changed, and deleted functionality, will change the product or application size by the amount of functionality added, less that deleted.

Once this difference in the term project is understood, it is simply a matter of communicating the FP counts in the right context.

This is another one of the most confusing terms that carries a different meaning when used in Information Technology and business, versus the function points use of the term. For business and IT professionals, the term enhancement or enhancement project refers to any project where the existing software is enhanced in terms of performance, appearance, function, operation, platform, usability, etc. Note that enhancement projects are often discerned by both users and developers from the term maintenance in that the latter pertains to work done to keep the existing software up and running)

All of the following are examples of what our clients' users and developers would refer to as software enhancements:

·         Making changes/additions to hard coded data within the system

·         Populating new occurrences of dynamic data (e.g., having developers do data administration/table population as part of the project either manually or with the use of tools)

·         Upgrading software to be compatible with new database releases (such as a new Oracle release)

·         Splitting one physical screen into multiple physical screens (but not changing the functionality)

·         Changing error message text to be more "user friendly"

·         Cosmetic screen or report rearrangement, adding more screen highlighting, or creating additional menus (restructuring the navigation)

·         Adding new peripheral devices (such as adding the ability to print to laser printers on a formerly dot-matrix-only network)

·         Testing one application to verify the expected effects of changes in another application

·         Increasing the results list for an existing report by adjusting a filter to retrieve more valid values

·         Adding data elements to an existing report

This is very different from enhancement in the context of function point counting, where it means functional enhancement. The IFPUG counting practices 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: “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:

·       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.

·       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.

·       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.

·       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. Conclusion
This list of commonly misunderstood words is not exhaustive, and other words and acronyms can form barriers to understanding of function points.

Table 1 summarizes the terms covered in this article:

Term	Meaning in IT	Meaning in Function Point Counting
Logical	Typically includes both conceptual and design considerations. Even logical data models often contain physical components.	Refers to logical functions and logical user requirements. Conceptual, from a user business perspective. Does not include design or quality considerations. Reflects what the software must do, not how.
User	Physical person who uses or specifies requirements for the software.	Person, thing, other application, department, etc. that provides functional user requirements for the software.
Application (system)	Physical implementation of software. The boundary of an application or system often coincides with physical hardware or software boundaries.	A cohesive collection of automated procedures and data supporting a business objective.
Project	Depending on the organization, can include new development, changes, or enhancements to multiple applications.	Pertains to the work product done on a single application: ·         Development: The specification, construction, testing, and delivery of a new information system. ·         Enhancement: The modification of an existing application.
Enhancement (enhancement project)	Any modification to the software including functional, non-functional, technical, cosmetic, data administration, or design changes that increase the business value of the software.	Functional modifications to the elementary processes of the application (e.g., new/ modified/removed functions: EI, EO, EQ, ILF or EIF).
File	Dataset, or physical assemblage of data, as in output file, input file, data file, research file, etc.	A logically related group of data, not the physical implementation of those groups of data.

Functional size measurement and function points are not rocket science; they simply provide an objective, repeatable process for assessing the logical size of software based on functional user requirements. By understanding some of the terminology that can trip up developers and novice counters, this article will, hopefully, demystify the perceived complexities involved in function point counting.