A Handbook for

Functional Sizing - Configuration

Points

Counting Practice Manual

Description and Guidelines

Configuration Point Analysis

November 2013

Document owner: Davide Levi

This Handbook, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This Handbook may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates.
© 2013 Gartner, Inc. and/or its affiliates. All rights reserved.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page i

Table of Contents

1.0 Configuration Point Methodology........................................................................ 2

1.1 Configurations .......................................................................................................... 2
1.2 Approach to Configuration Sizing ............................................................................. 3
1.3 Configuration Points Counting Rules ........................................................................ 3
1.4 Data ......................................................................................................................... 5
1.5 Logical Lists ............................................................................................................. 5
1.6 Rules ........................................................................................................................ 6
1.7 Examples ................................................................................................................. 6
1.7.1 Example 1 ................................................................................................... 6
1.7.2 Example 2 ................................................................................................... 7
1.7.3 Example 3 ................................................................................................... 8

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page 2

1.0 Configuration Point Methodology

1.1 Configurations
Configuration Points (CPs) are an extension to the Gartner Fast Function Point Analysis (FFPA)
method. Configuration Points are specifically designed for use in sizing modifications to the
functionality of software where this modification is achieved explicitly through the use of
“Configurations. Configuration Points has been developed to enable organisations to measure
the productivity of changes to functionality that are enacted either by business users directly or
by IT on behalf of business users rather than being delivered by the IT function as part of an
enhancement project, which would normally be sized using Function Point Analysis.
The terms often used to describe the types of software where this is typically seen are:
 Package software.
 ERP systems.
 COTS software.
 Bespoke applications specifically designed to support configuration by the business
users.
Configuration Points do not replace other functional sizing methods such as FFPA which could
be used to size the same modifications. The advantage of Configuration Points is that they are
directly applicable by business users without the need to understand the more technical
concepts common to traditional functional sizing methods.
Configurations are defined as changes (add, update, delete) of data (parameters) in one
or more tables pre-defined within the package/in house application (the application),
resulting in a change of the behavior of the application from the users perspective. These
table changes are applied directly or via a “configurator”. Typically there is no writing of
code involved.
Configurations can also result in additions of new functionality (for instance previously “hidden”
inside an application) that becomes “activated” through the configurations.
Configurations may occur in situations where user requirements can be satisfied by business
users without the need for coding or intervention by the IT function. Often this is achieved by
means of simple validation of existing data structures (lists, tables, matrices) without the need to
modify their structure (add or delete fields).
Configuration activities are frequently used in modern, packaged environments or well-
engineered applications, where the person who implements part of the required changes looks
at the application as a black box. Visibility of the underlying detailed logical model is not
required.
In this document we will illustrate the CP methodology by examples taken from the telecom
services industry, but the methodology is generic to all industries and applications where
configurations are occurring.
 Please note that Function Points (IFPUG or FFPA) and Configuration Points are NOT
equivalent. The two units cannot be added or otherwise manipulated together using
basic mathematical operations.
 Please note that Configuration Points are NOT independent of the technology used for
implementation as you can only count CPs if a previously implemented configuration

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page 3

capability is available in the application to be sized. Furthermore, the number of

Configuration Points depends on how the configuration tables or screens have been
defined with respect to the configurable entities/functionalities.

 Business object: any logical object managed/processed by the application and visible to
the users.

1.2 Approach to Configuration Sizing

A set or group of user requirements may have parts that require traditional development by the
IT function of an organisation (sizeable with a standard IFPUG approach or FFPA) and parts
that can be implemented by business users by means of configurations.
In order to use the Configuration Point methodology, which requirements will be delivered using
configurations must be defined. Within each general requirement, the number of single
configurable business requirements needs to be identified. Each single configurable business
requirement will be sized as a single configuration, with its number of data, lists and associated
rules, as shown in Figure 1.
A single configurable business requirement is defined as the lowest level, user
recognizable business operation which when completed leaves the system in a
predictable and consistent state (e.g. produce end of day report), or a new instance of an
existing business entity (e.g. a new product or a new user profile).
A requirement that is asking to implement five new functions, e.g. five distinct new
reports, will be sized as five different configurations, each of them with its own number
of data, lists and rules, and will produce five different rows in the data collection sheet.
To use Configuration Points the elementary steps below must be followed:
1. Identify the boundary of the system that has to be sized
2. Identify the user(s) of the system
3. Identify which business requirements will be delivered in the system using configurations
4. Identify the number of business objects (see glossary) that will be delivered using
configurations (i.e. the number of configurations) and for each one of those use the CP
methodology, following the rules below..

1.3 Configuration Points Counting Rules

For Configuration Points, every single and discrete business requirement that will be delivered
using configurations is translated into CPs, based on counts of three types of logical objects
impacted by the configuration activity:
 Data — is the number of logical attributes that are impacted by the configuration activity.
Data that must be counted are only the ones that are meaningful to the users of the
application.
 Logical Lists — is the number of logical tables to which data mentioned above belong.
A logical table is a set of logical data (or attributes), homogeneous from the user’s
perspective and from the perspective of the operations that the application performs on

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page 4

it. More attributes belong to a single list if they are logically connected to each other or
are processed from a logical point of view as a unique object.
 Rules — is the count of individual business rules, i.e. rules that determine the way in
which business is done, that will be created and set, amended or deleted as a result of
implementing the single configuration.
 “individual business rules” means as perceived by the business user performing
the configuration. A individual business rule may be:
o A formula carrying out a calculation that is meaningful to the business (i.e.
not each step within the calculation).
o Establishing a relationship between items.
o Setting upper and/or lower limits for an acceptable range.
 “created and set” means that the configuration has defined a new business rule
and established its initial settings.
 “amended or deleted” means that an existing business rule has its set of valid
parameters changed or that the set of valid relationships is changed or that the
existing business rule is deactivated.

The counts for each logical object being configured are weighted as shown below:
Logical Object Weight
Data 0.2
Logical Lists 0.5
Rules 1

Figure 1 shows an example of a data collection sheet used to size configuration activities: each
row of the sheet represents a single configurable business requirement, which is measured in
terms of the number of data, lists and rules that have been impacted by the configuration
activity.

Configurable Business Requirement Data Wt Lists Wt Rules Wt CPts

Offering xyz 4 0.2 1 0.5 1 1 2.3
Pricing abc 12 0.2 2 0.5 2 1 5.4
Offering wjk 5 0.2 1 0.5 1 1 2.5

Figure 1 – Data collection sheet

The Configuration Points (CP) For a given set of functional requirements realised through
configurations are calculated as follows:

CP = Data * 0.2 + Logical Lists * 0.5 + Rules * 1.0

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page 5

1.4 Data
When using the CP methodology, the data elements that have to be counted are the ones that
are impacted as a result of satisfying the business requirement through configuration. Data
represents the logical attributes of the business object requested by the user requirement.
In the simple example shown in
Figure 2, the user requirement is to introduce a new pricing structure (e.g. Pricing 3), for which
values have to be defined for the 4 different types of traffic.
In order to perform the configuration, the developer has available a configuration table, like the
one shown in the picture, where he has to define the unit price for each one of the 4 types of
traffic, according to the business requirement.
Pricing Structure
Charging Rates
Voice SMS MMS Data
Pricing 1 0.30 0.20 Void Void
Pricing 2 0.20 0.20 1.00 Void
Pricing 3 0.20 0.10 1.00 1.20
(the new pricing)

Figure 2 – Data
In this example, the data that will be counted in order to calculate the CP’s are only the four
data elements related to Pricing 3, namely those related to the requested business object.

1.5 Logical Lists

In the CP methodology, the logical lists are the logical files in which data are grouped. In order
to identify the logical lists associated to a configurable business object, the same rules used to
identify the internal logical files (ILF’s) can be applied, as for an IFPUG sizing approach.
In the example shown in
Figure 2 above, all data can be considered as belonging to single unique logical list, which is the
list of charging rates defined for a certain pricing structure.
In a different example, the pricing structure could be defined by the definition of both the unit
charging rates of the different types of traffic and also by the definition of the amount of free
units that the client can use for free. This case is shown in Figure 3. In this example, under the
rules for Configuration Points we identify two different logical lists, that are the list of the unit
fares (comprising 4 business data elements) and the list of free units (comprising 4 other
business data).

Pricing Structure Pricing Structure

Charging Rates Free Units Limit
Voice SMS MMS Data Minutes #SMS #MMS #KB

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page 6

Pricing 1 0.30 0.20 Void Void 5 0 0 0

Pricing 2 0.20 0.20 1.00 Void 5 10 0 0
Pricing 3 0.20 0.10 1.00 1.20 10 100 10 100
(the new pricing)

Figure 3 – Logical lists

1.6 Rules
One of the logical objects that are required to size a configuration is the number of rules
modified (added, changed or deleted). This means that, while a data item is a static value, a rule
usually implements an action, such as a validation, a selection, a modification to the behaviour
of the system, a mathematical formula or a calculation.
Count the number of logical rules that are implemented, no matter how they are physically
represented in the configurator.

1.7 Examples
1.7.1 Example 1
A sales application manages the portfolio of offerings that can be proposed to clients. A new
business requirement is the market launch of a new offer, called “Happy Summer.” To allow
selling a new offering, the application is built in such a way that there is no need for coding, but
a configuration approach is possible to change how the application validates some fields in a
user interface.
Figure shows the layout of the configurator; to keep the new offering available for selling to the
dealers, it is necessary to enter five attributes of the offering (Name, Code, Start date, End date,
Price) and set the compatibility rules with the already existing offerings.

Name Happy Summer

Code HSM

Start date 01/07/2006

End date 30/09/2006

Price € 20,00

Compatibility
. Offering AAC

. Offering CXB
Offering VCD
Offering DGF
Offering JKN

. Offering RTM
Offering PLN
Offering ESF

Figure 4 – New offering

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page 7

Using the CP methodology, this activity will be sized as a single configuration made up of five
data (the validated attributes), one logical list (the logical table of the offering) and one rule (the
rule of compatibility is used to establish a new set of valid relationships), as shown in Figure 5.
Note that the compatibility rule translates a logical condition (e.g. if the offering is Happy
Summer then you can also buy the offers AAC, VCD, PLN) instead of being a static parameter
like the offering Name or Code.
Name Code Start date End date Price Compatible Offers
Happy Summer HSM 01/07/2006 30/09/2006 € 20,00 AAC
Happy Summer HSM 01/07/2006 30/09/2006 € 20,00 VCD
Happy Summer HSM 01/07/2006 30/09/2006 € 20,00 PLN
Figure 4a - Truth table
A usual approach in configuring a rule like a validation or a logical “IF” in simple configurators is
to build a truth table. Figure 4a shows the same configuration as Figure 4 but using a different
type of configurator that requires multiple rows (the truth table) to implement the same
compatibility rule.

Configurations
CP
Configurable business requirement Data Lists Rules
Offering Happy Summer 5 1 1 2,5
Figure 5 – CP calculation for new offering

1.7.2 Example 2
Considering the example in Figure , let’s suppose that the selling of this offering has been so
successful that Marketing decides to extend the validity period. In this case, the only impact to
the configuration will be the need to modify just one of the fields of the configurator, the End
date, which will be changed from September 30th to October 30th (Figure 6).

Name Happy Summer

Code HSM

Start date 01/07/2006

End date 30/10/2006

Price € 20,00

Compatibility
. Offering AAC

. Offering CXB
Offering VCD
Offering DGF
Offering JKN

. Offering RTM
Offering PLN
Offering ESF

Figure 6 – Modification requirement

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Version 1.1 Handbook for Functional Sizing - Configuration Points
Description and Guidelines Configuration Points November 2013—Page 8

From a sizing point of view, the impact will be just one datum on one list, with no rules, as
shown in Figure . The CP calculation for this configuration is shown in Figure 7.

Configurations
CP
Configurable business requirement Data Lists Rules
Happy Summer extension date 1 1 0,7
Figure 7 – CP calculation for a modification

1.7.3 Example 3
Let’s suppose that we have a new offering to configure, which is a bit more complicated than the
previous one, because associated with it is a bundle of free components (such as SMS, MMS,
seconds of conversation, etc.) that the client can use for free, up to a pre-defined limit.
In this case we will have a larger number of data to be validated and two different logical lists
impacted (the first for the offering; the second for the bundle), as shown in Figure 4.
From a sizing point of view, the result will be as shown in Figure 5; we will have nine data in
total, five of which are on one logical list (the offering registry) and the other four are on another
logical list (the bundle), plus the compatibility rule.

Name Happy Summer Bundle

Code HSM Traffic (hh,mm,ss) 01,40,00

Start date 01/07/2006 SMS 100

End date 30/10/2006 MMS 50

Price € 20,00 GPRS (MB) 5

Compatibility
. Offering AAC

. Offering CXB
Offering VCD
Offering DGF
Offering JKN

. Offering RTM
Offering PLN
Offering ESF

Figure 4 – Composite offering

Configurations
CP
Configurable business requirement Data Lists Rules
Composite offering 9 2 1 3,8
Figure 5 - CP calculation for composite offering

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.
Any questions regarding this Handbook
should be addressed to:
Davide Levi
GCtitle
Gartner, Inc.
GCadd
Telephone: +1 GCphone
Facsimile: +1 GCfax
Email: [email protected]

© 2012 Gartner, Inc. and/or its affiliates. All rights reserved.

Gartner is a trademark of Gartner, Inc. or its affiliates.
For internal use of Gartner only.