Function Points FAQs

External Interface Files - Sample Scenarios

Home

Issue Description

Functional Overview

General Discussion and Resolution


ISSUE

When should data sourced from another system, which contributes to the update of internal logical files of the system being counted, be classified as an:

External Interface File

Internal Logical File

External Input transaction?

This section has been included to summarise a number of data transfer scenarios, commonly encountered. Some of the issues have already been addressed in other sections in this document. They are repeated and summarised in this section primarily to provide an easy comparison of different EIF scenarios and the resolutions of the counting issues relevant to the scenario.

To simplify the descriptions the following terms have been used

System A

The source system for the reference/transaction data being transferred.

System B

The receiving system for the reference/transaction data being transferred.

File X

System A ILF

File X

System B ILF A subset or superset of the File X data. Similar but not identical. Uniqueness criteria have been established.

File Y

System B ILF

File Z

The data transfer file. This file is generated by System A and read by System B


In each example it has been established that an application boundary exists between System A and System B.

 Home


FUNCTIONAL OVERVIEW

Data used by elementary processes to maintain records on an Internal Logical File within an application may originate from a number of different sources:

  1. External non-system sources.

Sourced from external manual procedures and entered by system users via on-line screens.

  1. Other computer systems:
  • via transferred files
  • via direct on-line real-time information requests
  1. The system itself.
  • Data from internal reference files may contribute to a master business transaction.
  • Stored data may be used to generate new data that must be stored (and cannot be re-created at a future time).

The following Sample Scenarios, focus on the situation where the data required to complete elementary processes within System B, is sourced from another system/s, System A. Counting guidelines for the other two data information sources i.e. external non computer system sources, and System B itself, are adequately covered by the IFPUG Release 4.1 Counting Guidelines.

Sample Scenarios

Scenario 1 Data Load, No Logical Processing of Loaded Data

System A produces an extract File Z of records that are loaded into the System B. System B does not process the input data. It is copied directly into physical table, System B File X. The DETs on both Files X are identical. The records on the transfer File Z are of one type only and typically the attributes are the same as for File X.

Scenario 1 Resolution

This data transfer is a technical solution devised to satisfy the business requirement that System B should have access, for data retrieval purposes, to the System A File X.

Transactions

The data transfer transactions: System A download, and System B Load, are part of the technical solution and are not counted to either system.

In reality, when counting System A in isolation, it may not be apparent to the FP Analyst that this is a technical transaction, and it may be counted as an EO/EQ.

Files

There is only one file involved. System A counts File X as an ILF. System B counts its copied version of File X as an EIF.

Neither system counts File Z as a logical file.

Scenario 2 Data Load, Includes Logical Processing of Loaded Data

System A produces an extract File Z of records that are loaded into System B. The records are usually of one type only. System B processes the input data prior to storing it on internal File X'. The DETs on System A File X, and System B File X, are different. Load processing may include:

  • data extraction
  • conversion or translation of values
  • validation
  • derivation of new values

aggregation of values.

Scenario 2 Resolution

This data transfer is a user business requirement. Both System A and B have a requirement to access a version of the File X however the DETs on the two files are different.

Transactions

The data transfer transactions: System A download, and System B Load, are counted to the respective systems.

Files

There are two files involved. System A counts File X as an ILF. System B counts File X as an ILF.

Neither system counts File Z as a logical file.

Scenario 3 File Update, Transaction Data Generated by Source System

System A produces a transaction File Z of record changes that are loaded into System B. The records are usually of more than one type. System B processes the input transactions according to the transaction type on the File Z records, prior to updating the records on internal File X. The DETs on System A File X, and System B File X, are different. For example File X may be a Master Material Catalogue while File X is a local Product List. Load processing may include the following transaction types:

  • Add
  • Modify
  • Delete

Alternatively the transaction types may trigger different types of processing, for example the rating of different call types received on exchange Call Event Records.

Scenario 3 Resolution

This data transfer is a user business requirement. Both System A and B have a requirement to access a version of the File X however the DETs on the two files are different. System A transfers to System B, data related to changes only. System B reads the records on File Z and based upon the transaction type initiates different logical processing

Transactions

System A download transactions are counted as either one, or multiple, EO/EQ functions. For multiple functions, different logical processing must be demonstrated. If every record written by System A to the File Z is processed in the same way only one EO/EQ is counted.

System B counts as EIs each unique maintenance function on File X. The number of Transaction Types on the transaction File Z, usually determines the number of these functions, but this is not necessarily the case. Different logical processing must be demonstrated.

Files

There are two files involved. System A counts File X as an ILF. System B counts File X as an ILF.

Neither system counts File Z as a logical file.

Scenario 4 File Update, Transaction Data Generated by Updating System

System B has a requirement to update records on its internal File X. File X in System A stores the most current version of the data required by X. System B reads System A File X, compares the records to records on its own file X and generates a changes File Z. File Z transactions are then processed by System B and File X is updated. Load processing may include the following transaction types:

  • Add
  • Modify
  • Delete

Scenario 4 Resolution

This file update is a user business requirement. System B performs all the functions required to facilitate the update.

Transactions

There are no transaction functions to count for System A.

System B counts as EIs each unique maintenance function on File X. .

Files

There are two files involved. System A counts File X as an ILF. System B counts File X as an ILF and File X as an EIF.

Neither system counts transaction File Z as a logical file.

 Home


GENERAL DISCUSSION AND RESOLUTION

Note: An associated counting issue is Section 3.4.3 ILF and EIF Identification and Counting Guidelines

The resolutions to the different scenarios seek to avoid a situation where EIFs are double counted. For example:

  • A file is counted as both an EIF and External Input transactions.
  • A file is counted as both an EIF and an ILF.


 Home

Issue Description

Functional Overview

General Discussion and Resolution