## Software Estimation

Certification Training
2592 Learners
8 Chapters +

# Counting Rules for Data Functions and Transaction Functions Tutorial

## 4.2 IFPUG FPA Counting Rules for Data Functions and Transaction Functions

Hello and welcome to software estimation course offered by Simplilearn. In the previous module, we covered counting scope, application boundary, and identification rules for data functions and transactions. This module primarily deals with counting rules for data functions and transaction functions. Let us begin by looking into the agenda of this module.

## 4.3 Agenda

We will start this module with a recap of the FPA counting steps. We will then be introducing the components of data functions, that is, the components that make up an ILF or an EIF. The components are Data Element Types (DETs) (abbreviate) and Record Element Types (RETs) (abbreviate). This will be followed by an understanding of the counting rules for DETs and RETs. Next, we will look in to the components that make up an EI, EQ, or an EO; the transaction functions. The components of transaction functions are Data Element Types (DETs) and File Type Referenced (FTR). We will end the module by covering the counting rules for DETs and FTR. Next slide contains a recap of the FPA counting steps.

## 4.4 Recap of the FP Counting Process

Function Point Analysis (FPA) starts with the determination of the counting scope and the application boundary. Then the data functions – Internal Logic Files (ILFs) and External Interface Files (EIFs), are identified and rated. This is followed by the identification and rating of the transaction functions – External Inputs (EIs), External Queries (EQs), and External Outputs (EOs). After the end of this step, the resulting measure is the Unadjusted Function Point (UFP) count of the project or application being counted. Finally, the fourteen General System Characteristics (GSCs) are rated to determine the Adjusted Function Point (AFP) count. We will look into the components of the data functions in the next slide.

## 4.5 Components of Data Functions

Function Point Analysis deals with the breaking down of the application into granular components, and studying each of these individual components. Till now it has been seen that an entire application is broken down into data in storage that is data functions, and data in motion which is transaction functions. The data functions are further classified as ILFs and EIFs. The transaction functions are further classified as EI, EQ, and EO. The next step is to further break the ILFs and EIFs into logical components called Data Element Types (DETs), and Record Element Types (RETs). In the next slide, we will understand what Data Element Types (DETs) are for Data Functions.

## 4.6 Data Element Type for Data Function

A data element type is a unique, user-recognizable, non-repeated attribute of a data function. Each data function has a set of attributes and they are the DETs for the data function. For example, let us consider the logical data function, “Employee” which has the attributes – name, age, employee type, and location as attributes. These attributes are the data element types for the data function “Employee”. In the next slide, we will look into the counting rules for Data Element Types for Data Functions.

## 4.7 Counting Rules for DETs of Data Functions

First and foremost, one DET is counted for all the unique and user-recognizable attributes maintained in an ILF, or being referenced from an EIF. These data elements are maintained in an ILF, or referenced from an EIF through an elementary process. Then, count only those DETs that are used by the application being measured. There might be cases where a data function also stores some attributes that are not used by the application being measured. However, these attributes might be used by another application, which is not a part of the counting scope. These additional DETs are not counted for the application being measured. Next, count one additional DET for each attribute that is used to establish a relationship with another related data function. Consider the example of Employee and Job data functions. Though these are logically entity-independent and separate data function, there might be a reference attribute in employee data function, which is related to the job data function, to signify the job details of an employee. This attribute can be the job ID, which is a foreign key. Such reference attributes, if any, have to be counted as a DET in the data function. If there are related attributes with a data function, these attributes have to be reviewed to understand if they are single or a set of multiple DETs. The decision is taken based on the how the attributes are going to be used by the user. For example, consider that the name of an employee is stored in two attributes called “First Name” and “Last Name”. If these two attributes are used separately in the application, then two DETs are counted for the data function. Instead, if the application uses both these attributes together, though storing them in two separate attributes, then only one DET is counted for the data function. Finally, do not count those attributes within a data function, which are merely used for technical implementation rather than as a user requirement. For example, consider that a unique ID is created for every employee in addition to the “Employee ID”. This ID might be used to index the data for faster retrieval during search operations. Such attributes are not counted as DETs for the data function. Remember that the DET has to be user-recognizable. In the next slide, we will understand what Record Element Types (RETs) are for Data Functions.

## 4.8 Record Element Type for Data Function

The concept of Record Element Types (RETs) is probably one of the most difficult in function point analysis. RET represents the user's view of coherent subgroups of data, within an identified logical file. This measure is an indicator of complex relationships that exists with a data function. Record element type represents the number of subgroups of data within a data function. Logically related and entity dependent information have to be grouped and considered as a single data function. RET is used to represent such entity dependent relationships within a data function. It typically corresponds to the entities that are grouped. Consider the case of employee and dependent information discussed earlier. We concluded that logically, these two entities are dependent and hence considered as a single data function. Thus, there are two subgroups of data within the data function, and thus there will be two RETs. In the next slide, we will look into the three entity relationship types that are useful for identification of record element types.

## 4.9 Entity Relationship Types

Before understanding the counting rules for RETs, it is important to understand the three types of entity relationships. A clear understanding of these relationships helps in the easy identification of RETs within a data function. These relationship types are based on the 3rd Normal Forms in Relational Database Management System (RDBMS). The first relationship type is the associative relationship. This type of relationship establishes the association of two dependent entities. As shown in the example, an employee is associated with his or her dependents. This is 1: M (pronounce as one to em) association, that is, one employee can have many dependents. Other types of association are 1:1 (pronounce as one to one), and M: N (pronounce em to en).The next relationship type is the sub-type relationship. In this type of relationship, a child entity inherits some of the attributes of the parent entity, and in addition has other attributes unique to the child entity. As shown in the example, an employee has a set of attributes. An employee can be either a permanent or a contractual employee. This is a sub-type of the parent entity type. Permanent employee has a set of additional attributes, and contractual employees have additional set of attributes. These sub-types of data would be stored within a single data function and hence counted as additional RETs. The last relationship type is the attribute relationship. This relationship is used to describe the attributes of the parent entities. The attributes merely depend on the parent for existence and can’t be exclusive. As shown in the example, the employee has a few attributes like name, age, role, etc. These attributes can’t exist without the existence of the employee entity. One RET is counted for all the attributive entities within a data function. In the next slide, we will see the counting rules for record element types.

## 4.10 Counting Rules for RETs

By default, every data function has one RET. This RET is to represent the attributes of the parent entity. In addition to this, additional RETs have to be counted if either sub-type or associative entity relationship exists within the data function. In the next slide, we will identify the number of DETs and RETs for the data functions in the currency converter example.

## 4.11 DETs and RETs in Currency Converter

In the example discussed in the previous module it was seen that the Currency Converter application has two data functions – one ILF and one EIF. The ILF is used to store the transactions carried out by the user, and the EIF is used to retrieve the current conversion rate. As depicted by the image in the slide, the ILF has four DETs – date, amount in dollar, conversion rate, and amount in rupees. There are no additional RET apart from the one default RET. The EIF has just one DET which is the conversion rate of that moment. Note that there might be additional attributes in the data function, but from the user perspective, the conversion rate is the only attribute being used in the application, and hence only this is considered as DET. There are no additional RET in the EIF. Thus one DET, one RET for the EIF. With this, we have completed the counting rules for Data Functions. In the next slide, we will introduce the components of transaction functions.

## 4.12 Components of Transaction Functions

We have already found out how an application is broken into data transaction functions. We have also looked into the components of data functions, which are DETs and RETs. Similarly, the transaction functions also comprises of Data Element Types (DETs) and File Type Referenced (FTR). Let us cover the data element types for transaction functions in the next slide.

## 4.13 Data Element Type for Transaction Function

Similar to the DET of a data function, a data element type of a transaction function is a unique, user-recognizable, non-repeated attribute. However, from the transaction functions’ perspective, these DETs are the attributes that move from out to in or vice versa in a transaction. In the next slide, we will look into the counting rules for data element types of transaction functions.

## 4.14 Counting Rules for DETs of Transaction Functions

A typical transaction has three parts: the first being the input or the trigger to initiate the transaction – like clicking a button, pressing a key, etc. The second part is data being transferred in or out of the application. That is, in the case of external inputs, data being sent inside the application, and in the case of external query or external output, data being transferred out of the application. The third and the last part is the confirmation message or validation message that the transaction is complete or incomplete. Understanding these three basic parts of a transaction is the key to identify the DETs of a transaction function. As discussed, DET for transaction functions are different from the DETs for data functions. To count the number of DETs for a transaction function, identify and count all the unique, user-recognizable and non-repetitive attributes that cross the boundary, that is, all the attributes that crosses the boundary from outside to inside and vice versa through the application boundary. It is to be noted that these attributes should be user-recognizable, which means that system or technical attributes are not counted as DETs. Additionally, count one DET for the ability of the application to send a response message or validation message within a transaction. For example, a message ‘employee added successfully’ is displayed when employee information is added in the application. There might be multiple response messages for a single transaction. However, all such messages are considered as only one DET per transaction. Additional one DET is counted for all means of initiating a transaction. Example of such triggers is clicking the ‘Save’ button after entering the information in a form. Again, it is obvious that a transaction can be triggered in multiple ways like clicking a button, pressing the shortcut keys, by hovering the mouse on a field, etc. In FPA, all such triggers are counted only once per transaction. As a rule of thumb, just add two DETs to the number of unique, user-recognizable attributes that crosses the boundary during a transaction. In the next slide, we will cover the exclusions while counting the DETs for transaction functions.

## 4.15 DET Exclusions for Transaction Functions

As the definition of DET for transaction function suggests, they are those unique, user-recognizable attributes that crosses the boundary of any application. Thus, those attribute that are generated within the boundary and saved in an ILF, is not counted as a DET for the transaction function. For example, consider that percentage of marks in a subject has to be calculated and stored in the table, based on the marks entered. If these percentages are not displayed to the user, that is the attribute doesn’t cross the boundary, but is only saved in the data function, then this is not included as a DET. Literals like Report titles, column headings, screen identifiers, etc., are also not counted as DETs because these attributes don’t cross the boundary. Similarly, Application generated time stamps for date and time, pagination variables page numbers, navigation aids like ‘Next’, ‘First’, ‘Last’, etc., are also not counted as DETs for the same reason that these are just user interface controls, and no attributes crosses the application boundary. Moving on, let us be introduced to the File Type Referenced (FTR) for transaction functions in the next slide.

## 4.16 File Type Referenced for Transaction Function

In a transaction, Data function is read and/or maintained by a transactional function, ILF is read or maintained, and EIF is read. Data crosses the boundary to maintain an ILF, or to present information to the user. So it is obvious that the data has to be updated or retrieved from one or more of the data function. To identify the complexity of a transaction function, the numbers of such data functions that are read or maintained within the transaction are counted and these data functions are called File Type Referenced (FTR). Next slide describes the counting rule for FTRs of transaction functions.

## 4.17 Counting Rules for FTRs of Transaction Functions

It is one of the simplest counting rules in function point analysis, count one FTR for all unique data functions, either ILF or EIF that is read or maintained as part of the transaction. For example, consider that a report has to be generated with information of the number of employees in each job band. In this case, employee and job are two entity-independent data functions that are referred for generating the report, and thus there are two FTRs for the transaction. Let us identify the number of DETs and FTRs for the Currency Converter application in the next slide.

## 4.18 DETs and FTRs in Currency Converter

The transaction details and the type of the transactions in Currency Converter application is shown in the slide. In the case of external input – “Save Details”, the number of attributes that crosses the boundary are ‘Amount in dollars’, ‘Conversion Rate’ from the EIF, and the ‘Amount in Rupees’, that is, three DETs for the number of unique, user-recognizable attributes that crosses the boundary. In addition, two DETs for the transaction trigger and the response message, which makes it five DETs for this transaction. For the transaction to succeed the conversion rate has to be read from the EIF and the data has to be saved in the ILF. Thus, two data functions are read or maintained in the transaction making it two FTRs. Thus, five DETs and two FTRs for the “Save Details” External input. “Convert Currency” is an external output, where the number of DETs is five – which includes ‘Amount in Dollars’, ‘Conversion Rate’ from the EIF, ‘Amount in Rupees’, and the additional two DETs for the trigger and response message. However, note that no ILF is maintained in this transaction. Just the conversion rate is read from the EIF, making it one FTR. Thus, five DETs and one FTR are identified for this transaction. Only one attribute crosses the boundary for the “Get Conversion Rate” external query which makes three DETs and one FTR for the transaction. For the “View Log” and “Print Log” external queries, the number of DETs is four attribute DETs, plus two DETs for trigger and response message. The information is retrieved from the ILF and thus only one FTR is necessary. Thus, six DETs and one FTR identified each for “View Log” and “Print Log” transactions. Let us summarize this module in the next slide.

## 4.19 Summary

In this module we further broke down Data Functions into Data Element Types (DET) and Record Element Type (RET). Transaction functions were further broken into Data Element Types (DET) and File Type Referenced (FTR). DET for a Data Function are all the unique, user-recognizable, and non-repetitive attributes within the data function. RET are the subgroup of data within the data functions. These RETs are easily identifiable by identify attributive, associative and sub-type entity relationships within a data function. DET for Transaction Functions are all the unique, user-recognizable and non-repetitive attributes that crosses the boundary, trigger and response message during a transaction. FTRs are the unique data functions that are read from, or maintained during a transaction. In the next module, we will understand some tips and tricks to identify / count data and transaction functions, understand how Unadjusted Function Point is determined, rate the fourteen general system characteristics, and finally complete IFPUG Function Point Analysis.

Related Courses
Learner Reviews
• Disclaimer
• PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Name*
Email*
Phone Number*