Demystifying Function Points

INTRODUCTION
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).

However, just as an architect begins by drawing a floor plan to meet the owners' needs, software project managers and developers begin by documenting the functional user requirements articulated by their customers. Function Point Analysis 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:

1. 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; and
2. 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