Counting Scope, Application Boundary, Data Functions, and Transaction Functions Tutorial

3.2 IFPUG FPA Counting Scope Application Boundary Data Functions and Transaction Functions

Hello and welcome to software estimation course offered by Simplilearn. In the previous module, we were introduced to IFPUG function point analysis. This module continues from the previous module where some of the steps of the counting process will be covered in detail. Let us begin by looking into the agenda of this module.

3.3 Agenda

We will start this module with a quick recap of the FP counting process. We will then cover the steps – counting scope and application boundary in detail. We will end the module after understanding the identification rules for data and transaction functions. Each of these steps will be explained with the example of a simple case. In the next slide we will recap the FP counting process.

3.4 Recap of the FP Counting Process

In the previous module we covered the FP counting process, which starts with determining 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. In this module, we will be covering counting scope, application boundary and the identification rules for data and transaction functions in detail. However, before we get into the detailed counting process, let us consider the case of a simple currency converter application which we will use throughout function point analysis modules. This case is explained in the next slide.

3.5 Case Currency Converter Application

Consider that you have been asked to develop an application to convert currency entered in dollars to rupees. The user would input the amount in dollars and on clicking the ‘Convert’ button, the amount is converted to rupees, based on the current conversion rates. It is assumed that the conversion rates are retrieved from an external application. On clicking the ‘Show Conversion Rate’ button, the current conversion rate from the external application is retrieved, and displayed in the form. If the ‘Save’ button is clicked; the current date, amount in dollars, conversion rate, and amount in rupees are saved in a database The ‘Show Log’ button contains a log of the previously saved information which is displayed in a different window. Clicking the ‘Clear’ button, will clear the information entered in the first window. While clicking the ‘Close’ button, closes the application. On clicking the ‘Print’ button, the log is sent to the printer and the displayed log is printed. Counting scope is dealt with in detail in the next slide.

3.6 Counting Scope

The first step in function point analysis is to collect all possible documentation available on the project, or the application being counted. These documentations either describe the functionality delivered by the software, or the functionality developed by the project being measured. Documentation may include requirements, class diagrams, data flow diagrams, use cases, etc. The documentation can also include requirements or specifications of similar applications, user manuals, prototypes, etc. In the absence of any documentation, any Subject Matter Expert on the application domain can be contacted to provide valuable inputs during the counting process. The second step is to determine the type of function point count to be used. As covered in the previous module, functional size measurement aims at providing answer to a business question. Based on the purpose, the function point count can be development FP, enhancement FP, or application FP. Finally, the counting scope defines the set of functional user requirements to be included in the function point count. Thus, the scope of a development function point count would include all the functionality being built by the project. The scope of an enhancement function point count would include all the added, changed, and deleted functionalities. The scope of the application function point count would either include the functionalities of the application being used by the user, or all the functions in the application based on the purpose of the count. In the next slide we will identify the counting scope for the currency converter example.

3.7 Counting Scope for Currency Converter

In the case of the currency converter example, the available documentation is only the set of functionalities or requirements given. In addition to this, a basic understanding of how currency conversion takes place is necessary. Since this application is being developed afresh, the type of the FP count is development function point count. It cannot be enhancement function point count because no functionality is being added, modified, or deleted from an existing application. Application function point count is not chosen because the purpose of the count is to determine the functional size of the application and not the installed size. The application is being newly constructed and not in production to deter mine the application function point count. Finally, the purpose of the counting is to measure the baseline functional size of the listed requirements. To summarize, counting scope basically helps to draw the application boundary around the application being counted. In the next slide we will discuss application boundary in detail.

3.8 Application Boundary

The counting scope helps to draw the application boundary. Application boundary is a logical “membrane” surrounding the application under study and its external environment. The external environment here refers to the users of the particular application, as well as any other applications from where information is referred. Do note that this is a “logical” boundary. The positioning of the boundary between the software under investigation, and other software applications may be subjective. By defining the application boundary clearly around the application, it becomes easier to define which functionality needs to be counted and which are external to the application. The application boundary encloses the logical data maintained by the application. Every application has some internal storage, and the application boundary helps to demarcate the internally maintained logical data, to the data referenced from external applications. More specifically, application boundary helps to identify the Internal Logic Files (ILFs). In addition to identifying Internal Logic Files, the application boundary is also a key to identify the data being referenced from external applications, that is, the External Interface Files (EIFs). The data from the various transactions pass in and out of the application boundary. The transactions are invoked by various users of the application, and are basically the three transaction functions – External Inputs (EI), External Queries (EQ), and External Output (EO). The application boundary is determined based on the user’s business view of the application and not on the technical, or implementation point of view. Function point analysis measures the functional size of a software application, based on the user’s point of view. Thus, it is important to define the application boundary from the user’s perspective, and not from a technical perspective. It is important that the boundary is placed with care, since all data crossing the boundary can potentially be included in the scope of the count. In the next slide, we will define the application boundary for the currency converter example.

3.9 Application Boundary for Currency Converter

As defined in the requirements, the currency converter application basically converts the entered amount in dollars to equivalent amount in rupees. The transactions are stored within the application for future reporting. The core functionality of the application is to convert the currency and store the information. Thus, from the user’s logical point of view, the application should have an internal storage for the transactions performed. It is also mentioned that the currency conversion rates are referenced from an external application– the Conversion Rate Feeder. Then there are users who input data and retrieve data from the application. Thus, the logical application boundary would encompass the primary storage of the currency converter application. As evident from the image in the slide, the application boundary clearly demarcates the logical data maintained within the application, the logical data referenced from an external application, and the data being passed into and out of the application. In the next slide, we will be introduced to the concept of data functions in IFPUG function point analysis.

3.10 Data Functions

The next step in the function point analysis process after identifying the counting scope and application boundary is to identify and rate data function. Rules for rating the data functions will be covered in the next module. A data function represents the functionality provided to the user to meet internal and external data storage requirements. It is common to have the application provide functionality to store data internally, or refer data stored in an external application. Data functions aim to measure the size of these storage functionalities. A data function can be either an Internal Logic File (ILFs), or an External Interface Files (EIFs). Do note that the term file here doesn’t refer to physical files. Files refer to a logically-related group of data, and not the physical implementation of those groups of data. The data function is a user-identifiable and logically-related data within the counting scope. User-identifiable refers to those data functions which are mentioned in the requirements, and is understood by the users and the software developers. Logically-related refers to information that is entity-dependent. While identifying data functions, entity-dependent information has to be logically grouped, and considered within the same data function. Identification rules for data functions are discussed in detail in the following slide.

3.11 Identification Rules for Data Functions

Consider the example of employee, and dependent’s information. A dependent’s information can’t exist without the Employee’s. Thus employee and dependent’s information are “Entity Dependent” entities, and so are counted as a single data function. Remember that data functions are a logical group of related data. In the actual implementation, employee and dependent information might be stored in two different database tables. However, in IFPUG function point analysis, these data are considered to be the part of a single logical data function. Now, consider the example of employee and job information. A job can exist without any employee assigned to it. Thus, employee and job information are “Entity Independent”, and are hence considered as two separate logical data functions. While identifying the data functions, care has to be taken to exclude “Code Data” as a data function. Examples of code data include substitution data entities, single occurrence entities, default value entities, and valid value entities. Substitution data entities refer to those entities that contain information of a code and an explanatory name or description. For example, a table consisting of code for city name and detailed description against each code – BLR – Bangalore, CHN – Chennai, etc. Single occurrence entities are those static entities that rarely change. Default value entities are those entities that contain values for populating certain attributes. For example – there might be a table containing default values for attributes like gender – male, country – India, marital status – single, etc. Valid values entity contains available values for selection or validation. For example, a table that contains valid value entries for attributes like gender – male or female, marital status – single or married, employment type – permanent or contract, etc. These code data entities should not be considered as a data function. While identifying data functions, those entities that contain data not required by the users should be excluded. There might be a few data that is required from the technical implementation point of view. Such entities should not be considered as a data function. It should be kept in mind that the data function has to be user-recognizable. There might be few tables where additional attributes of an entity is stored along with a foreign key. Such an entity should not be counted separately, but should be counted together with the parent entity. For example, consider that there are two tables, where in the first table, an employee’s name, gender, and location is stored; and in the other table, the employee’s date of birth is stored along with a foreign key reference. These two tables represent the attributes of a logically single entity – the employee – and so should be considered together. Such instances where attributes of a single entity is stored in two or more tables with a foreign key have to be grouped together and should be considered as a single data function. Let us understand the specific identification rules for Internal Logic Files, and External Interface files in the next slide.

3.12 ILF vs EIF

ILFs are those data functions that reside within the application boundary, whereas EIFs are those data functions that reside outside the application boundary. The primary intent of the ILFs is to store data maintained within the application, and the primary intent of EIFs is to store data that will be referenced by the application being measured. The EIF of the application being measured would be an ILF of another application. That is, the data function being identified as an EIF would be an ILF for another application, with a different application boundary and counting scope. The primary difference between an internal logical file and an external interface file is that an EIF is not maintained by the application being measured, while an ILF is maintained by the application being measured. In the next slide, we will identify the ILF and EIF for the currency converter application.

3.13 ILF and EIF in Currency Converter

As evident from the image in the slide and the application boundary, there is only one ILF and one EIF in this example. The storage used to maintain the log of conversions made by the user is the ILF, and the storage from where the conversion rates are fed into the application is the EIF. Both these data functions are user-recognizable and logically related information, and hence are valid data functions. Let us look into transaction functions in the next slide.

3.14 Transaction Functions

Users interact with the software application using transactions. The input and output transactions make up the software application, in addition to the storage. Transaction functions represent the functionality provided to the user to input, and retrieve data from the application. Transaction functions here can be External Inputs (EI), External Output (EO), and External Queries (EQ). Note the word “external” in each of the transaction function. This is because the data passes from outside the application boundary to within, or from within to outside the boundary. Transaction functions are the unique and user-recognizable elementary processes that satisfy functional user requirements. The explanation to the user-recognizable is similar to what was detailed for data functions. Thus, to identify transaction functions, it is important to understand the elementary processes, which will be covered in the next slide.

3.15 Elementary Processes

To identify the elementary processes, the function user requirements have to be broken into the smallest unit of activity. For example, if there is a requirement to maintain employee information, what this basically means is that the application should be able to add, view, modify, and delete employee information. Each of these is individual units of activities, and should be considered as individual elementary processes. The activity should be meaningful to the user. This is synonymous with the definition of a transaction function, which describes that it has to be user-recognizable. The examples related to employees are all logical and meaningful to the user of the application. Each of the elementary processes should constitute a complete transaction. For example, in the case of adding employee information, the set of activities that constitutes a complete transactions includes – clicking a button to add a new employee, filling the required information in a user form, clicking on the ‘save’ button, and finally getting a confirmation message from the system. These set of activities constitutes an entire transactions, and so should be considered as a single transaction function and not separately. Finally, the activity should be self-contained. What this means is that the identified activity should be independent and not depend on any other activity’s existence. In the next slide, we will cover the three transaction functions – EI, EQ, and EO.

3.16 EI EQ and EO

The transaction function is classified as EI, EO, or EQ, based on the primary intent of the elementary process under study. The three basic primary intents are “alter the behavior of the system”, “maintain one or more ILFs”, and “present information to a user”. These primary intents are summarized in the next slide after covering what transactions classify as External Inputs (EI), External Query (EQ), and External Output (EO). An external input is an elementary process that processes data, or control information sent from outside the boundary. What this means is that the data is passed from outside the boundary, either by users or other application, into one of the ILFs maintained within the application boundary. These transactions are usually data entry transactions like adding, modifying, deleting, inserting, etc. The primary intent of an EI is to maintain one or more ILFs, and to alter the behavior of the system. That is, every EI adds, modifies, and deletes data from one or more ILFs in the application, thereby alternating its behavior. An external query or external inquiry is an elementary process that sends data, or control information from inside the application boundary to outside. The primary intent of an EQ is to retrieve data and present the data to the user. Point to note is that the there is no processing logic, calculations, algorithms involved during the retrieval and reporting process. Example of EQs are viewing information, searching for a record, generating a dump of records, etc. An EQ doesn’t maintain an ILF, nor does it alter the behavior of the system. An external output is an elementary process that sends the data, or control information from inside the application boundary to outside and during the process, performs some additional processing of logic, algorithms, or calculations. EO is similar to EQ except that the data retrieved from an EO contains some calculations or algorithms. The primary intent of an EO, like an EQ, is to present information to the user. The processing logic should contain at least one mathematical formula, calculation, or create derived data based on some algorithm. An EO, like an EI, maintains one or more ILFs, and alters the behavior of the application. Some examples of EO are display calculated values, graphical representation of data, etc. The next slide summarizes the primary intents, and their applicability to the three transaction functions.

3.17 Primary Intents of Transaction Functions

As seen in the slide, the primary intent of an external input is to maintain one or more ILFs, and alter the behavior of the system. The primary intents of EO and EQ are to present information to the user. The primary difference between the two is that the EO needs to have at least one mathematical calculation or algorithm thereby chances of maintaining one or more ILFs and altering the behavior of the application. In the next slide, we will identify the various transactions in the currency converter application.

3.18 Transaction Functions in Currency Converter

As seen in the image on the slide, there is only one external input in the application which is the “Save Details” transaction. This transaction saves the entered currency details in the only ILF of the application. The set of external queries in the application are “View Log”, “Get Conversion Rate”, and “Print Log”. Note that none of these transactions are maintaining any ILF, nor altering the behavior of the system. All these transactions do is present some information to the user. There is only one external output in the application which is the “Convert Currency” transaction. This transaction multiplies the amount entered in dollars with the conversion rate, displays the amount in rupees, and thus this is an EO. Do note that ‘Clear’ and ‘Close’ buttons are not associated with any transaction functions. Unless data passes from outside to inside the boundary, or from inside to outside, the transaction cannot be classified as a transaction function. Let us summarize this module in the next slide.

3.19 Summary

We started off this module with a recap of the FPA counting process, which starts with determining the counting scope and the application boundary. We then covered the counting scope which basically includes collecting available documentations, deciding upon the type of function point count – either development, enhancement, or application function point count; and finally determining the purpose of the measurement exercise. Then we understood application boundary which is a logical “membrane” surrounding the application under study and its external environment. The application boundary helps to identify and classify the various data and transaction functions in the application. Post this; we found out the identification rules for data functions which include Internal Logic Files (ILF), and External Interface Files (EIF). All logically related set of data has to be grouped into data functions, and has to be classified as an internal logic file or external interface file, based on where the data function resides. If the data function is maintained within the application boundary, it is an internal logic file, and if the data functions are outside the application boundary, it is an external interface file. We ended the module with the identification of rules for transaction functions. The functional user requirements are broken into smaller unit of activities called as elementary processes, and are classified as external inputs, external queries, or external output. An external input is an elementary process that processes data sent from outside the boundary. External Query and External Output sends data from inside the application boundary to outside. The prime difference between EQ and EO is that EO contains at least one mathematical calculation or derives data based on some algorithm. We will understand the counting rules for the data and transaction functions in the next module.

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

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*