Demystifying Function Points

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:

User: 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:

1. 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;
2. Based on the physical platform on which a subset of functions (or subfunctions) resides; for example, the mainframe payment system, the PC payments system;
3. 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: 

Application: A cohesive collection of automated procedures and data supporting a business objective. It consists of one or more components, modules, or subsystems. 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.

"project" is another