Function Points FAQs

Calculators, Simulators


Issue Description

Functional Overview

General Discussion and Resolution


What is the user requested business functionality provided by an application which is used to perform ‘what if’ analyses for various types of business events and products?

Note: In the discussion that follows the term calculator is used to represent calculators and simulators. These are very similar types of software.



The prime purpose of a calculator is to provide a calculated result in response to a given set of input parameters. These systems are used in a ‘session’ mode. The user enters values for a number of parameters and a calculation/evaluation is performed. The user may then adjust the variable input parameters, and request that the calculation be performed again. This can occur numerous times until the user has obtained the information required and chooses to terminate the session.

Most calculators share the following characteristics:

  1. The prime objective of the calculator is to perform a number of calculations in response to user supplied input. The possible number of calculations is pre-defined. The results of the calculations may be presented in summary or detailed format. It is these outputs that are the main business functions of the calculator. The calculation and results presentation are sub processes of the one elementary process.
  2. The user enters data into a series of screens, which exhibit all the standard GUI screen features. For example, drop down list boxes to assist with user parameter selection, on-line validation of data, mandatory and optional fields and other features available in a GUI interface.
  3. Data entered may be stored permanently (indefinite persistence), exist only for the duration of the session (short persistence), or in a very simple calculator may need to be re-entered each time the calculation is triggered (no persistence)
  4. The databases used by calculators may be very simple. For example one large physical file may store all the data input by the user. It is recommended that the contents of the file be examined closely and the guidelines for identifying logical files applied, See Section 3.4 Files. One large physical file may comprise more than one logical file.
  5. The calculations are triggered once the user has supplied all the necessary information.
  6. The results of the calculation/evaluation are presented either as:
    1. A single result
    2. A results table, for example a schedule of repayments
    3. A graph

    The results are presented on screen and, if required a hard copy may be produced.

  7. The user is able to adjust the variable input parameters as many times as required, each time triggering the calculations. The changed parameter values are stored.
  8. The data entry and calculation functions are usually supported by a number of reference tables which define products, interest rates, calendars and other values that are needed as input to the calculations
  9. At the end of the session, the user may choose to accept one of the results, for example a leasing repayment schedule and other conditions, and proceed with making further arrangements. Typically, it is at this point that the data collected in the calculator files are sent via file, e-mail or hardcopy to another organisational unit or application.



The guidelines for counting calculators are based upon the following basic rules:

  1. Only functions customised or custom built by the organisation’s developers will be included within the scope of the function point count.
  2. The data entry functions and the calculations are counted as one elementary process. They are only counted as separate elementary processes, when the data entered is actually stored, because it must be retained until the end of the session for maintenance and reporting purposes. Only one data update function is counted if there is only one record per file. For add, modify and delete functions to be counted there must be multiple records eg more than one expense record per loan application.
  3. If the data is not stored and must be entered each time a calculation is performed, separate data entry functions are not counted. The data entry is a sub-process of the calculate function.

The following counting guidelines present a generic solution to the FPA issues related to calculators.

Files: Logical Files

Where they exist, the following may be counted as logical files for the calculator:

  • Files which store parameters entered by the user.
    (Applicant Details, Income Details, Expenses, Assets, are counted as separate logical files)
    These files are counted if they display either Short or Indefinite Persistence. In calculators, a unique view is taken of data that is stored for the duration of a session. As this data can be updated, viewed and reported upon, during the session, even though it may be deleted at the end it is considered to be a logical file.
  • Reference files accessed by the calculations - for example, loan products, interest rate tiers etc
  • Statistics file – which may record the level of use of calculator functions.

Use standard IFPUG guidelines, and the guidelines provided in Section 3.4 Files, of this document to determine the file type.

Transactions: External Inputs

Where they exist, the following may be counted as EIs for the calculator

  • Maintenance functions on the parameter files, but only if the data is stored and kept for the duration of the session or longer.
  • Maintenance functions for the reference files.

Transactions: External Outputs/External Enquiries

Where they exist, the following may be counted as EO’s and EQ’s for the calculator.

  • Results of calculations/evaluations performed. – for example, calculate repayment amount, determine repayment schedule. Apply rules for identifying unique elementary processes to ensure you do not count functions at a sub-process level.
    Count a separate EO for each type of output presentation, for example, table, graph, pie chart etc. Ensure uniqueness criteria are satisfied. For example a repayment schedule displayed on screen, and a hard copy print out of identical schedule information, are counted as one output.
  • Enquiry functions on input parameters – for example, View asset details.
  • Enquiry functions on reference table data – List Available Products
  • Transfer of Applicant/Client details to external business unit or external application via file, automatically generated e-mail, fax etc

Further References

  • Issue, ILF and EIF – Identification and Counting Guidelines
  • Issue, Identical Business Functions – Different Delivery Mechanisms
  • Issue, Uniqueness Criteria for Transactions.


Issue Description

Functional Overview

General Discussion and Resolution