Waves come in multiple sizes just like transactions.

Waves come in multiple sizes just like transactions.

Each of the three types of transactions identified in the IFPUG Function Point methodology are classified into three categories: low, average and high (or small, medium and large).  The process for sizing transactions is similar to the process we used to size data functions. The size of a transaction is based on the interplay between file types referenced (FTR) and data element types (DETs).  A FTR refers to an internal logical files read or updated or an external interface file read.  The function point counter will review each transaction and count the number ILFs read or updated and the EIFs read.  The total FTRs will be used to determine the size (remember IFPUG uses the work ‘complexity’).  In our example of an HR system, we described the human resource clerk sitting in front of a computer entering the data needed to add a new employee (Employee Number, Name, Address, City, State, Zip, Work Location, and Job Code), and after entering the data the clerk hits the enter key and the data is committed to the employee ILF. Upon review it was pointed out that the Zip Code entered was checked against the Zip Code file provided by the US Post Office.  The number of FTRs for this external input transaction would be two (Employee and Zip/Postal Code).  The counting rules for FTRs are no different whether the transaction is an EI, EO or EQ, with the exception that an EQ can never update a logical file. Therefore the FTRs should only reflect files that are read for EQs.

DETs are defined as unique, user-recognizable, non-repeated attributes.  This is the same definition of a DET that we used when discussing sizing data functions.  Counting data DETs for transactions is similar to counting DETs for data transactions with a few more transaction-related rules.  The rules:

Count “one” for each DET that enters or exits the boundary during the processing of the transaction.

Count “one” DET per transaction for the ability to send a response message (only one per transaction)

Count “one” DET per transaction for the ability to make the transaction happen (only one per transaction)

Using our example of entering an employee, the clerk types in 8 fields therefore the counter would count 8 DETs entering the boundary of the application.  When he or she is finished typing they will click on the post icon (or press enter) when the Zip Code is validated.  A message is returned if the Zip Code is wrong or if it is correct, and if the employee does not already exist a message is displayed saying that the employee is added.  In this case we would count a DET for the message and a DET for the ability to make the transaction happen. In our example the total number of DETs would be 10.

Just like the data transactions, IFPUG provides a simple matrix to derive size of external inputs.

FTRs 1 – 4 DETs 5 – 15 DETs 16 + DETs
0 – 1 Low Low Average
2 Low Average High
3+ Average High High

Using the matrix is a matter of counting the number of FTRs a transactions uses, finding the corresponding row and then finding the corresponding column for the number of DETs that you counted for the transactions.  In the example two FTRs and 10 DETs equates to an average external input.

The size/complexity matrix for external outputs and external inquires is a little different.

FTRs 1 – 5 DETs 6 – 19 DETs 20 + DETs
0 – 1 Low Low Average
2 – 3 Low Average High
4+ Average High High

A quick example of an external inquiry using our HR example would be if our mythical HR clerk needed to look up an employee (with same 8 fields noted before).  To accomplish this, the clerk types in an employee number and then presses enter. If the employee number is bad (or an employee does not exist) a message is returned.  If found all eight fields are displayed.  We would count 10 DETS.  We count one DET for employee number entering, one DET for pressing Enter one DET for the ability for a message and then seven DETs for all of the employee data returned (exits) except that employee number both enters and exits therefore is only counted once.   The Zip Code would not be validated on the external inquiry therefore the transaction would have one FTR and 10 DETs therefore would be a low external inquiry.

The process is repeated for each transaction.