0004 - 3 Part 4 (2009-09-01)

Part 4 – Examples
This page intentionally left blank.

Part 4 Examples
Introduction Part 4 provides examples of data functions and transactional functions to
illustrate the counting rules from Part 1. The examples provide:
• A description of the data or transactional function
• The basis for the measurement
• The tables to be used in applying the counting rules
• The identification of the functional complexity
• The contribution to the functional size
Contents Part 4 includes the following sections:
Topic Page
Data Function Counting Examples 1-3
ILF Counting Examples 1-7
EIF Counting Examples 1-37
Transactional Function Counting Examples 2-1
Elementary Process Identification Examples 2-7
EI Counting Examples 2-25
EO Counting Examples 2-59
EQ Counting Examples 2-89
January 2010 Function Point Counting Practices Manual 1-1

This page intentionally left blank
1-2 Function Point Counting Practices Manual January 2010

Part 4 Chapter 1
Data Function Counting Examples

Introduction This section uses several examples to illustrate procedures for measuring data
functions, each of which stands on its own.
Note: Each example shows only the requirement specific to the situation
being illustrated, although in practice we must evaluate all
requirements and their functional impact.
This section uses a Human Resources (HR) application along with a Security
application and a Mail Distribution application to illustrate procedures to
identify and measure data functions. In addition to this section, examples are
in the Case Studies which are included in the IFPUG supplementary
documentation.
Note: The examples in this section and throughout the manual have two
purposes:
1. To illustrate how the function point counting rules are applied for a given
set of user requirements
2. To allow you to practice using the counting procedures
Each counter must:
• Analyze the specific user requirements that apply for each project or
application being measured, and
• Count based on those requirements.
Contents This section explains the organization of the examples and includes detailed
examples for counting ILFs and EIFs.
Topic Page
Data Function Counting Examples 1-3
ILF Counting Examples 1-7
EIF Counting Examples 1-37

Data Function Counting Examples Part 4 - Examples
Organization of the Counting Examples
This section explains how the examples are presented.
Outline of the Organization

The following list outlines the sequence of information in the detailed
examples.
For each example:
1. Data functions are identified.
2. Data functions are classified as either ILFs or EIFs.
3. The RETs and DETs that contribute to the functional complexity are
identified and counted.
Diagram of the Organization

The following diagram illustrates the organization of the examples.
Example Example
Identify ILFs Identify EIFs
Count RETs/DETs Count RETs/DETs
Count for Each Example
Each example includes the following components:

1. Basis for the measurement
2. Tables applying the counting rules

Part 4 - Examples Data Function Counting Examples
Diagram of The following diagram illustrates the components for each example and the
Components flow of information.
Basis for the Measurement
Counting Rules Table

Identify ILF or EIF
For Each Identified ILF or EIF,

Count RETs and DETs

Data Function Counting Examples Part 4 - Examples
Basis for the The basis for the measurement begins each example. As shown in the
Measurement diagram of components, the measurement may be based on the following
components:
• User requirements
• Data and process models
• Windows, screens, or reports
Note: All components in the diagram are not included in all examples. In
some examples, the requirements stand alone as the basis for the
measurement. Other examples include a data or process model,
windows, screens, and reports.
Counting The analysis to identify functions is presented in a table that lists the counting
Rules Table rules for the function type. The rules are applied to the components that make
up the basis for the measurement. The analysis is explained in the table in the
column "Does the Rule Apply?".
Note: If all the rules apply, the example is counted as an ILF or EIF.
The next table shows the rules and explanation for the complexity for each
function type identified.

ILF Counting Examples
Introduction This section uses a Human Resources (HR) application to illustrate

procedures to identify and measure data functions. In addition to this section,
further examples are in the Case Studies which are included in the
supplementary IFPUG documentation.
Contents This section includes the following examples:
Topic Page
Summary Descriptions of ILF Counting Examples 1-8
Example: Audit Data for Inquiries and Reports 1-9
Example: Report Definition 1-15
Example: Alternate Index 1-20
Example: Shared Application Data 1-21
Example: Different Users/Different Data Views 1-29

ILF Counting Examples Part 4 - Examples
Summary Descriptions of ILF Counting Examples
The examples for ILFs are described in the following table.
Example Summary Description Page

Audit Data This example shows the analysis and 1-9
measurement of data that is retained for audit
purposes.
Report Definition This example shows counting user defined 1-15
report definitions maintained within an
application.
Alternate Index This example illustrates the analysis of user 1-20
requirements for the report definition example
that focuses on the requirements for physical
implementation.
Shared This example shows counting data that is 1-21
Application Data maintained by more than one application.
Different This example shows that two applications can 1-29
Users/Different count the same file with different DETs.
Data Views

Part 4 - Examples ILF Counting Examples
Example: Audit Data for Inquiries and Reports
User Analysis of the following user security requirements showed a need for audit
Requirements data:
1. Allow or deny user access to each screen in the application.
2. Change a user's access to each screen.
3. Report on any screen security added or changed using the following data:
− Identification of the user who is adding or changing security
information
− The user and screen security that was added or changed
− The user and screen security images before and after a change was
made
− Date and time the add or change occurred.
4. Capture audit data to monitor and report daily security activity. This
requirement was determined when a design was implemented to satisfy
the user's screen security requirements.
ERD
Legend:
Entity Type
Attributive Entity Type
Optional One-to-Many Relationship

Data Flow
Diagram
Report info
Request Report
User date, time, user id,

Before, after
date, time,
user id,
before, after
Screen
Screen
1.1
Security
Add screen security info
Audit
Add Screen
Security 1.3
user ID, SS#,
access allowed, user id, Report Security
window ID date, time, Changes
before, after
Screen
Screen
Security change 1.2
screen
security Change Screen
info Security
Change screen security info
Legend:
User or Application
Data Stored
Process
Flow of Data

Step 1 Identify Data Functions

Use the Data Function Identification rules to determine whether Screen
Security Audit data is a data function. The following table shows the analysis
for Screen Security Audit data.
Data Function Identification Rules Does the Rule Apply?
1. Identify all logically related and user Screen Security and Screen Security
recognizable data or control Audit.
information within the counting scope
2. Entities that are entity independent are There are no entities of this type.
considered to be separate logical
groups of data.
3. Group related entities that are entity Screen Security and Screen Security Audit
dependent are related. Screen Security Audit is
dependent upon Screen Security. They are
grouped together into a single data
function.
4. Exclude those entities referred to as There are no entities of this type.
code data
5. Exclude entities that do not contain There are no entities of this type.
attributes required by the user
6. Remove associative entities that There are no entities of this type.
contain additional attributes not
required by the user and associative
entities that contain only foreign keys;
group foreign key attributes with the
primary entities
The Screen Security Audit is not counted as a data function on its own
because it is dependent upon Screen Security. Screen Security Audit is part of
the Screen Security data function.

Step 2 Classify Data Functions

The following table shows the analysis to determine whether the Screen
Security information is classified as an ILF.
Data Function Classification Rules Does the Rule Apply?
1. Classify as an ILF if the data is The Screen Security data function is

maintained by the application being maintained within the application.
measured
2. Classify as an EIF, if it: Classified as an ILF; consequently, no
EIFs are identified.
• Is referenced, but not maintained,
by the application being measured
and
• Is identified in an ILF in one or
more other applications
Based on the analysis, the Screen Security information is classified as an ILF.
Step 3 Count DETs

For DETs, look at each attribute associated with the Screen Security ILF and
determine whether the DET counting rules apply.
The Screen Security ILF includes:
• User ID
• SS #
• Window ID
• Access Allowed
• Date Change Made
• Time Change Made
• Before Image
o User ID Before
o Window ID Before
o Access Allowed Before
• After Image
o User ID After
o Window ID After
o Access Allowed After

The analysis of the DETs for the Screen Security ILF is shown below:
Data Function DET Counting Rules Does the Rule Apply?
1. Count one DET for each unique user User ID, SS #, Window ID, Access
recognizable, non-repeated attribute Allowed, Date Change Made and
maintained in or retrieved from the data Time Change Made.
function through the execution of all
elementary processes within the counting
scope
2. Count only those DETs being used by There are no attributes of this type.
the application being measured when
two or more applications maintain and/or
reference the same data function
3. Count one DET for each attribute There are no attributes of this type.
required by the user to establish a
relationship with another data function
4. Review related attributes to determine if User ID Before, Window ID
they are grouped and counted as a single Before and Access Allowed Before
DET or whether they are counted as are grouped and counted as Before
multiple DETs; grouping will depend on Image. The same is also done for
how the elementary processes use the the After Image attributes.
attributes within the application
Step 4 Count RETs

For RETs, identify subgroups based on the RET counting rules.
RET Counting Rules Does the Rule Apply?
1. Count one RET for each data Count one RET for the Screen Security
function (i.e., by default, each data ILF.
function has one sub-group of
DETs to be counted as one RET)
2. Count one additional RET for each
of the following additional logical
sub-groups of DETs (within the
data function) that contains more
than one DET:
• associative entity with non-key There are no entities of this type.
attributes
• sub-type (other than the first There are no entities of this type.
sub-type) and
• attributive entity, in a Screen Security Audit is an attributive
relationship other than entity in an optional 1-M relationship.
mandatory 1-1 Count an additional RET for Screen
Security Audit.

The RET and DET totals for Screen Security are shown in the following
table.
RETs DETs
• Screen Security • User ID
• Screen Security Audit • SS #
• Window ID
• Access Allowed
• Date Change Made
• Time Change Made
• Before Image
• After Image
Total 2 RETs Total 8 DETs
Step 5 Determine Functional Complexity
2 RETs and 8 DETs Complexity is Low
Step 6 Determine Functional Size
Functional Size of 1 Low ILF 7 FP

Example: Report Definition
User The user requires the ability to perform the following activities:
Requirements 1. Enter a report definition which includes
− A unique report identifier

− A report name
− Attributes used on the report
− Calculations to generate the report.
2. Reuse the defined report at any time, changing the definition if
necessary.
3. View and print a report using the report definition.
4. Inquire on existing report definitions by report name or report identifier.


From the user requirements, report identifier, report name, attributes on the
report, and calculations together make up one logical grouping of data for a
report definition because they are maintained as a group.
The following table shows the analysis to determine whether the report
definition information is a data function. See the Case Studies for how the
remaining requirements may be counted.
1. Identify all logically related and user Report Definition.
recognizable data or control
groups of data.
3. Group related entities that are entity There are no entities of this type.
dependent
4. Exclude those entities referred to as Report Definition information is not an
code data instance of code data. The entity is used
for reference in generating reports,
consists of more than just a code and
description and is changed as needed by
the user.
primary entities


The following table shows the analysis to determine whether the Report
Definition information is classified as an ILF. See the Case Studies for how
the remaining requirements may be counted.
1. Classify as an ILF if the data is The Report Definition data function is

maintained by the application being maintained within the application.
measured
and
Based on the analysis, the Report Definition information is classified as an

ILF.
Step 3 Count DETs

For DETs, look at each attribute associated with the Report Definition ILF
and determine whether the DET counting rules apply.
The Report Definition ILF includes:
• Report Identifier
• Report Name
• Attributes
• Calculations

The analysis of the DETs for the Screen Security ILF is shown below:

1. Count one DET for each unique user Report Identifier, Report Name,
recognizable, non-repeated attribute Attributes, Calculations. Although
maintained in or retrieved from the data there are multiple occurrences of
function through the execution of all both Attributes and Calculations,
elementary processes within the counting they are each counted as only one
scope DET.
4. Review related attributes to determine if There are no attributes of this type.
they are grouped and counted as a single
DET or whether they are counted as
multiple DETs; grouping will depend on
how the elementary processes use the
Step 4 Count RETs

1. Count one RET for each data Count one RET for the Report
function (i.e., by default, each data Definition ILF.
than one DET:
attributes
sub-type) and
• attributive entity, in a There are no entities of this type.
relationship other than
mandatory 1-1

The RET and DET totals for report definition are shown in the following
table.
RETs DETs
• Report Definition group • Report Identifier
• Report Name
• Attributes
• Calculations
Total 1 RET Total 4 DETs

Example: Alternate Index
User The user needs to inquire on report definitions using the report name as the
Requirements key to finding the desired definition. To satisfy the user requirement, an
alternate index is created using the report name as the key.

The following table shows the summary analysis to determine whether the
alternate index is an ILF.
1. Identify all logically related and user No. From the user perspective, this filter
recognizable data or control function provides the user with specific
information within the counting scope attributes of the report definitions created
that reference the Report Definition ILF.
This technical filter, necessary to create
the inquiry list, does not constitute a
business function on its own.
2. Entities that are entity independent are Not applicable.
groups of data.
3. Group related entities that are entity Not applicable.
dependent
4. Exclude those entities referred to as Not applicable.
code data
5. Exclude entities that do not contain Not applicable.
6. Remove associative entities that Not applicable.
primary entities
Based on the analysis in the table, the alternate index is not a logical group;
therefore, it is not counted as an ILF.

Example: Shared Application Data
User The HR user requires the ability to maintain information on each new
Requirements employee.
The information that must be maintained by the HR user includes:
• Employee ID
• Employee Name
• Employee Mailing Address
• Employee Pay Grade
• Employee Job Title
* As a result of creating a new employee record, the employee’s anticipated
Pension Eligibility Date should be automatically calculated and saved with
the other employee information.
The Security user requires that a security level be assigned to each new
employee. The Security department conducts a background search after each
employee is hired and assigns the appropriate organizational security
authorization level. This is not application security which determines the
access of individual users within the application.
The information that must be maintained by the Security user includes:
• Employee ID
• Organizational Security Authorization Level
The Security user also requires a report listing the following information:
• Count of Employee IDs
• Employee Name
• Employee ID

Data Flow The following diagram shows the data flow for this example.
Diagram

Step 1 Identify Data Functions (for HR application)

Determine whether the Employee information is a data function for the HR
application. The following table shows the summary analysis.
1. Identify all logically related and user Employee.
groups of data.
dependent
code data
primary entities
Step 2 Classify Data Functions (for HR application)

Determine whether the Employee information is classified as an ILF for the
HR application.
1. Classify as an ILF if the data is The Employee data function is maintained
maintained by the application being within the HR application.
measured
and
The analysis shows that the Employee information is an ILF for the HR
application.

Step 3 Count DETs (for HR application)

For DETs, look at each attribute associated with the Employee ILF in the HR
application and determine whether the DET counting rules apply.
The following list includes the attributes for the Employee information:
• Employee ID
• Employee Name
• Pension Eligibility Date
The analysis of the DETs for the Employee ILF in the HR application is
shown below:

1. Count one DET for each unique user The following attributes satisfy this
recognizable, non-repeated attribute rule:
maintained in or retrieved from the data • Employee ID
function through the execution of all • Employee Name
scope
2. Count only those DETs being used by All of the attributes are used within
the application being measured when the HR application except
two or more applications maintain and/or Organizational Security
reference the same data function Authorization Level.

Step 4 Count RETs (for HR application)

1. Count one RET for each data Count one RET for the Employee ILF.
function (i.e., by default, each data
than one DET:
attributes
sub-type) and
mandatory 1-1
The RET and DET totals for the Employee ILF in the HR application are
shown in the following table.
RETs DETs
• Employee information group • Employee ID
• Employee Name
Step 5 Determine Functional Complexity (for HR application)
1 RET and 6 DETs Complexity is Low
Step 6 Determine Functional Size (for HR application)

Step 1 Identify Data Functions (for Security application)

Determine whether the Employee information is a data function for the
Security application. The following table shows the summary analysis.
groups of data.
dependent
code data
primary entities
Step 2 Classify Data Functions (for Security application)

Determine whether the employee information is classified as an ILF for the
Security application.
maintained by the application being within the Security application.
measured
and
The analysis shows that the Employee information is also classified as an ILF
for the Security application.

Step 3 Count DETs (for Security application)

For DETs, look at each attribute associated with the employee ILF in the
Security application and determine whether the DET counting rules apply.
The employee ILF includes:
• Employee ID
• Employee Name
The Analysis of the DETs for the Employee ILF in the Security application is
shown below:

• Organizational Security
scope
Authorization Level
2. Count only those DETs being used by Only the Employee ID, Employee
the application being measured when Name and Organizational Security
two or more applications maintain and/or Authorization Level are used by
reference the same data function the Security application.

Step 4 Count RETs (for Security application)

than one DET:
attributes
sub-type) and
mandatory 1-1
The RET and DET totals for the Employee ILF in the Security application
are shown in the following table.
RETs DETs
• Employee Name
• Organizational Security
Authorization Level
Step 5 Determine Functional Complexity (for Security application)
Step 6 Determine Functional Size (for Security application)

Example: Different Users/Different Data Views
User The information that must be maintained by the HR user includes:

Requirements
• Employee ID
• Employee Name
The Employee Mailing Address maintained in the Employee data store
consists of Floor, Building Code, Street, City, State and Zip Code;
however, the HR application uses Mailing Address as a single attribute.

• Pension Eligibility Date *
* As a result of creating a new employee record, the employee’s anticipated

Pension Eligibility Date should be automatically calculated and saved with
the other employee information.
The HR user requires the ability to produce mailing labels for each
employee.
The Mail Distribution user requires the ability to maintain the Building
Codes for each employee to reflect changes in the recognized codes.
The Mail Distribution user also requires the ability to evaluate the population
in each site to determine the most efficient process for delivering the internal
mail. A report is produced listing the number of employees located on each
floor for each building.
The information that must be maintained or referenced by the Mail
Distribution user includes:
• Employee ID
• Floor
• Building Code
Other attributes (e.g., Organizational Security Level) exist within the
Employee entity, but they are not referenced or maintained by either the HR
application or the Mail Distribution application.

Diagram
Step 1 Identify Data Functions (for HR application)

Determine whether the Employee information is a data function for the HR
application. The following table shows the summary analysis.
groups of data.
dependent
code data

Step 2 Classify Data Functions (for HR application)

HR application.
maintained by the application being within the HR application.
measured
and
The analysis shows that the Employee information is an ILF for the HR
application.
Step 3 Count DETs (for HR application)

For DETs, look at each attribute associated with the Employee ILF in the HR
application and determine whether the DET counting rules apply.
Employee information includes:
• Employee ID
• Employee Name
• Employee Mailing Address (Employee Mailing Address (Floor, Building
Code, Street, City, State & Zip Code)
• Organizational Security Level

The analysis of the DETs for the Employee ILF is shown below:
scope
2. Count only those DETs being used by Only the Employee ID, Employee
the application being measured when Name, Employee Mailing Address,
two or more applications maintain and/or Employee Pay Grade, Employee
reference the same data function Job Title, and Pension Eligibility
Date are used by the HR
application. The Organizational
Security Level attribute was not
counted as a DET, because it is not
used by the HR application.
4. Review related attributes to determine if Employee Mailing Address is
they are grouped and counted as a single counted as a single DET.

Step 4 Count RETs (for HR application)

than one DET:
attributes
sub-type) and
mandatory 1-1
The RET and DET totals for the Employee ILF in the HR application are
RETs DETs
• Employee Name
Step 5 Determine Functional Complexity (for HR application)
Step 6 Determine Functional Size (for HR application)

Step 1 Identify Data Functions (for Mail Distribution application)

Determine whether the Employee information is a data function for the Mail
Distribution application. The following table shows the summary analysis.
groups of data.
dependent
code data
primary entities
Step 2 Classify Data Functions (for Mail Distribution application)

Mail Distribution application.
maintained by the application being within the Mail Distribution application.
measured
and
The analysis shows that the Employee information is an ILF for the Mail
Distribution application.

Step 3 Count DETs (for Mail Distribution application)

For DETs, look at each attribute associated with the Employee ILF in the
Mail Distribution application and determine whether the DET counting rules
apply.
Employee information includes:
• Employee ID
• Employee Name
• Employee Mailing Address (Floor, Building Code, Street, City, State &
Zip Code; In the Mail Distribution application Floor and Building Code
are used as separate attributes.)
The analysis of the DETs for the Employee information in the Mail
Distribution application is shown below:
function through the execution of all • Floor
• Building Code
scope
2. Count only those DETs being used by Only the Employee ID, Floor, and
the application being measured when Building Code are used by the Mail
two or more applications maintain and/or Distribution application.
they are grouped and counted as a single Although Employee Mailing
DET or whether they are counted as Address was considered a single
multiple DETs; grouping will depend on attribute in the HR application, the
how the elementary processes use the two separate attributes (Floor &
attributes within the application Building Code) are counted as
separate DETs in the Mail
Distribution application.

Step 4 Count RETs (for Mail Distribution application)

than one DET:
attributes
sub-type) and
mandatory 1-1
The RET and DET totals for the Employee ILF in the Mail Distribution
application are shown in the following table.
RETs DETs
• Floor
• Building Code
Step 5 Determine Functional Complexity (for Mail Distribution application)
Step 6 Determine Functional Size (for Mail Distribution application)

EIF Counting Examples
Introduction This section uses a Human Resources (HR) application along with a Security
application and a Pension application to illustrate procedures used to measure
data functions. In addition to this section, further examples are in the Case
Studies included in the supplementary IFPUG documentation.
Topic Page
Summary Descriptions of EIF Examples 1-38
Example: Referencing Data from Other Applications 1-39
Example: Referencing Data from Another Application 1-43
Example: Providing Data to Other Applications 1-48
Example: Help Application 1-50
Example: Data Conversion 1-58
Example: Transaction Input File 1-60
Example: Different Users/Different User View 1-62
Example: Multiple Data Uses 1-66

EIF Counting Examples Part 4 - Examples
Summary Descriptions of EIF Examples
The examples for EIFs are described in the following table.
Referencing Data from This example identifies EIFs for an 1-39

Other Applications to application that references data maintained by
generate output another application. The data is used to
generate an external output.
Referencing Data from This example also looks at referencing data 1-43
Another Application to from another application. This example
use as part of an input identifies EIFs for an application that
process references data maintained by another
application to use for an external input.
Providing Data to Other This is another example of counting data 1-48

Applications referenced from a different application.
Help Application This is an example of counting a Help facility 1-50

within the HR application.
Data Conversion This is an example of counting when 1-58

converting to a new application.
Transaction Input File This example applies EIF counting rules to a 1-60
transaction input file processed to add jobs to
the Human Resources application.
Different Users/Different This example shows that the view differs 1-62
User View when an EIF is used by multiple applications.
Multiple Data Uses This example illustrates multiple uses for the 1-66
same data.

Part 4 - Examples EIF Counting Examples
Example: Referencing Data from Other Applications
User The user wants the Human Resources System to provide the ability to:
Requirements 1. Enter, inquire, and report employee information
2. Interface with the Fixed Assets System to retrieve location information

for each building. The location information includes name and
description information.

From the user requirements, there are two groups of information:
• Employee information
• Location information
Employee information is a data function.
1. Identify all logically related and user Employee and Location.
groups of data.
dependent Employee and Location are entity
independent of each other.
code data
primary entities
Based on the analysis, Employee and Location are each identified as a data
function.

Step 2 Classify Data Functions (for Employee information)

Determine whether the Employee information is classified as an EIF for the
HR application.

maintained by the application being within the application.
measured
and
Based on the analysis, the Employee information is not external to the HR

application. It is maintained internally; therefore, it is not an EIF.
Step 2 Classify Data Functions (for Location information)

Determine whether the Location information is classified as an EIF for the
HR application.
1. Classify as an ILF if the data is The Location data function is not

maintained by the application being maintained within the HR application.
measured
2. Classify as an EIF, if it:
• Is referenced, but not maintained, The Location data function is referenced,
by the application being measured but not maintained, by the HR application
and for use in employee reporting.
• Is identified in an ILF in one or At first, it is not clear whether Location
more other applications information is maintained in another
application. After asking users, we learn
that they enter the information into the
Fixed Asset application using a screen.
Therefore, the Location information is an
ILF for the Fixed Asset application and an
EIF for the HR application.
Based on the analysis, the Location information is classified as an EIF for the
HR application.

Step 3 Count DETs (for Location)

For DETs, look at each attribute associated with the Location EIF and
determine whether the rules apply.
The following attributes are referenced from the location EIF:
• Building Code
• Building Name
• Building Description
• Line 1
• Line 2
• Line 3
• City
• State
• Country
The following table shows the summary analysis of the DET count.
1. Count one DET for each unique user Building Code, Building Name,
recognizable, non-repeated attribute Building Description, City, State
maintained in or retrieved from the data and Country. The repeating lines of
function through the execution of all Building Description are counted
elementary processes within the counting as only one DET.
scope

Step 4 Count RETs (for Location)

1. Count one RET for each data Count one RET for the Location EIF.
than one DET:
attributes
sub-type) and
mandatory 1-1
The RET and DET totals for the Location EIF are shown in the following
table.
RETs DETs
• Location data • Building Code
• Building Name
• Building Description (repeating
lines)
• City
• State
• Country
Step 5 Determine Functional Complexity (for Location)
Step 6 Determine Functional Size (for Location)
Functional Size of 1 Low EIF 5 FP

Example: Referencing Data from Another Application
User The user requires the Human Resources application to provide the following
Requirements capabilities:
• All hourly employees must be paid in United States dollars.
• When the user adds or changes employee information, the Human
Resources application must access the Currency application to retrieve a
conversion rate. After retrieving the conversion rate, the HR application
converts the employee's local standard hourly rate to a U.S. hourly rate
using the following calculation:
Standard Hourly Rate
= US Dollar Hourly Rate
Conversion Rate
Data Model The following diagram shows the relationships for this example.
Currency Application HR Application
EMPLOYEE
CONVERSION SALARIED_EMPL
RATE
HOURLY_EMPL
DEPENDENT
Legend:
Entity Type
Entity Subtype
Mandatory One-to-Many Relationship
The Currency Conversion information includes:

CURRENCY
Conversion_Rate_To_Base_Currency
Currency


From the requirements, there are two groups of information:
• Currency Conversion information
Currency Conversion information is a data function.
1. Identify all logically related and user Currency Conversion, Employee and
recognizable data or control Dependent.
groups of data.
3. Group related entities that are entity Currency Conversion is entity independent
dependent of the other entities. Dependent is entity
dependent on Employee.
4. Exclude those entities referred to as Although Currency Conversion data might
code data appear to be an instance of code data,
Country Code and Conversion Rate are
not substitutable (i.e., are not
interchangeable) for each other. Currency
Conversion information also changes
regularly, so it does not meet the criteria
of being essentially static.
primary entities
Based on the analysis, Currency Conversion and Employee are each

identified as a data function. Dependent is not a data function on its own, but
is part of the Employee data function.

Step 2 Classify Data Functions (for Employee)

The following table shows the analysis to determine whether the Employee
information is classified as an EIF.
1. Classify as an ILF if the data is Employee information is maintained by

maintained by the application being the HR application.
measured
• Is referenced, but not maintained, Classified as an ILF; consequently, no
by the application being measured EIFs are identified.
and
Based on the analysis, the Employee information is not external to the HR

application. It is maintained internally; therefore, it is not an EIF.
Step 2 Classify Data Functions (for Currency Conversion)

The following table shows the analysis to determine whether the Currency
Conversion information is classified as an EIF.
1. Classify as an ILF if the data is Currency Conversion is not maintained by

maintained by the application being the HR application.
measured
• Is referenced, but not maintained, The Currency Conversion data function is
by the application being measured referenced by the HR application for use
and in calculating an employee’s pay.
• Is identified in an ILF in one or Although Currency Conversion data might
more other applications appear to be an instance of code data,
Because the Currency application provides the conversion rate for the HR
application, the group of Currency Conversion data is an EIF for the HR
application.

Step 3 Count DETs (for Currency Conversion)

For DETs, look at each attribute associated with the Currency Conversion
EIF and determine whether the rules apply. The following table shows the
summary analysis of the DET count.
1. Count one DET for each unique user Conversion Rate, Currency.
recognizable, non-repeated attribute
maintained in or retrieved from the data
scope
2. Count only those DETs being used by All attributes are referenced by the
the application being measured when HR application.

Step 4 Count RETs (for Currency Conversion)

1. Count one RET for each data Count one RET for the Currency
function (i.e., by default, each data Conversion EIF.
function has one sub-group of DETs
to be counted as one RET)
sub-groups of DETs (within the data
function) that contains more than one
DET:
attributes
sub-type) and
mandatory 1-1
The RET and DET totals for the Currency Conversion information EIF are
RETs DETs
• Conversion information • Conversion Rate
• Currency
Step 5 Determine Functional Complexity (for Currency Conversion)
Step 6 Determine Functional Size (for Currency Conversion)

Example: Providing Data to Other Applications
User The user has the following requirements for the Currency application:
Requirements
• Maintain conversion rates for other currencies to U.S. dollars.
• Provide an interface to enable other applications, such as Human
Resources, to retrieve conversion information.

For this example, determine whether the Currency Conversion information is
a data function for the Currency application. The following table shows the
summary analysis.
1. Identify all logically related and user Currency Conversion.

recognizable data or control information
within the counting scope
considered to be separate logical groups
of data.
dependent
4. Exclude those entities referred to as Although Currency Conversion data might
code data appear to be an instance of code data,
6. Remove associative entities that contain There are no entities of this type.
additional attributes not required by the
user and associative entities that contain
only foreign keys; group foreign key
attributes with the primary entities

Step 2 Classify Data Functions (for Currency Conversion)

The following table shows the analysis to determine whether the Currency
Conversion information is classified as an EIF.
1. Classify as an ILF if the data is The Currency application maintains

maintained by the application being Currency Conversion data via transactions
measured from a wire service.
and
The Currency Conversion information is not external to the Currency

application; therefore, it is counted as an ILF rather than an EIF for the
Currency application. See the previous example in this chapter to review how
referencing Currency Conversion may be counted as an EIF.

Example: Help Application
User The user requires the Help system to provide:

Requirements 1. The ability to describe how each window is used to accomplish each
business function available on the window.
2. The ability to change window help.
3. The ability to set up a definition, default values, and valid values for each
attribute in the Human Resources application.
4. The ability to change field help.
5. The ability for the Human Resources application to retrieve window and
field help for display.
Window Help and Field Help are maintained independently. An entry may
exist in one type of help without existing in the other.
Data Flow The following diagram illustrates the data flow for this example.
Diagram
User
2.1
Human
Add window help Add Resources
Window Help Application
window id, help description window id

changes to
WINDOW HELP field id,
window 2.2 description,
help info
valid values,
Change default values
Change window help Window Help
2.3 window id, field id, description,

Add field help FIELD HELP
valid values, default values,
Add Field Help
2.4
Change field help
Change changes to field help info
Field Help
Legend:
User or Application Process
Data Stored Flow of Data


From the requirements for the Human Resources (HR) application, there are
two groups of data:
• Window Help
• Field Help
The following table shows the summary analysis to determine whether
Window Help and Field Help are data functions for the HR application.
1. Identify all logically related and user Window Help, Field Help.
groups of data.
3. Group related entities that are entity Window Help and Field Help are
dependent independent of each other. An entry may
exist in one entity without existing in the
other.
4. Exclude those entities referred to as Window Help and Field Help consist of
code data more than just code and description
attributes, are not used for substitution and
store data to support core user activity;
consequently, they are not considered
code data.
primary entities

Step 2 Classify Data Functions (for Window Help)

The following table shows the analysis to determine whether the Window
Help information is classified as an EIF.
1. Classify as an ILF if the data is Window Help is not maintained by the HR

maintained by the application being application.
measured
• Is referenced, but not maintained, The HR application references, but does
by the application being measured not maintain Window Help.
and
• Is identified in an ILF in one or The Help application has identified
more other applications Window Help as an ILF.
Window Help information is an EIF in the HR application because the

information is referenced by the HR application. Window Help is maintained
in the Help application, where it is counted as an ILF.

Step 3 Count DETs (for Window Help)

For DETs, look at each attribute associated with the window help and use the
DET counting rules to count DETs. The attributes for window help include:
• Window Identifier
• Business Function Description.
The following table shows the DET analysis for window help.
1. Count one DET for each unique user Window Identifier, Business
recognizable, non-repeated attribute Function Description.
maintained in or retrieved from the data
scope

Step 4 Count RETs (for Window Help)

1. Count one RET for each data Count one RET for Window Help.
DET:
• associative entity with non-key There are no entities of this type for
attributes either data function.
• sub-type (other than the first There are no entities of this type for
sub-type) and either data function.
• attributive entity, in a There are no entities of this type for
relationship other than either data function.
mandatory 1-1
The RET and DET totals for the Window Help EIF are shown in the
following table.
RETs DETs
• Window Help information • Window Identifier
• Business Function Description
Step 5 Determine Functional Complexity (for Window Help)
Step 6 Determine Functional Size (for Window Help)

Step 2 Classify Data Functions (for Field Help)

The following table shows the summary results of the analysis to determine
whether the Field Help is classified as an EIF.
1. Classify as an ILF if the data is Field Help is not maintained by the HR

maintained by the application being application.
measured
• Is referenced, but not maintained, The HR application references, but does
by the application being measured not maintain Field Help.
and
• Is identified in an ILF in one or The Help application has identified Field
more other applications Help as an ILF.
Field Help information is an EIF in the HR application because the

information is retrieved by the HR application. The Field Help information is
maintained in the Help application where it is counted as an ILF.

Step 3 Count DETs (for Field Help)

For DETs, look at each attribute associated with field help and use the DET
counting rules to count DETs. The following list shows the attributes for
Field Help:
• Window Identifier
• Field Identifier
• Field Description
• Default Values
• Valid Values
The following table shows the DET analysis for Field Help.
1. Count one DET for each unique user Window Identifier, Field Identifier,
recognizable, non-repeated attribute Field Description, Default Values,
maintained in or retrieved from the data Valid Values.
scope

Step 4 Count RETs (for Field Help)

1. Count one RET for each data Count one RET for Field Help.
DET:
• associative entity with non-key There are no entities of this type for
attributes either data function.
• sub-type (other than the first There are no entities of this type for
sub-type) and either data function.
• attributive entity, in a There are no entities of this type for
relationship other than either data function.
mandatory 1-1
The RET and DET totals for the Field Help EIF are shown in the following
table.
RETs DETs
• Field Help information • Window Identifier
• Field Identifier
• Field Description
• Default Values
• Valid Values
Step 5 Determine Functional Complexity (for Field Help)
Step 6 Determine Functional Size (for Field Help)

Example: Data Conversion
User An organization has purchased a new HR application package. The

Requirements organization is required to convert its employee file from its existing HR
System to a replacement system.
The old system did not provide the capability to maintain employee
dependent information. The dependent information is initialized when
existing employees are migrated to the new application.
Data Model The following diagram shows the data for the two applications.
Old New
HR Application HR Application
EMPLOYEE EMPLOYEE
SALARIED_EMPL SALARIED_EMPL
HOURLY_EMPL HOURLY_EMPL
DEPENDENT
Legend:
Entity Type
Entity Subtype
The Employee file from the old HR application is used to add employees to
the new HR application. The Employee file from the old HR application has
the primary intent to maintain (i.e., populate) the Employee file in the new
application. The Employee file from the old HR application does not meet
the primary intent of an EIF which is to hold data referenced through one or
more elementary processes.


From the user requirements, determine whether the old Employee file is a
data function. The following table shows the summary analysis.
1. Identify all logically related and user The old Employee file is not a logical
recognizable data or control information group of data from the user perspective.
within the counting scope
2. Entities that are entity independent are The old Employee file is an output (i.e.,
considered to be separate logical groups extract) from the prior application, rather
of data. than a logical file that is maintained.
dependent
code data
6. Remove associative entities that contain There are no entities of this type.
additional attributes not required by the
user and associative entities that contain
only foreign keys; group foreign key
attributes with the primary entities
The Employee information file is a transaction file of Employee information

that is migrated to the new system. The conversion process uses the
transaction file to maintain the Employee information after it enters the new
HR application.
The old Employee file is not a logical group of data from the new HR
application user’s perspective. The primary intent of the old Employee file is
to serve as an input to the new HR application, not to hold data used for
reference by one or more elementary processes of the new HR application;
therefore, it is not an EIF. Refer to EI/EO/EQ Counting Examples to see how
the old Employee file may be counted as an external input.

Example: Transaction Input File
User The user requires the ability to:

Requirements 1. Add, change, delete, inquire, and report on job information online
2. Add and change job information in batch mode.
Record The following diagram shows the record layout for this example for adding
Layout and changing job information in batch mode.
123456789101234567890123456789012345678901234567890123456789012345678901234567890
1 ADD⏐01⏐SRENG⏐SENIOR ENGINEER INFORMATION SYSTEMS ⏐05⏐

2 ADD⏐02⏐SRENG⏐01⏐STARTS AT PAY GRADE 05 ⏐
3 ADD⏐02⏐SRENG⏐02⏐OTHER PAY GRADES:06 AND 07 ⏐
4 CHG⏐01⏐STENG⏐ ⏐04⏐
5 CHG⏐02⏐STENG⏐02⏐OTHER PAY GRADES:05 AND 06 ⏐
6
7
9
0
Record The following table includes descriptions for each record type.
Descriptions
Record Position Description
01 1-3 Transaction Type
4-5 Record Type
6-10 Job Number
11-45 Job Name
46-47 Job Pay Grade
02 1-3 Transaction Type
4-5 Record Type
6-10 Job Number
11-12 Job Description Line Number
13-41 Job Description Lines


From the user requirements, determine whether the transaction file is a data
function. The following table shows the summary analysis.
1. Identify all logically related and user Yes. Data is grouped into transactions
recognizable data or control which enter the boundary to maintain the
information within the counting scope Job ILF.
2. Entities that are entity independent are The Transaction File is excluded. The
considered to be separate logical transactions entering the boundary to
groups of data. update the Job ILF make up the
elementary processes. There is no
elementary process to update the
transaction file.
dependent
code data
primary entities
There are no EIFs for this example. Refer to EI/EO/EQ Counting Examples
to see the explanation of how an input transaction file may be counted as an
external input.

Example: Different Users/Different User View
User The HR user requires the ability to maintain information on each new
Requirements employee.
The information that must be maintained by the HR user includes:
• Employee ID
• Employee Name
• Pension Eligibility Date *
* As a result of creating a new employee record, the employee’s Pension

Eligibility Date is automatically calculated and saved with the other
employee information.
The Pension user requires the ability to generate a list of employees with
their anticipated Pension Eligibility date.
Other attributes (e.g., Organizational Security Level) exist within the
Employee entity, but they are not referenced or maintained by either the HR
application or the Mail Distribution application.
Diagram
HR Application Pension
Application
User
User
Employee Emp_Id Print

Info Emp_Name Request
Mailing Address
Pay_Grade Emp_Name
Job_Title Pension_Elig_Date
Pension_Elig_Date Print Employee
Create Employee
Listing
Employee
Emp_Id
Emp_Name
Mailing Address
Pay_Grade
Job_Title
Pension_Elig_Date
Security_Level

Step 1 Identify Data Functions (for Pension application)

employee information is a data function for the Pension application.

2. Entities that are entity independent are Employee information is maintained by
considered to be separate logical the HR application. It is not excluded.
groups of data.
dependent
code data
primary entities
Step 2 Classify Data Functions (for Pension application)

The following table shows the summary results of the analysis to determine
whether Employee is classified as an EIF for the Pension application.
1. Classify as an ILF if the data is The Pension application does not maintain
maintained by the application being the Employee information.
measured
• Is referenced, but not maintained, The Pension application references, but
by the application being measured does not maintain Employee data.
and
• Is identified in an ILF in one or The HR application has identified
more other applications Employee as an ILF.
The Employee information meets all the requirements for an EIF for the
Pension application.

Step 3 Count DETs (for Pension application)

For DETs, look at each attribute associated with the employee EIF for the
Pension application. Use the DET counting rules to count DETs.
The attributes for the employee information include:
• Employee ID
• Employee Name
The following table shows the DET analysis for the Employee EIF for the
Pension application.
1. Count one DET for each unique user The Employee information
recognizable, non-repeated attribute includes the following attributes:
scope
2. Count only those DETs being used by Only the Employee Name and
the application being measured when Pension Eligibility Date are
two or more applications maintain and/or recognized by the Pension user. All
reference the same data function others are not counted as DETs for
the Pension application.

Step 4 Count RETs (for Pension application)

1. Count one RET for each data Count one RET for the Employee EIF.
DET:
attributes
sub-type) and
mandatory 1-1
The RET and DET totals for the Employee EIF in the Pension application.
RETs DETs
• Employee information • Employee Name


Example: Multiple Data Uses
User The Employee information is maintained by the HR application.

Requirements The HR user requires the ability to generate a listing of all of the employees.
The information that must be displayed for each employee includes:

• Employee ID
• Employee Name
Diagram
HR Application
User
Print
Employee Emp_Id Request
Emp_Name
Info Mailing Address
Pay_Grade
Emp_ID
Job_Title Emp_Name
Pension_Elig_Date Print Employee
Create Employee
Listing
Employee
Emp_Id
Emp_Name
M ailing Addres s
Pay _Grade
Jo b_Title
Pen sion_Elig_Date
Security_ Level


employee information is a data function for the HR application.

2. Entities that are entity independent are Employee information is maintained by
considered to be separate logical the HR application. It is not excluded.
groups of data.
dependent
code data
primary entities

employee information that is used to create the employee listing is also
classified as an EIF for the HR application.
1. Classify as an ILF if the data is Employee is maintained by the HR

maintained by the application being application. Classify it as an ILF.
measured
• Is referenced, but not maintained, Classified as an ILF; consequently, no
by the application being measured EIFs are identified.
and
• Is identified in an ILF in one or Not applicable.
The Employee information used for creating the Employee Listing is not an
EIF for the HR application.

This page intentionally left blank

Part 4 Chapter 2
Transactional Function Counting Examples

procedures used to functionally size transactional functions. In addition to
this section, examples are in the Case Studies included in the supplementary
IFPUG documentation.
Note: The examples in this section and throughout the manual have two
purposes:
1. To illustrate how the function point counting rules are applied
for a given set of user requirements.
2. To enable you to practice using the counting procedures.
Each counter must:

• Analyze the specific user requirements that apply for each project or
application being measured, and
• Count based on those requirements
Contents This section explains the organization of the examples and includes detailed
examples for each transactional function.
Topic Page
Organization of the Counting Examples 2-2
Overview of Transactional Function Procedures 2-5
Elementary Process Identification Examples 2-7
EI Counting Examples 2-61
EO Counting Examples 2-103
EQ Counting Examples 2-127

Transactional Function Counting Examples Part 4 - Examples
Organization of the Counting Examples
This section explains how the examples are presented.
Outline of the Organization
The following list outlines the sequence of information in the detailed

examples.
For each example:
• The EIs, EOs, and EQs are identified
• The FTRs and DETs that make up the functional complexity are counted
Diagram of the Organization
The following diagram illustrates the organization of the examples.
Example Example Example

Identify EIs Identify EOs Identify EQs
Count FTRs/DETs Count FTRs/DETs Count FTRs/DETs
Count for Each Example
Each example includes the following components:

• Basis for the count
• Tables applying the counting rules

Part 4 - Examples Transactional Function Counting Examples
Diagram of Components
The following diagram illustrates the components for each example and the
flow of information.
Basis for the Measurement
Counting Rules Table

Basis for the The basis for the count begins each example. As shown in the diagram of
Count components, the functional size measurement may be based on the following
components included in the examples:
• User requirements
• Data and process models
• Windows, screens, or reports
Note: All components in the diagram are not included in all examples. In
some examples, the requirements stand alone as the basis for the
count. Other examples include a data or process model, windows,
screens, and reports.
Counting The analysis to identify functions is presented in a table that lists the counting
Rules Tables rules for the function type. The rules are applied to the components that make
up the basis for the count. The analysis is explained in the table in the
column "Does the Rule Apply?"
Note: If all the rules apply, the example is counted as an EI, EO, or EQ.
The next tables show the rules and explanation for types that make up the
complexity for each function type identified.

Part 4 - Examples Transactional Function Counting Examples
Overview of Transactional Function Procedures

The process to analyze all the examples follows the process described earlier
in this chapter. Steps of the process are concerned with applying the rules to
measure transactional functions as defined in Part 1 and include the
following:
• Identify each Elementary Process (EP) required by the user
• Determine unique EPs
• Classify each EP as an External Input (EI), External Output (EO), or
External Inquiry (EQ)
• Count the File Types Referenced (FTRs) for each transactional function
• Count the Data Element Types (DETs) for each transactional function
• Determine the functional complexity for each transactional function
• Determine the functional size of each transactional function


Elementary Process Identification Examples
Introduction This section uses several examples to illustrate procedures for identifying
elementary processes, each of which stands on its own.
Note: Each example shows only the requirement specific to the situation
being illustrated, although in practice we must evaluate all
requirements and their functional impact. References are occasionally
made to related functions that also exist but are not illustrated (e.g.,
Add Employee vs. Update Employee).
Contents This section includes the following examples,:
Topic See Page

Summary Descriptions of Elementary Process Identification 2-8
Counting Examples
Example: New Employee/Dependent Data 2-9
Example: Print a Check/Mark It Paid 2-16
Example: View Job Assignments 2-21
Example: Print Job Assignments/Save Criteria 2-26
Example: Employee/Interview Information 2-31
Example: Employee/License Information 2-36
Example: Batch Employee Data Feed 2-41
Example: Assign Employee to Job 2-47
Example: Similar Elementary Processes 2-56

Elementary Process Identification Examples Part 4 - Examples
Summary Descriptions of Elementary Process

Identification Counting Examples
The examples for elementary process identification are described in the
following table.

New Employee/ This example shows that multiple processes 2-9
Dependent Data can make up one elementary process.
Print a Check/ This example illustrates the concept of primary 2-16
Mark It Paid intent in an elementary process.
View Job This example shows that entering selection 2-21
Assignments criteria for a report is not an elementary
process.
Print Job This example shows explicitly saving selection 2-26
Assignments/ criteria for a later use is a separate elementary
Save Criteria process.
Employee/ This illustrates another example of multiple 2-31
Interview processes making up one elementary process.
Information
Employee/ This is a third example of multiple processes 2-36
License making up one elementary process.
Information
Batch Employee This example illustrates that producing batch 2-41
Data Feed error reports and statistical reports are not
separate elementary processes.
Assign Employee This example illustrates the evaluation of 2-47
to Job similar elementary processes to determine
whether they are unique.
Similar This example illustrates two similar 2-56
Elementary Elementary Processes that are counted as
Processes unique transactions.

Part 4 - Examples Elementary Process Identification Examples
Example: New Employee/Dependent Data

User If a user adds a new employee, the user is required to enter
Requirements 1. employee setup (basic) data and
2. dependent information if the number of dependents is greater than
zero.
A transaction file is created during the update of the employee information.
This transaction file is sent periodically (e.g., at the end of the day) to the
Benefits System.
Note: Updating of existing employee information including dependent
information is not included in this example. Refer to Case Studies 1-3
for an illustration of counting updates.

Add Employee Determine whether adding the employee information without the associated
Without dependent information is an elementary process. The following table shows
Dependent
Information
the analysis.
Identify the Elementary Process Does the Rule Apply?
1. Compose and/or decompose the
Functional User Requirements into the
smallest unit of activity, which satisfies
all of the following:
• is meaningful to the user Yes. Adding an employee is part of the
functional user requirements.
• constitutes a complete transaction No. The complete transaction includes
adding the employee information with the
associated dependent information, if the
number of dependents is greater than zero.
These steps cannot be logically separated.
• is self-contained and No. Adding the associated dependent
information to the added employee is a
subsequent processing step necessary to
complete the elementary process.
• leaves the business of the application No. Adding the employee without adding
being counted in a consistent state the dependent does not leave the business
of the application in a consistent state. To
be in a consistent state, the functional user
requirement must be satisfied with nothing
more to be done. To satisfy the functional
user requirement, the dependent must also
be added.
2. Identify an elementary process for each Adding an employee (without adding
unit of activity identified that meets all of dependents) does not meet all of the
the above criteria criteria.
Conclusion Add Employee Without Dependent Information does not meet the
requirements of an elementary process.

Add Only Determine whether adding only the dependent information without the
Dependent employee information is an elementary process. The following table shows
Information
the analysis.
• is meaningful to the user Yes. Adding a dependent is part of the
• constitutes a complete transaction No. This activity is not a complete
transaction because it cannot be executed
independent of adding an employee.
• is self-contained and No. This activity is not self-contained
because it cannot be executed
independently of adding an employee.
• leaves the business of the application No. Adding the dependent without adding
being counted in a consistent state the employee does not leave the business of
the application in a consistent state. To be
in a consistent state, the functional user
user requirement, both the employee and
the associated dependent must be added.
2. Identify an elementary process for each Adding a dependent (without the applicable
unit of activity identified that meets all of employee) does not meet all of the criteria.
the above criteria It is not an elementary process.
Conclusion Add Only Dependent Information does not meet the requirements of an
elementary process. In this example, adding an employee (without adding
dependent information) does not meet all of the criteria. Other systems may
treat maintenance of dependent information independently from employee.

Add an For an employee who has dependents, determine whether adding the
Employee with employee information with the associated dependent information is an
Dependent
Information
elementary process. The following table shows the analysis.
• is meaningful to the user Yes. Adding an employee including
dependent is part of the functional user
requirements.
• constitutes a complete transaction Yes. Together employee and dependent
information are used to add an employee to
the HR system. These steps cannot be
logically separated.
• is self-contained and Yes. This activity is meaningful by itself
and all necessary information is added to
the HR application.
• leaves the business of the application Yes. The business is left in a consistent
being counted in a consistent state state when the employee is added,
including applicable dependents.
2. Identify an elementary process for each Add an Employee with Dependent
unit of activity identified that meets all of Information meets all of the above criteria.
the above criteria
Conclusion Add an Employee with Dependent Information meets the requirements of an

elementary process.
There could be different implementations of this requirement to add
dependent(s) to an employee. For example:
• a data entry field called Number of Dependents on the employee screen
that triggers the display of the dependent screen
• a button that displays the dependent screen
• a menu item on the employee screen that displays the dependent screen
• the possibility to enter dependent(s) on the employee screen
Irrespective of the implementation of this requirement, there is still one
elementary process, adding employee including dependents.
We do not identify separate elementary processes because we have optional
data (e.g., Add Employee with dependent, Add Employee without
dependent).

Determine The following table shows the analysis to determine whether the elementary
Unique process is unique.
Elementary
Processes
Determine Unique Elementary Processes Does the Rule Apply?
1. When compared to an Elementary Process
(EP) already identified, count two similar
EPs as the same Elementary Process if
they:
• Require the same set of DETs and Yes. Add Employee requires the same set
of DETs as Update Employee.
• Require the same set of FTRs and Yes. Add Employee requires the same set
of FTRs as Update Employee.
• Require the same set of processing No. Add Employee has a different set of
logic to complete the elementary processing logic than Update Employee.
process
2. Do not split an elementary process with The functional user requirement considers
multiple forms of processing logic into there to be a single function. We do not
multiple elementary processes split Add Employee into two elementary
processes (i.e., Add Employee Only, Add
Dependent Only).
Conclusion The Add Employee elementary process is unique from all other identified
elementary processes.

Send Determine whether sending the transactions file to the Benefits System is an
Transaction additional elementary process. The following table shows the analysis.
File to Benefits
System
• is meaningful to the user Yes. Sending the transaction file to the
Benefits System is part of the functional
user requirements.
• constitutes a complete transaction Yes. Sending the transaction file to the
Benefits System is a complete transaction.
It is a logically separate function from the
Add Employee function.
• is self-contained and Yes. The activity to send the transactions to
the Benefits System is self-contained. The
Transaction file is sent independently (i.e.,
at end of day) from the Add Employee
function.
• leaves the business of the application Yes. After the transactions are sent to the
being counted in a consistent state Benefits System, the business of the HR
application is in a consistent state. The
functional user requirement has been fully
satisfied with nothing more to be done.
2. Identify an elementary process for each Send Transaction File to Benefits System
unit of activity identified that meets all of meets all of the above criteria.
the above criteria
Conclusion Send Transaction File to Benefits System meets the requirements of an

elementary process.

Elementary
Processes
they:
• Require the same set of DETs and No. Sending the transaction file to the
Benefits System requires different DETs
than other identified EPs.
• Require the same set of FTRs and Yes. Sending the transaction file to the
Benefits System requires the same set of
FTRs as Add Employee.
• Require the same set of processing No. Sending the transaction file to the
logic to complete the elementary Benefits System has a different set of
process processing logic than other identified EPs.
2. Do not split an elementary process with There is nothing to split.
multiple forms of processing logic into
multiple elementary processes
Conclusion The Send Transaction File to Benefits System elementary process is unique
from all other identified elementary processes.

Example: Print a Check/Mark It Paid

User Print a check and, as a result, mark the account as paid. All data printed on
Requirements the check is already stored in the check file.
The following diagram shows the data flow for this example.
Print check
Check ILF
Check Number
Check Amount
Recipient
Account Paid Indicator
Check Date

Mark the Determine whether marking the account as paid is an elementary process.
Account as The following table shows the analysis.
Paid
• is meaningful to the user Yes. Marking the account as paid is part of
the functional user requirements.
• constitutes a complete transaction No. Marking the account as paid is not a
complete transaction, unless the check is
also printed. These steps cannot be
• is self-contained and No. Marking the account as paid without
also printing a check is not a self-contained
function. The account cannot be marked as
paid independently from printing the check.
• leaves the business of the application No. Marking the account as paid without
being counted in a consistent state printing the check does not leave the
business in a consistent state. To be in a
consistent state, the functional user
user requirement, marking the account as
paid must occur when printing the check.
2. Identify an elementary process for each Marking the account as paid does not meet
unit of activity identified that meets all of all of the criteria. It is not an elementary
the above criteria process.
Conclusion Mark the Account as Paid does not meet the requirements for an elementary
process.

Print a Check Determine whether printing a check without marking the account as paid is an
elementary process. The following table shows the analysis.
• is meaningful to the user Yes. Printing a check is part of the
• constitutes a complete transaction No. Printing a check is not a complete
transaction, unless the account is marked as
paid. These steps cannot be logically
separated.
• is self-contained and No. Printing a check is not self-contained
until the subsequent step of marking the
account as paid has been performed.
• leaves the business of the application No. Printing a check without marking the
being counted in a consistent state account as paid does not leave the business
in a consistent state. To be in a consistent
state, the functional user requirement must
be satisfied with nothing more to be done.
To satisfy the functional user requirement,
the account must also be marked as paid.
2. Identify an elementary process for each Printing a check does not meet all of the
unit of activity identified that meets all of criteria. It is not an elementary process.
the above criteria
Conclusion Print a Check does not meet the requirements for an elementary process.

Print a Check Determine whether printing the check and marking the account as paid is an
and Mark the elementary process. The following table shows the analysis.
Account as
Paid
• is meaningful to the user Yes. Printing a check and marking the
account as paid is part of the functional user
requirements.
• constitutes a complete transaction Yes. Printing a check and marking the
account as paid is a complete transaction.
• is self-contained and Yes. Printing a check and marking the
account as paid is self-contained. There are
no prior or subsequent steps that need to be
performed.
• leaves the business of the application Yes. Printing a check and marking the
being counted in a consistent state account as paid leaves the business in a
consistent state. The functional user
requirement has been fully satisfied.
2. Identify an elementary process for each Printing a check and marking the account
unit of activity identified that meets all of as paid meets all of the criteria. It is an
the above criteria elementary process.
Conclusion Print a Check and Mark the Account as Paid meets the requirements for an
Elementary Process.
The user requirement is to print the check. Marking the field Account Paid
Indicator is part of the printing process. Printing and marking together are the
smallest unit of activity that is meaningful to the user. The entire process is
meaningful to the user, constitutes a complete transaction, is self-contained
and leaves the business of the application being counted in a consistent state.

Elementary
Processes
they:
• Require the same set of DETs and No. The set of DETs for printing a check
and marking it complete is different than
that of any other EP.
• Require the same set of FTRs and No. The set of FTRs for printing a check
and marking it complete is different than
• Require the same set of processing No. The set of processing logic for printing
logic to complete the elementary a check and marking it complete is different
process than that of any other EP.
2. Do not split an elementary process with Marking the account paid is part of the
multiple forms of processing logic into processing logic of printing a check.
Conclusion The Print a Check and Mark the Account as Paid elementary process is
unique from all other identified elementary processes.

Example: View Job Assignments

User View a list of the job assignments within a date range. The user will be able
Requirements to enter the selection criteria. There is no requirement to store the selection
criteria once the report has been generated. The following diagram shows the
data flow for this example.
Assignment Li st Cri teria
Employee ID
Print
Start Date
Cancel
End Date

Enter Selection Determine whether entering the selection criteria (without viewing the job
Criteria assignments) is an elementary process. The following table shows the
analysis.
• is meaningful to the user Yes. Entering the selection is part of the
• constitutes a complete transaction No. Entering the selection criteria (without
viewing the job assignments) is not a
complete transaction. These steps cannot be
• is self-contained and No. Entering the selection criteria (without
viewing the job assignments) is not self-
contained. Viewing the job assignment list
is a subsequent processing step necessary to
• leaves the business of the application No. Entering the selection criteria (without
being counted in a consistent state viewing the job assignments) does not leave
the business in a consistent state. To be in a
user requirement, the job assignments list
must be viewed.
2. Identify an elementary process for each Entering the selection criteria (without
unit of activity identified that meets all of viewing the job assignments) does not meet
the above criteria the criteria.
Conclusion Enter Selection Criteria does not meet the requirements for an elementary
process.

View Job Determine whether viewing job assignments (without entering the selection
Assignments criteria) is an elementary process. The following table shows the analysis.
• is meaningful to the user Yes. Viewing job assignments is part of the
• constitutes a complete transaction No. Viewing job assignments (without
entering the selection criteria) cannot be
performed without entering the selection
criteria. These steps cannot be logically
separated.
• is self-contained and No. Viewing job assignments (without
entering the selection criteria) is not self-
contained. The job assignments cannot be
viewed independently from the prior step of
entering the selection criteria.
• leaves the business of the application No. Viewing job assignments (without
being counted in a consistent state entering the selection criteria) does not
leave the business in a consistent state. To
be in a consistent state, the functional user
user requirement, the selection criteria must
also be entered.
2. Identify an elementary process for each Viewing job assignments (without entering
unit of activity identified that meets all of the selection criteria) does not meet the
Conclusion View Job Assignments (without entering the selection criteria) does not meet
the requirements for this elementary process.

Enter Selection Determine whether entering the selection criteria and viewing the job
Criteria and assignments is an elementary process. The following table shows the
View Job
Assignments
analysis.
• is meaningful to the user Yes. Entering the selection criteria and
viewing job assignments is part of the
• constitutes a complete transaction Yes. Entering the selection criteria and
viewing job assignments is a complete
transaction. These steps cannot be logically
separated.
• is self-contained and Yes. Entering the selection criteria and
viewing job assignments is a self-contained
transaction. There are no prior or
subsequent steps that need to be performed.
• leaves the business of the application Yes. Entering the selection criteria and
being counted in a consistent state viewing job assignments leaves the
business in a consistent state. To be in a
user requirement, the selection criteria must
be entered and the job assignments viewed.
2. Identify an elementary process for each Entering the selection criteria and viewing
unit of activity identified that meets all of job assignments meets all of the above
Conclusion Enter Selection Criteria and View Job Assignments meets the criteria for an
elementary process.
Control information is the input side of an EO or EQ. The request specifying
what and/or how data is to be retrieved or generated is part of the elementary
process to provide the user data and is not an elementary process itself.
Entering the selection criterion is not the smallest unit of activity that is
meaningful to the user. It is not self-contained because it cannot be
performed independently of producing the report. Entering the selection
criteria and generating the report together comprise the smallest unit of
activity that is meaningful to the user, constitutes a complete transaction, is
self-contained and leaves the business of the application being counted in a
consistent state.

Elementary
Processes
they:
• Require the same set of DETs and No. The set of DETs for entering selection
criteria and viewing assignments is
different than that of any other EP.
• Require the same set of FTRs and No. The set of FTRs for entering selection
criteria and viewing assignments is
different than that of any other EP.
• Require the same set of processing No. The set of processing logic for entering
logic to complete the elementary selection criteria and viewing assignments
process is different than that of any other EP.
2. Do not split an elementary process with It is necessary to enter the selection criteria
multiple forms of processing logic into in order to view the job assignments.
Conclusion The Enter Selection Criteria and View Job Assignments elementary process is
unique from all other identified elementary processes.

Example: Print Job Assignments/Save Criteria

User Print a job assignment list between a date range. The user will be able to
Requirements enter the selection criteria. There is a requirement to enable the user to save
the selection criteria for later use.
Assignment Li st Cri teria

Print
Employee ID
Save
Start Date
Cancel
End Date
Job Assignment List
Date EmpId Assignment

Save P rint Job
Criteria Assignment List 1/13/1997 0103 xxxxxxxxxxx
2/1/1997 0109 yyyyyyyyyyy
2/12/1997 0106 zzzzzzzzz zzz
Report Criteria ILF Job Assignment ILF

Userid EmpId
EmpId
Assignment Date
Start Date Assignment
End Date
Report ID
...

Enter & Save Determine whether saving the selection criteria (without printing a job
Selection assignment list) is an elementary process. The following table shows the
Criteria
analysis.
• is meaningful to the user Yes. Saving the selection criteria is part of
• constitutes a complete transaction Yes. Saving the selection criteria is a
complete transaction. It is a logically
separate function from printing a job
assignment list.
• is self-contained and Yes. Saving the selection criteria is a self-
contained transaction. It can be performed
independently from printing the job
assignment list.
• leaves the business of the application Yes. Saving the selection criteria leaves the
being counted in a consistent state business in a consistent state. The
2. Identify an elementary process for each Saving the selection criteria meets all of the
unit of activity identified that meets all of above criteria.
the above criteria
Conclusion Enter & Save Selection Criteria meets the requirements for an elementary
process.

Elementary
Processes
they:
• Require the same set of DETs and No. The set of DETs for saving selection
criteria is different than that of any other
EP.
• Require the same set of FTRs and No. The set of FTRs for saving selection
criteria is different than that of any other
EP.
• Require the same set of processing No. The set of processing logic for saving
logic to complete the elementary selection criteria is different than that of
process any other EP.
Conclusion The Save Selection Criteria elementary process is unique from all other
identified elementary processes.

Print Job Determine whether printing a job assignment list, whether the selection
Assignments criteria is saved or not, is an elementary process. The following table shows
the analysis.
• is meaningful to the user Yes. Printing a job assignment list is part of
• constitutes a complete transaction Yes. Printing a job assignment list is a
complete transaction. It is a logically
separate function from saving the selection
criteria.
• is self-contained and Yes. Printing a job assignment list is a self-
contained transaction. It can be performed
independently of saving the criteria.
• leaves the business of the application Yes. Printing a job assignment list leaves
being counted in a consistent state the business in a consistent state. The
2. Identify an elementary process for each Printing a job assignment list meets all of
unit of activity identified that meets all of the above criteria.
the above criteria
Conclusion Print Job Assignments is an elementary process.

The entering of selection criteria is meaningful to the user because the user
can explicitly save the criteria. Either printing the report or saving the criteria
can be performed independently, and both leave the business in a consistent
state.
Both processes, storing the selection criteria and generating the report, are
meaningful to the user, constitute complete transactions, are self-contained
and leave the business of the application in a consistent state. According to
the Elementary Process Identification Rules, there are two elementary
processes.

Elementary
Processes
they:
• Require the same set of DETs and No. The set of DETs for printing a job
assignment list is different than that of any
other EP.
• Require the same set of FTRs and No. The set of FTRs for printing a job
assignment list is different than that of any
other EP.
• Require the same set of processing No. The set of processing logic for printing
logic to complete the elementary a job assignment list is different than that of
process any other EP.
Conclusion The Print Job Assignments elementary process is unique from all other
identified elementary processes.

Example: Employee/Interview Information

User When adding a new employee, in addition to the employee’s personal data
Requirements (i.e., Social Security Number, surname, address, etc.), the employee’s
interview details must be entered. The interview information includes the
interviewer’s name, the interview date, and the interviewer’s comments.
Create Employee
Employee SSN Create
Surname Cancel
Address
Add Interview Details

Interviewer Name Add
Interview Date Cancel
Interviewer Comments
Create Add Interview

Employee Details
Employee ILF
SSN
Surname
Address
...
Interviewer Name
Interview Date
Interviewer Comments

Entering the Determine whether entering only the employee’s personal information is an
Employee’s Elementary Process. The following table shows the analysis.
Personal Data
• is meaningful to the user Yes. Entering the employee’s personal data
is part of the functional user requirements.
entering the employee’s personal data as
well as the interview details. These steps
cannot be logically separated.
• is self-contained and No. Adding the associated interview details
is a subsequent step step necessary to
• leaves the business of the application No. Entering the employee’s personal data
being counted in a consistent state without also entering interview details does
not leave the business of the application in
a consistent state. To be in a consistent
the interview details must also be entered.
2. Identify an elementary process for each Entering the employee’s personal data only
unit of activity identified that meets all of does not meet all of the criteria.
the above criteria
Conclusion Entering the Employee’s Personal Data (without entering the interview
details) does not meet the requirements for an elementary process.

Entering Determine if entering only the employee’s interview details is an elementary

Employee’s process. The following table shows the analysis.
Interview
Details
• is meaningful to the user Yes. Entering employee’s interview details
is part of the functional user requirements.
well as the interview details. These steps
• is self-contained and No. Entering employee’s interview details
only cannot be performed independently of
entering interview details.
• leaves the business of the application No. Entering employee’s interview details
being counted in a consistent state without also entering personal information
does not leave the business of the
application in a consistent state. To be in a
user requirement, both the employee’s
personal data and the interview details must
be entered.
2. Identify an elementary process for each Entering employee’s interview details only
the above criteria
Conclusion Entering Employee’s Interview Details (without the employee’s personal

data) does not meet the requirements for an elementary process.

Entering the Determine whether entering the employee’s personal data along with the
Employee’s interview details is an elementary process. The following table shows the
Personal Data
and Interview
analysis.
Details
• is meaningful to the user Yes. Entering the employee’s personal data
and interview details are both part of the
• constitutes a complete transaction Yes. Entering the employee’s personal data
and interview details together are a
complete transaction. These steps cannot be
• is self-contained and Yes. Entering the employee’s personal data
and interview details together are a self-
contained function. There are no prior or
subsequent steps that need to be performed.
• leaves the business of the application Yes. Entering an employee’s personal data
being counted in a consistent state and interview details leaves the business of
the application in a consistent state. To
satisfy the functional user requirement, both
steps must be performed.
2. Identify an elementary process for each Entering the employee’s personal data and
unit of activity identified that meets all of interview details meets all of the criteria.
the above criteria
Conclusion Entering the Employee’s Personal Data and Interview Details meets the
criteria for an elementary process.
If two input processes are always sequential and dependent (step one and step
two are mandatory), then there is one elementary process and one function.
A new employee cannot be recorded until both the employee’s personnel data
and the employee’s interview details are entered. Entering the personal data
or the interview details alone would not be the smallest unit of activity that is
meaningful to the user.
Entering the Employee’s Personal Data and Interview Details together
comprise the smallest unit of activity that is meaningful to the user,
constitutes a complete transaction, is self-contained and leaves the business of
the application being counted in a consistent state.

Elementary
Processes
they:
• Require the same set of DETs and No. The set of DETs for Entering the
Employee’s Personal Data and Interview
Details is different from that of any other
EP.
• Require the same set of FTRs and No. The set of FTRs for Entering the
Employee’s Personal Data and Interview
Details is different from that of any other
EP.
• Require the same set of processing No. The set of processing logic for Entering
logic to complete the elementary the Employee’s Personal Data and
process Interview Details is different from that of
any other EP.
2. Do not split an elementary process with A new employee cannot be recorded until
multiple forms of processing logic into both the employee’s personal data and the
multiple elementary processes employee’s interview data are entered.
Conclusion The Entering the Employee’s Personal Data and Interview Details elementary
process is unique from all other identified elementary processes.

Example: Employee/License Information

User When adding a new employee, the employee data is entered for Social
Requirements Security Number, name, address, and whether or not the employee has a
driver’s license. If the employee does have a driver’s license, a secondary
step must be completed to record the employee’s driver’s license number,
classification(s), and expiration date.
Note: Updating of existing employee information including license
information is not included in this example.
Create Employee
Employee SSN Create
Surname Cancel
Address Driver’s License
Add License Information

Driver’s License Return
License Number
Cancel
Yes Classification
Expiration Date
Driver’s
Create Add License
License?
Employee Information
No
Employee ILF
SSN
Surname
Address
Driver’s License
License Number
Classification
Expiration Date

Entering the Determine whether entering only the employee’s personal information is an
Employee’s Elementary Process. The following table show the analysis.
Personal Data
• is meaningful to the user Yes. Adding an employee is part of the
well as the driver’s license (if it exists).
• is self-contained and No. Entering the driver’s license (if it
exists) is a subsequent processing step
necessary to complete the elementary
process.
• leaves the business of the application No. Entering the employee’s personal data
being counted in a consistent state without also entering the driver’s license (if
it exists) does not leave the business of the
user requirement, the driver’s license must
also be entered (if it exists).
2. Identify an elementary process for each Entering the employee’s personal data only
the above criteria
Conclusion Entering the Employee’s Personal Data without entering the driver’s license
(if it exists) does not meet the requirements for an elementary process.

Entering the Determine whether entering the driver’s license information without the
Employee’s employee’s personal information is an elementary process. The following
License
Information
table shows the analysis.
• is meaningful to the user Yes. Adding license information is part of
• is self-contained and No. Entering personal information is a prior
processing step necessary to complete the
elementary process.
• leaves the business of the application No. Adding only license information does
being counted in a consistent state not leave the business of the application in
both personal data and driver’s license (if it
exists) must be entered.
2. Identify an elementary process for each Adding only license information does not
unit of activity identified that meets all of meet all of the criteria.
the above criteria
Conclusion Adding License Information (without entering the employee’s personal

information) does not meet the requirements for an elementary process.

Adding Determine whether entering an employee’s personal information together

Employee and with the associated license information is an elementary process. The
License
Information
following table shows the analysis.
• is meaningful to the user Yes. Adding an employee and recording the
employee license is part of the functional
user requirements.
• constitutes a complete transaction Yes. The complete transaction includes
• is self-contained and Yes. Adding an employee and recording the
employee license is a self-contained
function. There are no prior or subsequent
steps that must be performed.
• leaves the business of the application Yes. Entering an employee’s personal data
being counted in a consistent state and driver’s license (if it exists) leaves the
business of the application in a consistent
state. To satisfy the functional user
requirement, both steps must be performed.
2. Identify an elementary process for each Adding an employee and recording the
unit of activity identified that meets all of employee license meets all of the criteria.
the above criteria
Conclusion If two input processes are always sequential and dependent, but the second
process is optional (but is mandatory if it applies), then there is one
elementary process.
Adding Employee and License Information is an Elementary Process. If an
employee does not have a license, the step “Add License Information” is not
relevant. If an employee does have a driver’s license, a secondary screen
must be completed to complete the Elementary Process and leave the business
of the application in a consistent state.

Elementary
Processes
they:
• Require the same set of DETs and No. The set of DETs for Adding Employee
and License Information is different from
• Require the same set of FTRs and No. The set of FTRs for Adding Employee
and License Information is different from
• Require the same set of processing No. The set of processing logic for Adding
logic to complete the elementary Employee and License Information is
process different from that of any other EP.
2. Do not split an elementary process with If an employee has a driver’s license, a new
multiple forms of processing logic into employee cannot be recorded until both the
multiple elementary processes employee’s personal data and the
employee’s license data are entered.
Conclusion The Entering the Employee’s Personal Data and Interview Details elementary
process is unique from all other identified elementary processes.

Example: Batch Employee Data Feed

User A batch feed of new employee data from another application must be
Requirements accepted. The employee data must be validated and saved to the Employee
file; an error report is produced containing any identified errors. The HR
business office is notified via email with processing summary data.
HR Application
Empl
Feed Employee
Error Report Email

Notification
w/Summary
Data

Process an Determine whether accepting an Employee Data Feed and processing the
Employee Data transactions without reporting errors and summary data is an elementary
Feed
process. The following table shows the analysis.
• is meaningful to the user Yes. Accepting an Employee Data Feed
and processing the transactions is part of
reporting the errors and summary data from
the Employee Data Feed. These steps
• is self-contained and No. Producing the Error Report and Email
Notification are subsequent processing
steps necessary to complete the elementary
process.
• leaves the business of the application No. Processing the Employee Data Feed
being counted in a consistent state without producing the Error Report and
Email Notification does not leave the
business of the application in a consistent
state. To be in a consistent state, the
functional user requirement must be
satisfied with nothing more to be done. To
satisfy the functional user requirement, the
errors and summary data from processing
the Employee Data Feed must be reported.
2. Identify an elementary process for each All of the criteria have not been met.
unit of activity identified that meets all of
the above criteria
Conclusion Accepting the feed and processing the transactions without producing the
error report or sending the summary email does not meet the requirements of
an elementary process.

Produce an Determine whether producing an error report without processing the

Error Report Employee Data Feed is an elementary process. The following table shows the
analysis.
• is meaningful to the user Yes. Producing the Error Report is part of
• constitutes a complete transaction No. Producing the Error Report is an
integral part of the update process and the
errors cannot be determined outside of that
process. These steps cannot be logically
separated.
• is self-contained and No. Producing the Error Report without
processing the Employee Data Feed is not a
self-contained function. The Error Report
cannot be produced independently from
processing and validating the Employee
Data Feed.
• leaves the business of the application No. Producing the Error Report without
being counted in a consistent state processing the Employee Data Feed does
not leave the business of the application in
the Error Report must be produced from
processing and validating the Employee
Data Feed.
the above criteria
Conclusion Producing the Error Report without processing the Employee Data Feed does
not meet the requirements of an elementary process.

Produce an Determine whether producing an Email Notification without processing the

Email Employee Data Feed is an elementary process. The following table shows the
Notification
analysis.
• is meaningful to the user Yes. Producing an Email Notification with
summary data is part of the functional user
requirements.
• constitutes a complete transaction No. Producing an Email Notification is an
integral part of the update process and the
processing statistics cannot be determined
outside of that process. These steps cannot
be logically separated.
• is self-contained and No. Producing an Email Notification
without processing the Employee Data
Feed is not a self-contained function. The
processing statistics cannot be determined
independently from processing the
Employee Data Feed.
• leaves the business of the application No. Producing the Email Notification
being counted in a consistent state without processing the Employee Data
Feed does not leave the business of the
user requirement, the Email Notification
must be produced from processing the
Employee Data Feed.
the above criteria
Conclusion Producing the Email Notification without processing the Employee Data Feed
does not meet the requirements of an elementary process.

Process Determine whether accepting an employee data feed, processing transaction,

Employee Data producing an error report and sending a notification email is an elementary
Feed, Produce
Error Report
process. The following table shows the analysis.
and Email
Notification
• is meaningful to the user Yes. Processing the Employee Data Feed,
producing the Error Report and Email
Notification are part of the functional user
requirement.
• constitutes a complete transaction Yes. Processing the Employee Data Feed,
Notification is a complete transaction.
• is self-contained and Yes. Processing the Employee Data Feed,
Notification is a self-contained function.
• leaves the business of the application Yes. Processing the Employee Data Feed,
being counted in a consistent state producing the Error Report and Email
Notification leaves the business of the
application in a consistent state. To satisfy
the functional user requirement, all steps
must be performed to process the Employee
Data Feed.
2. Identify an elementary process for each All of the criteria have been met.
the above criteria
Conclusion Processing the Employee Data Feed including producing the Error Report and
Email Notification together satisfy the functional user requirements.
Accepting the Employee Data Feed, processing the transactions, producing
the Error Report and Email Notification is one Elementary Process. If the
feed is not accepted and the transactions are not processed, the steps “Produce
Error report” and “Produce Email Notification” are not relevant. All
processing steps must be performed to complete the elementary process and
leave the business of the application in a consistent state.

Elementary
Processes
they:
• Require the same set of DETs and No. The set of DETs for Processing the
Employee Data Feed is different from that
of any other EP.
• Require the same set of FTRs and No. The set of FTRs for Processing the
Employee Data Feed is different from that
of any other EP.
• Require the same set of processing No. The set of processing logic for
logic to complete the elementary Processing the Employee Data Feed is
process different from that of any other EP.
2. Do not split an elementary process with As was previously discussesd, subdividing
multiple forms of processing logic into an elementary process is not appropriate.
Conclusion The Processing the Employee Data Feed elementary process is unique from
all other identified elementary processes.

Example: Assign Employee to Job

User Assign an employee to a job. Add job assignment information by entering
Requirements the following information for each job and employee:
• Effective Date
• Salary
• Performance Rating
To aid in making assignments, the user has requested a list of employee
assignments by employee and/or a list of jobs with employees.
Employee This window shows the list of employees and the jobs assignments for each
Assignments employee.
List Window
Human Resources System
Employee Jobs Assignments Locations Reports Security Help
Employee Assignments
Last Name First Name MI Job
Keller Caroline RD21379305

Keller Nicky A RD21379305
Latta Nicky A RD90379305
Manship Mark J RD14379305
Manship Mark J RD15379305
Schmidt -Taylor Kathleen RD14379305
Smith David E RD16379305
Smith Loretta M RD16379305
Waldenson Pat RD90379305
White William W RD21379305
White William W RD90379305
View New Edit Delete
View Initiates display of data on AE-4 Job Assignment Data

New Returns blank form on AE- 3 Job Assignment Setup (default data filled in)
Edit Initiates display of data on AE- 5 Job Assignment Edit
Delete Removes job assignment entry (after confirmation)

Job Assignment The next window shows the assignment of an employee to a job (by
Setup Window employee).
Job Assignment Setup

First Name MI Last Name
Mark J Manship
Social Security Number 345-67-8901
Loca tion Main Plant Bargaining Unit UFPCA
Job Number
Date
OK
Salary
Performance Rating Cancel
AE-3 Job Assignment Setup

OK Saves new job assignment, returns to AE -1 Employee Assignment List
Cancel Ignores data entered, returns to AE -1 Employee Assignment List
If the user does not enter data correctly, an error message is shown.
Job The next window shows a list of jobs and the employee assigned.
Assignments
List Window
Job Assignments
Job ID Last Name First Name MI
RD14379305 Manship Mark J

RD14379305 Schmidt-Taylor Kathleen
RD15379305 Manship Mark J
RD16379305 Smith David E
RD16379305 Smith Loretta M
RD21379305 Keller Caroline
RD21379305 Latta Nicky A
RD21379305 White William W
RD90379305 Latta Nicky A
RD90379305 Waldenson Pat
RD90379305 White William W
View New Edit Delete
AJ-1 Job Assignment List
View Initiates display of data on AJ-4 Employee Assignment Data

New Returns blank form on AJ-3 Employee Assignment Setup (default data filled in)
Edit Initiates display of data on AJ-5 Employee Assignment Edit
Delete Removes employee job assignment entry (after confirmation)

Employee The next window shows the assignment of an employee to a job (by job).
Assignment
Setup Window
Job Assignments
Employee Assignment Setup
RD14379305 May Issue - Print Text
Last Name
First Name
Middle Initial
Social Security - -
Location Bargaining Unit

Date OK
Salary Cancel
Performance Rating
AJ-3 Employee Assignment Setup

OK Saves new employee assignment
Cancel Ignores data entered, returns to AJ-1 Job Assignment List
If the user does not enter data correctly, an error message is shown.

Employee Determine whether Listing Employee Assignments is an elementary process.

Assignments The following table shows the analysis.
List
• is meaningful to the user Yes. Listing Employee Assignments is part
of the functional user requirements.
• constitutes a complete transaction Yes. Listing Employee Assignments is a
complete transaction. This is a logically
independent function.
• is self-contained and Yes. Listing Employee Assignments is a
self-contained function. Listing Employee
Assignments is performed independently
from assigning an employee to a job.
• leaves the business of the application Yes. Listing Employee Assignments leaves
being counted in a consistent state the business of the application in a
consistent state. The functional user
requirement has been fully satisfied with
nothing more to be done.
2. Identify an elementary process for each Listing Employee Assignments meets all of
unit of activity identified that meets all of the criteria.
the above criteria
Conclusion Listing Employee Assignments meets the requirements of an elementary

process.

Assign Determine whether Assigning Employee to Job (by Employee) is an

Employee to elementary process. The following table shows the analysis.
Job (by
Employee)
• is meaningful to the user Yes. Assigning Employee to Job (by
Employee) is part of the functional user
requirements.
• constitutes a complete transaction Yes. Assigning Employee to Job (by
Employee) is a complete transaction. This
is a logically independent function.
• is self-contained and Yes. Assigning Employee to Job (by
Employee) is a self-contained function.
Assigning Employee to Job (by Employee)
is performed independently from Listing
Employee Assignments.
• leaves the business of the application Yes. Assigning Employee to Job (by
being counted in a consistent state Employee) leaves the business of the
application in a consistent state. The
2. Identify an elementary process for each Assigning Employee to Job (by Employee)
unit of activity identified that meets all of meets all of the criteria.
the above criteria
Conclusion Assigning Employee to Job (by Employee) meets the requirements of an

elementary process.

Job Determine whether Listing Job Assignments is an elementary process. The

Assignments following table shows the analysis.
List
• is meaningful to the user Yes. Listing Job Assignments is part of the
• constitutes a complete transaction Yes. Listing Job Assignments is a complete
transaction. This is a logically independent
function.
• is self-contained and Yes. Listing Job Assignments is a self-
contained function. Listing Job
Assignments is performed independently
from assigning an employee to a job.
• leaves the business of the application Yes. Listing Job Assignments leaves the
being counted in a consistent state business of the application in a consistent
state. The functional user requirement has
been fully satisfied with nothing more to be
done.
2. Identify an elementary process for each Listing Job Assignments meets all of the
unit of activity identified that meets all of criteria.
the above criteria
Conclusion Listing Job Assignments meets the requirements of an elementary process.

Assign Determine whether Assigning Employee to Job (by Job) is an elementary

Employee to process. The following table shows the analysis.
Job (by Job)
• is meaningful to the user Yes. Assigning Employee to Job (by Job) is
part of the functional user requirements.
• constitutes a complete transaction Yes. Assigning Employee to Job (by Job) is
a complete transaction. This is a logically
independent function.
• is self-contained and Yes. Assigning Employee to Job (by Job) is
a self-contained function. Assigning
Employee to Job (by Job) is performed
independently from Listing Job
Assignments.
• leaves the business of the application Yes. Assigning Employee to Job (by Job)
being counted in a consistent state leaves the business of the application in a
consistent state.
2. Identify an elementary process for each Assigning Employee to Job (by Job) meets
unit of activity identified that meets all of all of the criteria. The functional user
the above criteria requirement has been fully satisfied with
nothing more to be done.
Conclusion Assigning an Assigning Employee to Job (by Job) meets the requirements of
an elementary process.

Determine The following table shows the analysis to determine whether the Listing
Unique Employee Assignments and Listing Job Assignments elementary processes
Elementary are unique.
Processes
they:
• Require the same set of DETs and Yes. The set of DETs for Listing Employee
Assignments is the same as the set of DETs
for Listing Job Assignments.
• Require the same set of FTRs and Yes. The set of FTRs for Listing Employee
Assignments is the same as the set of FTRs
for Listing Job Assignments.
• Require the same set of processing Yes. The set of processing logic for Listing
logic to complete the elementary Employee Assignments is the same as the
process set of processing logic Listing Job
Assignments. The only difference between
them is the arrangement of the fields and
the sort sequence of the rows. As stated in
the Forms of Processing Logic, differences
in the arrangement or sorting does not
constitute a unique EP.
Conclusion Listing Employee Assignments and/or Listing Job Assignments is a single

unique elementary process.

Determine The following table shows the analysis to determine whether the Assigning
Unique Employee to Job (by Employee) and Assigning Employee to Job (by Job)
Elementary elementary processes are unique.
Processes
they:
• Require the same set of DETs and Yes. The set of DETs for Assigning
Employee to Job (by Employee) is the same
as the set of DETs for Assigning Employee
to Job (by Job).
• Require the same set of FTRs and Yes. The set of FTRs for Assigning
Employee to Job (by Employee) is the same
as the set of FTRs for Assigning Employee
to Job (by Job).
• Require the same set of processing Yes. The set of processing logic for
logic to complete the elementary Assigning Employee to Job (by Employee)
process is the same as the set of processing logic
Assigning Employee to Job (by Job). The
only difference between them is the
arrangement of the attributes on the screen.
As stated in the Forms of Processing Logic,
differences in the arrangement of attributes
does not constitute a unique EP.
Conclusion Two unique elementary process are identified:

• Listing Assignments (by Employee) and/or Listing Assignments (by Job)
• Assigning Employee to Job (by Employee) and/or Assigning Employee to
Job (by Job)
When two similar elementary processes are compared and it is determined
that they contain the same set of DETs, FTRs and Processing Logic, they are
identified as a single unique elementary process.

Example: Similar Elementary Processes

User The user of employee information requires two reports that are very similar.
Requirements One report will include employee emails and will be distributed to the
remote staff that is required to communicate via email instead of phone. See
report examples for details of each report.
All of the data on the reports come from the same logical file except for the
email address that comes from a different logical file that is maintained
within the same application.
Employee Employee Listing

Listing (With
Email Address) ID # Name Home Phone Work Phone Location Email Address
894253 Jay Smith 888-555-1212 999-666-0202 Plant A Jsmith@USACorp.com
999524 Mel Dunn 777-258-489 999-125-3589 Plant B MDunn@USACorp.com
125896 Val Jones 555-678-6892 999-258-4789 Plant C VJones@USACorp.com
Employee Employee Listing

Listing (Without
Email Address) ID # Name Home Phone Work Phone Location
894253 Jay Smith 888-555-1212 999-666-0202 Plant A
999524 Mel Dunn 777-258-489 999-125-3589 Plant B
125896 Val Jones 555-678-6892 999-258-4789 Plant C

Employee Determine whether the Employee Listing (Without Email Address) is an

Listing elementary process. The following table shows the analysis.
(Without Email
Address)
Elementary Process Counting Rules Does the Rule Apply?
• is meaningful to the user Yes. The Employee Listing (Without Email
Address) is a functional user requirement.
• constitutes a complete transaction Yes. The Employee Listing (Without Email
Address) is a complete transaction
satisfying a group of users.
• is self-contained and Yes. The Employee Listing (Without Email
Address) is meaningful by itself.
being counted in a consistent state state when the Employee Listing (Without
Email Address) is created.
2. Identify an elementary process for each The Employee Listing (Without Email
unit of activity identified that meets all of Address) meets all of the above criteria.
the above criteria
Conclusion The Employee Listing (Without Email Address) meets the requirements of an
elementary process.

Elementary
Processes
they:
• Require the same set of DETs and Yes. Employee Listing (Without Email
Address) requires a different set of DETs
than Employee Listing (With Email
Address).
• Require the same set of FTRs and Yes. Employee Listing (Without Email
Address) requires a different set of FTRs
than Employee Listing (With Email
Address).
• Require the same set of processing Yes. Employee Listing (Without Email
logic to complete the elementary Address) has a different set of processing
process logic than Employee Listing (With Email
Address).
Conclusion The Employee Listing (Without Email Address) elementary process is unique

Employee Determine whether the Employee Listing (With Email Address) is an

Listing elementary process. The following table shows the analysis.
(With Email
Address)
Elementary Process Counting Rules Does the Rule Apply?
• is meaningful to the user Yes. The Employee Listing (With Email
Address) is a functional user requirement.
• constitutes a complete transaction Yes. The Employee Listing (With Email
Address) is a complete transaction
satisfying a group of users.
• is self-contained and Yes. The Employee Listing (With Email
Address) is meaningful by itself.
being counted in a consistent state state when the Employee Listing (With
Email Address) is created.
2. Identify an elementary process for each The Employee Listing (With Email
unit of activity identified that meets all of Address) meets all of the above criteria.
the above criteria
Conclusion The Employee Listing (With Email Address) meets the requirements of an
elementary process.

Elementary
Processes
they:
• Require the same set of DETs and Yes. Employee Listing (With Email
Address) requires a different set of DETs
than Employee Listing (Without Email
Address).
• Require the same set of FTRs and Yes. Employee Listing (With Email
Address) requires a different set of FTRs
than Employee Listing (Without Email
Address).
• Require the same set of processing Yes. Employee Listing (With Email
logic to complete the elementary Address) has a different set of processing
process logic than Employee Listing (Without
Email Address).
Conclusion The Employee Listing (With Email Address) elementary process is unique
Two processes are determined to meet the criteria of an elementary process,
then compared to each other to determine if they contain different DETs,
FTRs or Processing Logic.
When the two elementary processes are compared and it is determined that
they contain different DETs, FTRs or Processing Logic, they are identified as
separate elementary processes if they are specified as distinct functional user
requirements by the user.
Two unique elementary process are identified:

• Listing Employees (Without Email Address) and
• Listing Employees (With Email Address)

EI Counting Examples

procedures to count external inputs. In addition to this section, examples are
in the Case Studies.
Topic Page
Summary Descriptions of EI Counting Examples 2-62
Example: Report Control Information 2-63
Example: Screen Input 2-67
Example: Batch with Multiple EIs and Duplicate EIs 2-70
Example: Correcting Suspended Transactions 2-73
Example: EI with Multiple File Types Referenced 2-76
Example: Data Conversion 2-80
Example: Referencing Data from Another Application 2-83
Example: EI with Screen Output - 1 2-85
Example: EI with Screen Output - 2 2-88
Example: EI with Attributes Retrieved from an EIF 2-91
Example: EI Delete 2-97
Example: Add Window Security 2-100

EI Counting Examples Part 4 - Examples
Summary Descriptions of EI Counting Examples

The examples for external inputs are listed and described in the following
table.
Report Control This example looks at control information used 2-63

Information for reporting.
Screen Input This example illustrates counting an online add 2-67

transaction via a screen.
Batch with Multiple This example shows counting a transaction file 2-70
EIs and Duplicate EIs with multiple types or formatted record types.
Correcting Suspended This example illustrates counting making 2-73

Transactions corrections to jobs suspended to a file during
batch processing of adding or changing jobs.
EI with Multiple File This example illustrates using a data flow 2-76
Types Referenced diagram to count an external input that
references multiple files.
Data Conversion This example illustrates counting the process of 2-80

converting a group of data to a new format with
additional data elements.
Referencing Data from This example looks at why an external interface 2-83
Another Application file (discussed in Part 2,Chapter 6) is not
counted as an external input.
EI with Screen Output This example illustrates an EI with a calculated 2-85

–1 field that is displayed.
EI with Screen Output This example illustrates an EI with a calculated 2-88

–2 field and embedded EQs.
EI with Attributes This example illustrates an EI with attributes 2-91

Retrieved from an EIF retrieved from an EIF that do not cross the
boundary.
EI Delete This example illustrates counting DETs for a 2-97

delete transaction.
Add Window Security This example illustrates counting functionality 2-100

to maintain application security.

Part 4 - Examples EI Counting Examples
Example: Report Control Information

User The user requires the ability to control how and where assignment reports are
Requirements printed. The following list shows the specific user requirements for
generating the report:
1. Control the following aspects of report processing:
• Sort sequence
• Printer port
• Output format (i.e., microfiche and/or paper)
2. Save the job assignment reporting controls.
3. Make and save changes.
4. Send a message to confirm that the controls for the assignment reports
have been added or changed, and that the report is being generated.
Note: This example shows only the requirement to add the group of
assignment report control information. The Case Studies illustrate
counting the entire user requirement.
Example The following Job Assignments Report window is used to Establish Controls
Window for Reporting Job Assignments.

Employee Jobs Assignments Locations Help
Job Asssignments Report

Sort
3 Job ID
2 Employee Number
1 Employee
Ident ify with 1, 2 & 3
Print er Port
( ) LPT
( ) LPT
OK
( ) LPT
Cancel
G enerate Microf iche Copy
Restore
Generate Paper Copy
JR-1 Job Assignments Report

OK Processes report
Cancel Returns to pull down m enu
Restore Restores previous value s

Step 1 Identify the Elementary Process
Does the Transactional Function meet Yes.

the requirements of an Elementary
Process?
Step 2 Determine whether the Elementary Process is unique
Is the Transactional Function unique Yes. No other elementary process

from other elementary processes? performs this function.
Step 3 Classify each Elementary Process

EI Counting Rules Does the Rule Apply?
1. It has a primary intent of either:
• maintaining one or more ILFs or Yes. The data entering the boundary will
eventually be used as control data. It is
business data stored on the Report Control
ILF.
• altering the behavior of the No.
application
2. It includes processing logic to accept data Yes. Report Control information enters the
or control information that enters the boundary.
boundary of the application
Conclusion Establish Controls for Reporting Job Assignments is one EI.
Step 4 Count File Types Referenced (FTRs)

FTR Counting Rule Does the Rule Apply?
1. One FTR shall be counted for each The Report Control ILF is maintained and
unique data function that is accessed read. It is counted only once.
(read from and/or written to) by the
transactional function

Step 5 Count Data Element Types (DETs)

DET Counting Rule Does the Rule Apply?
1. Count one DET for each unique user Sort Sequence, Printer Port, Output Format.
recognizable, non-repeated attribute that
crosses (enters and/or exits) the boundary
during the processing of the transactional
function
2. Count only one DET per transactional User Message.
function for the ability to send an
application response message even if
there are multiple messages
3. Count only one DET per transactional OK button.
function for the ability to initiate action(s)
even if there are multiple means to do so
4. Do not count the following items as
DETs:
• literals such as report titles, screen or None of the screen literals are counted.
panel identifiers, column headings
and attribute titles
• application generated stamps such as There are no items of this type.
date and time attributes
• paging variables, page numbers and There are no items of this type.
positioning information; e.g., ‘Rows
37 to 54 of 211’
• navigation aids such as the ability to There are no items of this type.
navigate within a list using
“previous”, “next”, “first”, “last” and
their graphical equivalents
• attributes generated within the There are no items of this type.
boundary by a transactional function
and saved to an ILF without exiting
the boundary
• attributes retrieved or referenced There are no items of this type.
from an ILF or EIF for participation
in the processing without exiting the
boundary

1 FTR and 5 DETs Complexity is Low
Functional Size of 1 Low EI 3 FP

Example: Screen Input

Requirements
• Add job information online
• Generate an error message and highlight incorrect fields so that the error
may be corrected online
• Save job information added
Example The following Job Data screen is used to Add a New Job.
Screen
Action:_ 7=Prior 8=Following 9=Save

Job Data
Job number: RD15379305
Job name: May Issue - Print Covers
Pay grade: JRNY05A
Line No Job Description

01 Print Covers 4-Up, Lacquer Finish.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
F1=Help F7=Scroll up F8=Scroll down F12=Cancel
Enter: returns to calling screen. F1: shows screen or field level help.
Action 7: shows prior job data, if present. F7: scrolls up 10 job description lines.
Action 8: shows following job data, if present. F8: scrolls down 10 job description lines.
Action 9: saves entered job data. F12: returns to calling screen.


Process?


• maintaining one or more ILFs or Yes. The Job ILF is maintained.

• altering the behavior of the No. The behavior of the application is not
application altered.
2. It includes processing logic to accept data Yes. Job information enters the boundary in
or control information that enters the order to maintain the Job ILF.
Conclusion Add a New Job is one EI.

Refer to the Case Studies to see how the change and delete requirements and
associated screens are counted.

1. One FTR shall be counted for each The Job ILF is maintained and read, but it is
unique data function that is accessed counted only once.


1. Count one DET for each unique user Job Number, Job Name, Job Pay Grade, Job
recognizable, non-repeated attribute that Description (Repeated). Job Description
crosses (enters and/or exits) the boundary Line Number exists for technical reasons
during the processing of the transactional only and should not be counted as a DET.
function
2. Count only one DET per transactional Error Messages.
3. Count only one DET per transactional Add Action key.
DETs:
• literals Literals such as “Job number” are not
counted.
• application generated stamps There are no items of this type.
• paging variables There are no items of this type.
• navigation F7 and F8.
• attributes generated without exiting There are no items of this type.
the boundary and
from an ILF or EIF without exiting
the boundary

Example: Batch with Multiple EIs and Duplicate EIs

Requirements
• Add job information in batch mode
• Change job information in batch mode
Note: The focus of this example is adding a job in batch mode. The
previous example looked at the online mode. The Case Studies
illustrate counting all user requirements for adding jobs in both online
and batch modes.
Construction It was decided that during the batch process, any jobs not successfully
Requirements updated would error into a suspense file, which will be separately
maintained. (See next example)
Record Layout The following diagram shows the record layout for this example.
123456789101234567890123456789012345678901234567890123456789012345678901234567890
1 ADD⏐01⏐SRENG⏐SENIOR ENGINEER INFORMATION SYSTEMS ⏐05⏐

2 ADD⏐02⏐SRENG⏐01⏐STARTS AT PAY GRADE 05 ⏐
3 ADD⏐02⏐SRENG⏐02⏐OTHER PAY GRADES:06 AND 07 ⏐
4 CHG⏐01⏐STENG⏐ ⏐04⏐
5 CHG⏐02⏐STENG⏐02⏐OTHER PAY GRADES:05 AND 06 ⏐
6
7
8
9
0
Record The following table includes descriptions for each record type.
Descriptions
Record Position Description

01 1-3 Transaction type
4-5 Record type
6-10 Job number
11-45 Job name
46-47 Job pay grade
02 1-3 Transaction type
4-5 Record type
6-10 Job number
11-12 Description line number
13-41 Description line

Where Record Types are:

01 Add record for a new job
02 Add record for descriptions of a new job
Step 1 Identify the Elementary Process – Transaction Type 01
Does the Transactional Function meet No. A job without a description is

the requirements of an Elementary not meaningful to the user.
Process?
Step 1 Identify the Elementary Process – Transaction Type 02
Does the Transactional Function meet No. A description cannot exist

the requirements of an Elementary without the job it is describing. The
Process? data would be inconsistent.
Step 1 Identify the Elementary Process – Transaction Type 1 + 2
Does the Transactional Function meet Yes. Job and description are
the requirements of an Elementary meaningful to the user.
Process?
Is the Transactional Function unique Yes. The Add a Job Batch function
from other elementary processes? (Transaction Type 1+2) is similar to
the Add a Job Online function in the
previous example. The Add a Job
Batch function maintains an
additional ILF (Suspended Job) that
the online function does not.
Step 3 Classify each Elementary Process – Transaction Type 1 + 2

• maintaining one or more ILFs or Yes. Add Job has the primary intent to
maintain the Job ILF.
2. It includes processing logic to accept data Yes. Add Job includes processing logic to
or control information that enters the accept Job information.

Conclusion Add a Job (Transaction Type 1 + 2) is one EI.

1. One FTR shall be counted for each The Job ILF is maintained and read, but it is
unique data function that is accessed counted only once. The Suspended Job ILF
(read from and/or written to) by the is maintained.

1. Count one DET for each unique user Job Number, Job Name, Job Pay Grade, Job
recognizable, non-repeated attribute that Description (Line Repeated).
Transaction Type and Job Description Line
Number exist for technical reasons and are
function
not counted as a DET.
2. Count only one DET per transactional Not Applicable. Errors are recorded in a
function for the ability to send an Suspense File.
3. Count only one DET per transactional Transaction Type.
DETs:
• literals There are none.
• application generated stamps There are none.
• paging variables There are none.
• navigation There are none.
• attributes generated without exiting There are none.
the boundary and
• attributes retrieved or referenced There are none.
the boundary
2 FTR and 5 DETs Complexity is Average
Functional Size of 1 Average EI 4 FP

Example: Correcting Suspended Transactions

User It was decided that during the batch process that any jobs not successfully
Requirements updated would be saved to a suspense file. The user requires a screen to
access and edit the transactions that are incorrect.
Note: The focus of this example is only the requirement to correct
suspended transactions. The Case Studies illustrate counting the
entire user requirement.
Diagram
2.7
View
Suspended Job
2.7 suspended job

information transaction type,
Update job name, job#,
Suspended Job pay grade,
job suspense information
description
transaction type,
job name, job#,
pay grade,
2.7 job suspense
description
information JOB SUSPENSE
Delete
Suspended Job
transaction type,
job#
2.2.2
Add Pay Grade PAY GRADE

pay grade info
pay grade, pay
grade descr pay grade info
2.1.2
2.7
User List Pay Grades User
Add Job Batch pay grade list
transaction type, job name,
job#, pay grade, description
invalid job valid job

information information Job List (w ithout totals):
job name, job #
JOB SUSPENSE JOB 2.2.3
job information List Jobs

(without totals )
invalid job valid job
information information Job List (with totals ):
job name, job #, pay grade,
2.7 descr, total jobs
Update Job Batch 2.5

transaction type, job name, job information
job#, pay grade, description List Jobs
(w ith totals)
Legend:


Process?


• maintaining one or more ILFs or Yes. Correcting Suspended Job Transaction

has the primary intent to maintain the
Suspended Job ILF.
2. It includes processing logic to accept data Yes. Add Job includes processing logic to
or control information that enters the accept Job information.
Conclusion Correcting Suspended Job Transaction is one EI.

1. One FTR shall be counted for each The Suspended Job ILF is maintained and
unique data function that is accessed referenced, but it is counted only once.


1. Count one DET for each unique user Transaction Type, Job Number, Job Name,
recognizable, non-repeated attribute that Job Pay Grade, Job Description Line
crosses (enters and/or exits) the boundary (Repeated).
The Record Type and Job Description Line
function
Number exist for technical reasons and are,
therefore, not counted. All other fields are
user recognizable.
2. Count only one DET per transactional There are no messages.
3. Count only one DET per transactional Enter key.
DETs:
the boundary and
the boundary

Example: EI with Multiple File Types Referenced

User The user requires the ability to Add Job Assignments.
Requirements Note: The focus of this example is only the requirement to add job
assignments. The Case Studies illustrate counting the entire user
requirement.
Example The following diagram shows an example of the window to add job
Window assignments.

Job Assignment Setup
Mark J Manship
Social Security Number 345-67-8901
Location Main Plant Bargaining Unit UFPCA
Job Number RD15379305 May Issue – Print Covers
Date
OK
Salary
Performance Rating Cancel
AE-3 Job Assignment Setup
OK Saves new job assignment, returns to AE-1 Employee Assignment List
Cancel Ignores data entered, returns to AE-1 Employee Assignment List

Data Flow The following diagram shows the data flow for the job assignment process.
Diagram
3.8
SCR
Process Screen
HELP screen id, screen Level Help
name, description
screen id, screen

name, description
3.1 error and confirmation messages
Assign Employee
name, ssn, location, to Job
bargain unit, job#, date, job assignment info
salary, perf rating, job
name (display only )
ssn
JOB
job#, job
EMPLOYEE / name
DEPENDENT job#, job name
JOB ASSGNMT
3.2 job assignment info
ssn
Transfer
Employee
name, ssn, location,
bargain unit, job#, date, error and confirmation messages
salary, perf rating, job
name (display only )
ssn, job# 3.3 error and confirmation messages

User Delete Job User
Assignment
effective date,
status inactive
JOB ASSGNMT JOB
EMPLOYEE /
DEPENDENT
job assignment info job name
3.4
name, location,
bargain unit Inquire Job
Assignment
ssn, job# name, ssn, location, bargain unit, job#, job
name, salary, effectiv e date, perf rating
Legend:


Process?


• maintaining one or more ILFs or Yes. Add Job Assignments has the primary
intent to maintain the Job Assignment ILF.
2. It includes processing logic to accept data Yes. Add Job Assignment includes
or control information that enters the processing logic to accept Job Assignment
boundary of the application information.
Conclusion Add Job Assignments is one EI.

1. One FTR shall be counted for each The Employee ILF is read to ensure the
unique data function that is accessed employee exists.
The Job ILF is read to ensure the job exists.
The Job Assignment ILF is maintained and
read, but it is only counted once.


1. Count one DET for each unique user Employee Name, Social Security Number,
recognizable, non-repeated attribute that Location, Bargaining Unit, Job Number,
crosses (enters and/or exits) the boundary Job Name, Effective Date, Salary,
during the processing of the transactional Performance Rating.
function
The screen depicts the Employee Name
field as three physical fields, although the
data flow diagram depicts it as a single
element. Based upon review of the
application functionality, the Employee
Name is always used in its entirety. There
are no screens or reports where a single
piece of the name is used without the others.
It is counted as a single DET.
DETs:
• literals Literals such as “Job number” are not
counted.
the boundary and
the boundary
3 FTRs and 11 DETs Complexity is High
Functional Size of 1 High EI 6 FP

Example: Data Conversion

User The user has purchased a new HR application package. The user requires
Requirements the ability to Convert Employee Information by migrating existing employee
information (Name, Social Security Number, Number of dependents, Type
code, Supervisory level, Standard hourly rate, Collective bargaining unit
number, and Location name) to the new application.
The old system did not let the user maintain employee dependent's
information. The dependent's information can be created after existing
employees are migrated to the new application.
Note: Part 3 , Chapter 5 (Data Conversion Activity) explains how data
conversion is measured.
Data Diagrams The following diagram shows the data for the old and new applications.
Old New
HR Application HR Application
EMPLOYEE EMPLOYEE
SALARIED_EMPL SALARIED_EMPL
HOURLY_EMPL HOURLY_EMPL
DEPENDENT
Legend:
Entity Type
Entity Subtype

Process?



• maintaining one or more ILFs or Yes. The Employee ILF is maintained.

2. It includes processing logic to accept data Yes. Data from the employee file of the old
or control information that enters the HR application crosses the boundary.
Conclusion Convert Employee Information is one EI.

1. One FTR shall be counted for each The Employee ILF is maintained and read,
unique data function that is accessed but it is counted only once.


1. Count one DET for each unique user Name, Social Security Number, Number of
recognizable, non-repeated attribute that Dependents, Type Code, Supervisory Level,
crosses (enters and/or exits) the boundary Standard Hourly Rate, Collective
during the processing of the transactional Bargaining Unit Number, Location Name.
function
2. Count only one DET per transactional There are none.
DETs:
the boundary and
the boundary

Example: Referencing Data from Another Application

User The user requires the Human Resources application to provide the following
Requirements capabilities:
• All hourly employees must be paid in U.S. Dollars.
• When adding or changing employee information, the Human Resources
application must access the Currency application to retrieve a currency
conversion rate. After retrieving the currency conversion rate, the HR
application converts the employee's local standard hourly rate to a U.S.
hourly rate using the following calculation:
Standard Hourly Rate
= U.S. Dollar Hourly Rate
Currency Conv. Rt.
Data Diagram The following diagram shows the relationship for this example.
Currency Application HR Application
EMPLOYEE
CONVERSION SALARIED_EMPL
RATE
HOURLY_EMPL
DEPENDENT
Legend:
Entity Type
Entity Subtype

Currency The currency conversion information includes

Conversion
Information CURRENCY
• Conversion_Rate_To_Base_Currency
• Currency
Does the Transactional Function meet No. Referencing the data is only
the requirements of an Elementary meaningful when associated with
Process? adding an employee.
Conclusion There is not an EI for the retrieval of currency conversion information. Refer
to the EIF counting examples in the Data Function Counting Examples to see
why currency conversion information may be counted as an EIF when adding
or changing employee information. Adding and Changing Employee
information are counted as EIs.

Example: EI with Screen Output - 1

User The user requires the ability to Enter a Sales Transaction for a customer. The
Requirements cost of each item is to be shown, and the transaction total must be displayed
for review before the information is saved. If any errors occur, appropriate
error messages are displayed.
Example Screen The following sales transaction screen is a simplification to illustrate how
output fields are counted. The user enters the customer name and transaction
date. As each item and quantity required is entered, the system calculates and
displays the costs as shown.
Sales Transaction
Customer Name: __________________________________________

Transaction Date: ________
Item Qty Item Cost Item Total Cost

__________________________ _____ $____.__ $____.__
__________________________ _____ $____.__ $____.__
__________________________ _____ $____.__ $____.__
__________________________ _____ $____.__ $____.__
__________________________ _____ $____.__ $____.__
__________________________ _____ $____.__ $____.__
Sub Total $____.__

Sales Tax $____.__
Total $____.__
F1=Save

Process?



• maintaining one or more ILFs or Yes. Entering a Sales Transaction has the
primary intent to maintain the Sales
Transaction ILF.
2. It includes processing logic to accept data Yes. Entering a Sales Transaction includes
or control information that enters the processing logic to accept sales information.
Conclusion Enter a Sales Transaction is one EI.

1. One FTR shall be counted for each The Sales Transaction ILF is read and
unique data function that is accessed maintained, but is counted only once.


1. Count one DET for each unique user The following input DETs are counted:
recognizable, non-repeated attribute that Customer Name
crosses (enters and/or exits) the boundary Transaction Date
during the processing of the transactional Item (repeated)
function Quantity (repeated)
The following output DETs are counted:
Item Cost (repeated)
Item Total Cost (repeated)
Transaction Sub Total
Sales Tax
Transaction Total
3. Count only one DET per transactional F1 key.
DETs:
• literals Literals such as “Item” are not counted.
the boundary and
the boundary
Functional Size of 1 Average EI 3 FP

Example: EI with Screen Output - 2

User The user requires the ability to Assign a Job to an employee. In order to
Requirements select an employee and job, the user requires the ability to reference the
employee and job files using 2 drop down lists. The employee list is required
to show the employee number and name. The jobs list is required to show the
job number and its description. The number of employees assigned to the job
is to be displayed after the record is saved. In the event of an error, an
appropriate message is displayed.
Example Screen The following Job Assignment screen is a simplification to illustrate how
output fields are counted. The user selects the employee from a drop down
list showing the employee name and employee number. On selection, the
system needs the employee number for the assignment. The user selects the
job from a dropdown list showing the job number and its description. The
system needs the job number for the assignment. When the assignment is
saved, the system determines the number of employees and displays it to the
user.

Employees Jobs Assignments Locations Help
Job Assignment
Employee Number 1290 1290 James, R.W

Job Number 0100 0100 Apply Lacquer
Assignment Date 12/12/1998
Save
Total Number of Employees assigned to this Job 3
The list boxes for Jobs and Employees are EQs and are not analyzed in this
example.


Process?


• maintaining one or more ILFs or Yes. Assign a Job has the primary intent to
maintain the Job Assignment ILF.
2. It includes processing logic to accept data Yes. Assign a Job includes processing logic
or control information that enters the to accept Job Assignment information.
Conclusion Assign a Job is one EI.

1. One FTR shall be counted for each The Job Assignment ILF is maintained.
unique data function that is accessed
The Employee and Job ILFs are not counted
as FTRs, as they are part of separate EQs.


1. Count one DET for each unique user The following input DETs are counted:
recognizable, non-repeated attribute that Employee Number
crosses (enters and/or exits) the boundary Job Number
during the processing of the transactional Assignment Date
function
The following output DETs are counted:
Employees Assigned To Job
The Employee Name and Job Name DETs

in the dropdowns are not counted as DETs,
as they are part of separate EQs.
2. Count only one DET per transactional A message is returned in the event of an
function for the ability to send an error.
3. Count only one DET per transactional There is only one way the function can be
function for the ability to initiate action(s) invoked, via the Save button.
DETs:
• literals Literals such as “Job Number” are not
counted.
the boundary and
the boundary

Example: EI with Attributes Retrieved from an EIF

User The user requires the ability to Add an Employee by entering:
Requirements
• Salary or hourly rate information
• Dependent’s information
• The location must be a valid location in the Fixed Asset System (FAS).
• The hourly rate is converted to U.S. Dollars; the currency data is
accessed from the Currency System in order to convert a standard hourly
rate in U.S. Dollars based upon the currency of the employee
Example The following are examples of the windows to add an employee.

Screens

Employee Setup
Last Name
First Name
Middle Initial
Social Security Number
Number of Dependents
Location Main Office New Supervisor Level
New Bargaining Unit
Salary Type OK
( ) Hourly
( ) Salaried Cancel
EN-1 Employee Setup

New Supervisor Level Navigates to SL-1 Supervisor Level
New Bargaining Unit Navigates to BU-1 Bargaining Unit
OK Navigates to next screen:

• EN-2H, if hourly salary type is selected
• EN-2S, if salaried salary type is selected
Cancel Goes back to pull down menu


Employee Setup
Last Name
First Name
Middle Initial
Salaried Employee Setup
Supervisor Level First Line Manager
OK
Cancel
Dependents
EN-2S Employee Setup: Salary

OK Saves new employee data and returns refreshed EN-1 Employee Setup
Cancel Returns to EN-1 Employee Setup (no data saved)
Dependents Navigates to EN-3 Employee Dependent Setup

(data on EN-2S Employee Setup salary is kept in memory)

Employee Setup
Last Name
First Name
Middle Initial
Hourly Employee Setup

Hourly Rate
Bargaining Unit UFPCA

OK
Cancel
Dependents
EN-2H Employee Setup: Hourly

OK Saves new employee data and returns refreshed EN-1 Employee Setup
Cancel Returns to EN-1 Employee Setup (no data saved)
Dependents Navigates to EN-3 Employee Dependent Setup

(data on EN-2H Employee Setup Hourly is kept in memory)


Employee Setup
Salaried Employee Data
Dependent Setup
Last Name
First Name
Middle Initial
OK
Cancel
Birth Date
More Dependents
EN-3 Employee Dependent Setup
OK
Saves new dependent data and returns to EN-1 Employee Setup
Cancel Returns to EN-2H Employee Setup Hourly or

EN-2S Employee Setup Salary (no data saved)
More Dependents Accepts dependent data and returns refreshed
EN-3 Employee Dependent Setup

Process?



• maintaining one or more ILFs or Yes. Add an Employee has the primary
intent to maintain the Employee ILF.
2. It includes processing logic to accept data Yes. Add an Employee includes processing
or control information that enters the logic to accept Employee information.
Conclusion Add an Employee is one EI.

1. One FTR shall be counted for each The Employee ILF is maintained. The
unique data function that is accessed Currency and Location EIFs are referenced.


1. Count one DET for each unique user Name (Last Name, First Name, Middle
recognizable, non-repeated attribute that Initial), Social Security Number, Number of
crosses (enters and/or exits) the boundary Dependents, Location, Salary Type,
during the processing of the transactional Supervisor Level, Hourly Rate, Bargaining
function Unit, Dependent Name (Last Name, First
Name, Middle Initial), Dependent Social
Security Number, Dependent Birth Date.
The screen depicts the Employee Name
field as three physical fields. Based upon
review of the application functionality, the
Employee Name is always used in its
entirety. There are no screens or reports
where a single piece of the name is used
without the others. The same is also true of
the Dependent Name. The Employee Name
and Dependent Name are each counted as a
single DET.
DETs:
• literals Literals such as “Last Name” are not
counted.
• attributes generated without exiting US Hourly Rate is calculated, but it does
the boundary and not exit the boundary.
• attributes retrieved or referenced Conversion Rate To Base Currency is
from an ILF or EIF without exiting retrieved from the Currency EIF in order to
the boundary calculate the US Hourly Rate, but does not
exit the boundary.

3 FTR and 13 DETs Complexity is High
Functional Size of 1 High EI 6 FP

Example: EI Delete
User The user requires the ability to Delete an Employee.
Requirements
Delete all information about an individual employee. When deleting an

employee currently assigned to a job, update the job assignment to set the
status to inactive.
• Generate error messages and highlight incorrect fields if the fields do not
pass edits. Five (5) error messages and one (1) confirmation message are
included for the employee information delete transaction.
• When deleting an employee, update Status Inactive with an “X” and put
the system date in Effective Date for each associated Job Assignment.
Example The following is an example of the window used to delete an employee.

Window

Employee Edit
Kathleen Schmidt-Taylor
SSN 456- 78-9012 OK
Location Main Office Cancel
Salary Type Salaried Restore
Dependents 4 Dependents Delete
New Supervisor Level Salary Data
New Bargaining Unit Dependents
EE2 – Employee Edit

Delete Asks for confirmation, then
Saves changes- made, deletes employee record &
OK returns to EE -1 associated dependent records
Employee List
Navigates to:
Salary Data
Cancel Ignores changes, EE-3S Employee
- Salary, if value is “Salaried”
returns to EE -1 EE-3H Employee
- Hourly, if value is “Hourly”
Employee List
Dependents Causes list on EI-4 Dependent List to display
Restore Restores prior values
New Supervisor Level Navigates to SL -1 Supervisor Level
New Bargaining Unit Navigates to BU -1 Bargaining Unit


Process?


• maintaining one or more ILFs or Yes. Delete an Employee has the primary
intent to maintain the Employee ILF.
2. It includes processing logic to accept data Yes. Delete an Employee includes
or control information that enters the processing logic to accept Employee
boundary of the application information.
Conclusion Delete an Employee is one EI.

1. One FTR shall be counted for each The Job Assignment ILF is maintained. The
unique data function that is accessed Employee ILF is both referenced and
(read from and/or written to) by the maintained.


1. Count one DET for each unique user Social Security Number. All other attributes
recognizable, non-repeated attribute that on the screen are part of the inquiry that
crosses (enters and/or exits) the boundary preceeds the Delete. They are not counted
during the processing of the transactional as DETs for the Delete.
function
3. Count only one DET per transactional Delete button.
DETs:
• literals Literals such as “SSN” are not counted.
• attributes generated without exiting The Status Inactive attribute is updated, but
the boundary and does not exit the boundary. It is not
counted.
the boundary

Example: Add Window Security

User The requirement for manage security was added during the Construction
Requirements phase. The user wants to add, change, delete and inquire on Human
Resources System security information. The add functionality is illustrated
below.
Add window security information by entering

• User Identifier
• Windows for Job Assignment, Job, Employee, Location and Report
Generator functions
• User Security for those functions (i.e., access or no access)
Generate error messages and highlight incorrect fields if the fields do not
pass edits. Two (2) error messages and one (1) confirmation message are
included for the security information add transaction.
Add Window The following illustration shows the window to add window security.
Security Screen

HR Window Security Setup
User Id
Job Employee
Job Assignment
Setup Setup
Setup
Inquiry Inquiry
Inquiry (Job)
Edit Edit
Inquiry (Employee)
Reports Reports
Edit
Reports
Report Generator Location

Definition Review
Define
OK
Edit
Inquiry Cancel
SW-1 HR Window Security Setup
OK Commit changes, return to to Human Resources System main menu

Cancel Return to Human Resources System main menu
The boxes in the illustration above represent Window IDs.


Process?


• maintaining one or more ILFs or Yes. The Window Security ILF is

maintained.
application altered. The behavior of the application will
be altered by controlling the functionality
that the user can perform when they logon.
2. It includes processing logic to accept data Yes. Window Security information enters
or control information that enters the the boundary in order to maintain the
boundary of the application Window Security ILF.
Conclusion Add Window Security is one EI.

Refer to the Case Studies to see how the change and delete requirements and
associated screens are counted.

1. One FTR shall be counted for each The Window Security ILF is maintained.


1. Count one DET for each unique user User Identifier, Windows, User Security.
function
3. Count only one DET per transactional OK Action key.
DETs:
• literals Literals such as “User Id” are not counted.
• application generated stamps There are no items of this type.
• paging variables There are no items of this type.
• navigation There are no items of this type.
• attributes generated without exiting There are no items of this type.
the boundary and
the boundary

EO Counting Examples

procedures used to count external outputs. In addition to this section,
examples are in the Case Studies included in supplemental IFPUG
documentation.
Contents This section includes following examples:
Topic Page
Summary Descriptions of EO Counting Examples 2-104
Example: Hard Copy Report Output 2-105
Example: Online Reporting 2-108
Example: Transaction Sent to Another Application 2-111
Example: Error/Confirmation Messages 2-113
Example: Performance Review Notification 2-114
Example: EO Triggered without Data Entering the 2-117
Boundary
Example: Primary Intent of an EO 2-120
Example: EO Transaction File 2-123

EO Counting Examples Part 4 - Examples
Summary Descriptions of EO Counting Examples
The examples for EOs are described in the following table.
Hard Copy Report This example illustrates counting a hard copy 2-105
Output report.
Online Reporting This example shows the count for an online 2-108
report.
Transaction Sent to This example illustrates a transaction generated 2-111

Another Application by one application and sent to another
application.
Error/Confirmation This example shows that error or confirmation 2-113

Message messages are not counted as external outputs.
Performance Review This example illustrates a notification based 2-114

Notification upon a calculation.
EO Triggered without This example illustrates the concept that an EO 2-117

Data Entering the can be triggered without data entering the
Boundary boundary.
Primary Intent of an This example illustrates that an EO can update a 2-120

EO file.
EO Transaction File This example illustrates the existence of 2-123

calculations determines that the elementary
process is an EO and not an EQ.

Part 4 - Examples EO Counting Examples
Example: Hard Copy Report Output
User The user of the Human Resources System requires a listing of employee job
Requirements assignments.
The report is generated by retrieving:
• An assignment from the job assignment ILF
• Additional information from the employee and job ILFs
The report control ILF is referenced to determine how to generate the report.
Example The following Job with Employees Report lists jobs and the employees
Report assigned to them.
HRS006 Human Resource System Page 1

Jobs with Employees Date 99.99.99
Job Number Job Name Employee SSN Employee Name

9999 xxxxxxxxxx xxx-xx-xxxx xxxxxxxxxxxxxxx
xxx-xx-xxxx xxxxxxxxxxxxxxx

Total Jobs 9999


Process?


EO Counting Rules Does the Rule Apply?
1. It has the primary intent of presenting Yes. The Jobs with Employees report has
information to the user, and the primary intent to present information to
the user.
2. It includes at least one of the following
forms of processing logic:
• mathematical calculations are Yes. The total number of jobs is considered
performed both calculated and derived.
• one or more ILFs are updated No. An ILF is not updated.
• derived data is created or Yes. The total number of jobs is considered

both calculated and derived.
• the behavior of the application is No. The behavior of the application is not
altered altered.
Conclusion The Job with Employees Report is one EO.

1. One FTR shall be counted for each The following ILFs are read:
• Employee
transactional function • Job
• Job Assignment
• Report Control


1. Count one DET for each unique user Job Number, Job Name, Employee SSN,
recognizable, non-repeated attribute that Employee Name and Total Jobs are
crosses (enters and/or exits) the boundary reported. Count each only once.
function
DETs:
• literals such as report titles, screen or Report identifiers, report titles and column
panel identifiers, column headings headings are not counted.
• application generated stamps such as The report date is not counted.
• paging variables, page numbers and The page number is not counted.
37 to 54 of 211’
• navigation aids such as the ability to There are none.
• attributes generated within the There are none.
the boundary
boundary
4 FTRs and 5 DETs Complexity is Average
Functional Size of 1 Average EO 5 FP

Example: Online Reporting
User The user requires a report of employees in descending sequence by the

Requirements duration of their current job assignments. This report is displayed online and
contains calculated/derived data (for example, the job assignment duration).
Example The following Employees by Assignment Duration screen layout lists

Screen employees by duration.
.
EMPLOYEES BY ASSIGNMENT DURATION
Rows 1 to 18 of 1,316 MM/DD/YY
Employee Employee Job Job Assignment

SSN Name Number Name Duration
xxx-xx-xxxx xxxxxxxxxx 9999 xxxxxxxxxx 99 mos.

xxx-xx-xxxx xxxxxxxxxx 9999 xxxxxxxxxx 99 mos.
Employees over 24 mos. 9999
Employees over 12 mos. 9999
F1=Help F7=Scroll up F8=Scroll down F16=End

Process?



1. It has the primary intent of presenting Yes. Employees By Assignment Duration
information to the user, and report has the primary intent to present
information to the user.
• mathematical calculations are Yes. Three calculated fields are considered
performed both calculated and derived.
• derived data is created or Yes. Three calculated fields are considered

both calculated and derived.
altered altered.
Conclusion The Employees by Assignment Duration report is one EO.

1. One FTR shall be counted for each The Employee, Job and Job Assignment
unique data function that is accessed ILFs are read. No ILFs are maintained.


1. Count one DET for each unique user Employee SSN, Employee Name, Job
recognizable, non-repeated attribute that Number, Job Name and Assignment
crosses (enters and/or exits) the boundary Duration are repeated. Count each only
during the processing of the transactional once.
function
Number of employees over 24 mos. and
over 12 mos.
3. Count only one DET per transactional A function key is used to display the online
function for the ability to initiate action(s) report.
DETs:
• literals Literals such as “Employee SSN” are not
counted.
• application generated stamps The report date is not counted.
• paging variables “Rows 1 to 18” are not counted.
• navigation F7 and F8 are not counted.
the boundary and
the boundary
Functional Size of 1 Average EO 5 FP

Example: Transaction Sent to Another Application

User When the Human Resources System adds employee dependent data, the user
Requirements requires that this Dependent File be sent to the Benefits application to keep
benefits records consistent. This information is sent to Benefits daily.
Construction If dependent data is added, that information is formatted properly on the

Requirements output transaction file.
When implementing a solution, it was decided to include a header and trailer
record with the benefits information. These records are used by Benefits to
ensure that nothing technically was incorrect when transmitting the file.
Example Record The following employee dependent record layout contains information about
Layout dependent additions and changes.
123456789101234567890123456789012345678901234567890123456789012345678901234567890
1 H⏐FILE NAME ⏐DATE ⏐

2 D⏐EMP SSN ⏐DEP SSN ⏐DEPENDENT NAME ⏐BDAY⏐
3 T⏐TOT. REC ⏐
4
5
6
7
9
0
Field The following table includes descriptions for each field on the record.
Descriptions
Record
Type Position Description
Header 1 Record type H
2-13 File name
14-19 Date created
Dependent 1 Record type D
2-10 Employee social security number
11-19 Dependent social security number
20-39 Dependent name
40-45 Dependent birth date
Trailer 1 Record type T
2-10 Total number of records

Step 1 Identify the Elementary Process - Header
Does the Transactional Function meet No. The header contains no user
the requirements of an Elementary meaningful data.
Process?
Step 1 Identify the Elementary Process - Trailer
Does the Transactional Function meet No. The trailer contains no user
the requirements of an Elementary meaningful data.
Process?
Step 1 Identify the Elementary Process - Dependent
Does the Transactional Function meet Yes. The dependent section of the
the requirements of an Elementary transaction file satisfies the
Process? requirements for an EP.


1. It has the primary intent of presenting Yes. The Dependent file has the primary
information to the user, and intent to present information to the user.
• mathematical calculations are No. Calculations are not performed.
performed
• derived data is created or No. Derived data is not created.
altered altered.
Conclusion The Dependent File does not qualify as an EO; it would be counted as an EQ
(not analyzed here).

Example: Error/Confirmation Messages

User Users require message feedback when job information is maintained. More
Requirements specifically, users require messages to indicate any edit or validation errors
or to indicate that the process completed successfully.
Example Screen The following Job screen shows a confirmation message (bottom of screen).
Action:_ 7=Prior 8=Following

Job Data
Job number: RD15379305
Job name: May Issue - Print Covers
Pay grade: JRNY05A
Line No Job Description

01 Print Covers 4-Up, Lacquer Finish.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
F1=Help F7=Scroll up F8=Scroll down F12=Cancel

Processing Completed Successfully
Enter: returns to calling screen. F12: returns to calling screen.

F1: shows screen or field level help. Action 7: shows prior job data, if present.
F7: scrolls up 10 job description lines. Action 8: shows following job data, if present.
F8: scrolls down 10 job description lines.
Does the Transactional Function meet No. The output of an error message
the requirements of an Elementary is not a self-contained function. It is
Process? an output DET on the Add Job EI.

Example: Performance Review Notification

User The user requires automatic notification when an employee has completed
Requirements 12 months in a job assignment. This indicates that a performance review
should be completed.
Example The following Performance Review Notification window describes the

Window notification message.
Performance Review Notification
As of Date: xx/xx/xx
Employee: xxx-xx-xxxx x_________________x
Has completed 12 months in assignment:
Job: xxxx x_______________________x
And should be scheduled for a performance review immediately.

Process?



1. It has the primary intent of presenting Yes. Performance Review Notification has
information to the user, and the primary intent to present information to
the user.
• mathematical calculations are Yes. The 12 month completion date is
performed calculated.
altered altered.
Conclusion The Performance Review Notification is one EO.

1. One FTR shall be counted for each Employee, Job and Job Assignment ILFs
unique data function that is accessed are read.


1. Count one DET for each unique user As of Date, Employee Social Security
recognizable, non-repeated attribute that Number, Employee Name, Job Number, Job
crosses (enters and/or exits) the boundary Name.
function
DETs:
• literals Literals such as “Employee” are not
counted.
• application generated stamps The report date and time are not counted.
the boundary and
the boundary
Functional Size of 1 Low EO 4 FP

Example: EO Triggered without Data Entering the

Boundary
User Users require that the application print the Weekly Employee Report
Requirement: automatically every Sunday night at 11:00 p.m. The report contains details
for each employee plus a total of the employees.
Data Model The following diagram shows the data flow for this example.
Weekly Employee Report

Name Location
Brown, B. Macomb
D’Souza, M. New Plymouth
Edwards, R. Freehold
Print Weekly Fischer, J. Palm Coast
Employee Report Garmus, D. Orange Park
Marthaler, V. Clarkston
Russac, J. Green Cove Springs
Thomas, P. Fareham Hampshire
Timp, A. Utrecht
Employee ILF Total Employees: 9

SSN
Name
Location

Process?



1. It has the primary intent of presenting Yes. The Weekly Employee Report has the
information to the user, and primary intent to present information to the
user.
• mathematical calculations are Yes. Total Employees is a calculated field.
performed
• derived data is created or Yes. The report contains a calculated field.
altered altered.
Conclusion The Weekly Employee Report is one EO.

1. One FTR shall be counted for each The Employee ILF is read. No ILFs are
unique data function that is accessed maintained.


1. Count one DET for each unique user Name, Location, Total Employees.
function
DETs:
• literals Literals such as “Name” are not counted.
the boundary and
the boundary

Example: Primary Intent of an EO

User Print a Check and, as a result, mark the account as paid. All data printed on
Requirements the check was already stored in the check file.
Print check
Check ILF
Check Number
Check Amount
Recipient
Account Paid Indicator
Check Date

Process?



1. It has the primary intent of presenting Yes. The primary intent is to print a check.
information to the user, and The maintenance of the ILF is secondary.
• mathematical calculations are No. Calculations are not performed.
performed
• one or more ILFs are updated Yes. The Check ILF is updated.
altered altered.
Conclusion Print a Check is one EO.

1. One FTR shall be counted for each The Check ILF is read and maintained, but
unique data function that is accessed is only counted once.


1. Count one DET for each unique user Check Number, Check Amount, Recipient,
recognizable, non-repeated attribute that Check Date.
function
DETs:
• application generated stamps There is a date printed on the check, but it
represents user recognizable data and is
counted.
• attributes generated without exiting The Account Paid Indicator is not counted
the boundary and as it does not cross the boundary.
the boundary

Example: EO Transaction File

User At the end of the month, generate a Monthly Check File and send it to
Requirements Application B. The check numbers, check dates, and check amounts are
included on the file with a computed count of the checks processed and the
total amount of all of the checks printed for the month. The number of
checks printed and total dollar amount for all checks printed are used by the
Application B users to provide banking reports.
Data Model The following diagram shows the data flow for this example.
Application A Application B
Generate
Monthly Check File
Monthly Check
File
Check number
Check Amount
Check Date
Month
No. of Checks Printed
Check ILF Total $ for all checks
Check Number
Check Amount
Check Date

Process?
Is the Transactional Function unique Yes. There is no other elementary

from other elementary processes? process that performs this function.


1. It has the primary intent of presenting Yes. The primary intent is to generate a
information to the user, and transaction file.
• mathematical calculations are Yes. The file includes two calculated fields.
performed
• derived data is created or Yes. The file includes two calculated fields.
altered altered.
Conclusion The Monthly Check File is one EO.

1. One FTR shall be counted for each The Check ILF is read. There are no ILFs
unique data function that is accessed maintained.


1. Count one DET for each unique user Check Number, Check Amount, Check
recognizable, non-repeated attribute that Date, Month, No. of checks printed, Total $
crosses (enters and/or exits) the boundary for all checks.
function
DETs:
the boundary and
the boundary


EQ Counting Examples

procedures to count external inquiries. In addition to this section, examples
are in the Case Studies included in the supplemental IFPUG documentation.
Topic Page
Summary Descriptions of EQ Counting Examples 2-128
Example: Application Menus 2-129
Example: List of Retrieved Data 2-131
Example: Drop-Down List Box 2-136
Example: Field Level Help–First Occurrence 2-140
Example: Field Level Help–Second Occurrence 2-143
Example: Implied Inquiry 2-145
Example: EQ Triggered without Data Entering the Boundary 2-149
Example: Data Sent to Another Application 2-152
Example: Additional Help Functionality 2-155
Example: Security Logon 2-159

EQ Counting Examples Part 4 - Examples
Summary Descriptions of EQ Counting Examples

The examples for EQs are listed and described in the following table.
Application Menus This example shows that navigational menus or 2-129

other navigational aids are not counted as EQs.
List of Retrieved Data This example illustrates the count for a list. 2-131
Drop-Down List Box This example illustrates counting a drop-down 2-136

list.
Field Level Help–First This example illustrates that field level help is 2-140
Occurrence counted for the first occurrence.
Field Level Help–Second This example illustrates that a second instance 2-143
Occurrence of field level help is not counted.
Implied Inquiry This example illustrates counting an inquiry that 2-145

is not explicitly stated but it is implied.
EQ Triggered without Data This example illustrates counting data retrieval 2-149
Entering the Boundary and display triggered internally by time.
Data Sent to Another This example illustrates counting data sent to 2-152
Application another application via a file.
Additional Help This example illustrates counting additional help 2-155

Functionality functionality.
Security Logon This example illustrates counting the logon 2-159

function.

Part 4 - Examples EQ Counting Examples
Example: Application Menus

User The Human Resources application requires navigation menus and aids.
Requirements
Example The following diagram shows the Employee drop-down menu on the Human
Windows Resources System main menu. This is the input request.

Employee Jobs Assignments Locations Rpt Man Security Help
New
Review
Edit
Report

When the user selects New on the Employee drop-down menu, the following
empty Employee Setup window is displayed.

Employee Setup
Last Name
First Name
Middle Initial
Number of Dependents
Location Main Office
Currency Location
OK
Salary Type
( ) Hourly
( ) Salaried Cancel
EN-1 Employee Setup
Cancel Goes back to pull down menu
OK Navigates to next screen:

• EN-2H Employee Setup Hourly, if hourly salary type is selected
• EN-2S Employee Setup Salary, if salaried salary type is selected
Does the Transactional Function meet No. Menus exist to satisfy

the requirements of an Elementary navigational requirements rather
Process? than functional user requirements.
Conclusion Menus do not satisfy the requirements of an elementary process.

Example: List of Retrieved Data

User The user has the following requirements:
Requirements
• View a List of Employees sorted by Last Name, First Name and Middle
Initial.
This example focuses on viewing a list of employees in the Human
Resources application.
Diagram
User
ssn, name, type, supv_cd, hr_rate,

bu_#, dep_ssn, dep_name, dep_birth,
loc_name
ssn 1.4 access allowed
Inquire Employee
empl
info Employee
access allowed
Security
Employee List
1.5 ssn, name, type,
empl info sal_type
EMPL/DEP Inquire List
of Employees
Review Request
Legend:

Example The following diagram shows the drop-down menu for employee. The
Windows Review field and the enter key make up the input side of this example.

New
Review
Edit
Report
When the user selects Review on the Employee drop-down menu, the
following window displays with a list of employees.

Employee List
Last Name First Name MI Social Security Salary Type
Keller Caroline 123-45-6789 Salaried
Latta Nicky A 234-56-7890 Hourly
Manship Mark J 345-67-8901 Hourly
Schmidt-Taylor Kathleen 456-78-9012 Salaried
Smith David E 567-89-0123 Hourly
Smith Loretta M 678-90-1234 Salaried
View Dependents Cancel
EI-1 Employee List

View Initiates display of data on EI-2 Review Employee Data
Dependents Initiates list displayed on EI-4 Dependent List
Cancel Returns to pull down menu


Process?


EQ Counting Rules Does the Rule Apply?
1. It has the primary intent of presenting Yes. The primary intent is to present
information to the user, and it: information to the user.
• references a data function to retrieve Yes. Data is retrieved from the Employee
data or control information and ILF.
• does not satisfy the criteria to be Yes. It performs no calculations, creates no

classified as an EO derived data and does not update any ILFs.
Conclusion The List of Employees is one EQ.

1. One FTR shall be counted for each The Employee ILF is read. An EQ cannot
unique data function that is accessed maintain an ILF by definition.


1. Count one DET for each unique user The following are repeated, they are
recognizable, non-repeated attribute that counted only once. Last Name, First Name,
crosses (enters and/or exits) the boundary MI, SSN, Salary Type.
The list is sorted using individual elements
function
of the name (i.e., Last Name, First Name,
MI). As a result, the individual elements of
the Name are user-recognizable.
3. Count only one DET per transactional Yes. The Review field/enter key initiates
function for the ability to initiate action(s) the action.
DETs:
• literals such as report titles, screen or Screen and column headers are not counted.
panel identifiers, column headings
• application generated stamps such as There are none.
• paging variables, page numbers and There are none.
37 to 54 of 211’
• navigation aids such as the ability to The scroll bar is not counted.
• attributes generated within the There are none.
the boundary
boundary

Functional Size of 1 Low EQ 3 FP

Example: Drop-Down List Box

User The user requires the ability to view a List of Bargaining Units added to the
Requirements Human Resources System by a user.
Example The following diagram shows the Hourly Employee Data window with the
Windows Bargaining Unit field.

Employee List
Employee Data
Mark J Manship
345-67-8901
Hourly Employee Data
Hourly Rate
Bargaining Unit Dependents
EI-3H Hourly Employee Data with Bargaining Unit

Dependents Presents list on EI-4 Dependent List

When the user selects the arrow, the following drop-down list box appears.

Employee List
Employee Data
Mark J Manship
345-67-8901
Hourly Rate

UPFCA
L841
CPLG
EI-3H Hourly Employee Data with Bargaining Unit


Process?

from other elementary processes? process that peforms this function.


• references a data function to retrieve Yes. Data is retrieved from the Bargaining
data or control information and Unit ILF. The Bargaining Unit ILF contains
numerous attributes about a Bargaining
Unit.
Conclusion The List of Bargaining Units is one EQ.

1. One FTR shall be counted for each The Bargaining Unit ILF is read. An EQ
unique data function that is accessed cannot maintain an ILF, by definition.


1. Count one DET for each unique user Bargaining Unit.
function
3. Count only one DET per transactional Yes. The down arrow activates the listbox.
DETs:
the boundary and
the boundary

Example: Field Level Help–First Occurrence

User During construction of the Human Resources System, a requirement for
Requirements online field level help was added. Help information is maintained by a
separate application. The Help information is referenced by the Human
Resources, Currency, Fixed Assets, and Benefits applications.
Example The following diagram shows the Employee Data window.

Windows

Employee List
Employee Data
Mark J Manship
345-67-8901
Hourly Rate
EI-3H Hourly Employee Data

When the user presses F1 while the cursor is on the hourly rate field, a box
displays the help text as shown in the following diagram.


Hourly Rate
The amount an employee is paid for each hour of
work completed.
This information must be provided for each hourly employee.
Valid Values: Any hourly amount is acceptable.

Default Values: This field does not have default values.
Hourly Rate
EI-3H Hourly Rate


Process?


1. It has the primary intent of presenting Yes. Field Help has the primary intent to
information to the user, and it: present information to the user.
• references a data function to retrieve Yes. Data is retrieved from the Help EIF.
data or control information and
Conclusion Field Level Help is one EQ.


1. One FTR shall be counted for each The Help EIF is read. An EQ cannot

1. Count one DET for each unique user Window ID, Field ID, Help Message,
recognizable, non-repeated attribute that Default Value, Valid Values.
function
3. Count only one DET per transactional Yes. The F1 key.
DETs:
• literals Literals such as “Valid Values” are not
counted.
the boundary and
the boundary

Example: Field Level Help–Second Occurrence

Requirements online field level help was added. The online help is for the add, delete, and
change processes for the Human Resources information. Help information is
maintained by a separate application. The Help information is referenced by
the Human Resources, Currency, Fixed Assets, and Benefits applications.
Example The following diagram shows the Employee Data window.

Windows

Employee List
Employee Data
Mark J Manship
345-67-8901
Hourly Rate

The user places the cursor on the field for which help is desired, and presses
F1 to view help about that field.

Process?

Is the Transactional Function unique No. This function performs the same
from other elementary processes? function as that depicted in the prior
example. The DETs, FTRs and
processing logic for this function are
the same as the prior example. It is
not counted again.
Conclusion The Second Occurrence of Field Level Help is not a unique elementary
process and is not counted as an EQ.

Example: Implied Inquiry

User The user requires the ability to view assignment information when editing
Requirements job assignment information. Although it is not explicitly stated, it is implied
that Job Assignment Information must be retrieved before it can be changed.
Example The following diagram shows the Job Assignment Edit window with only the
Windows employee name and job number.

Job Assignment Edit
Mark J Manship
345-67-8901
Main Plant UFPCA
Job Number RD15379305 May Issue - Print Covers
Date OK
03/27/93
Cancel
Salary 17.28
Restore
Performance Rating Satisfactory Delete
AE-5
OK Commits changes, returns to AE-1
Cancel Ignores changes, returns to AE-1
Delete Asks for confirmation, then deletes job assignment

When the user enters employee name and job number, the job information
appears as shown in the following diagram.

Job Assignment Edit
Mark J Manship
345-67-8901
Main Plant UFPCA
Job Number RD15379305 May Issue - Print Covers
Date OK
03/27/93
Cancel
Salary 17.28
Restore
Performance Rating Satisfactory Delete
AE-5
OK Commits changes, returns to AE-1
Cancel Ignores changes, returns to AE-1
Delete Asks for confirmation, then deletes job assignment

Process?
Is the Transactional Function unique Yes. We have not counted any other
from other elementary processes? elementary process that performs
this function. If a direct inquiry also
exists, it would be considered a
duplicate and would not be counted
again.


1. It has the primary intent of presenting Yes. Job Assignment Implied Inquiry has
information to the user, and it: the primary intent to present information to
the user.
• references a data function to retrieve Yes. Data is retrieved from the Job
data or control information and Assignment, Employee, and Job ILFs.

Conclusion Job Assignment Implied Inquiry is one EQ.

1. One FTR shall be counted for each The Job Assignment, Employee, and Job
unique data function that is accessed ILFs is read. An EQ cannot maintain an ILF
(read from and/or written to) by the by definition.


1. Count one DET for each unique user Name, SSN, Location, Bargaining Unit, Job
recognizable, non-repeated attribute that Number, Job Name, Effective Date, Salary,
crosses (enters and/or exits) the boundary and Performance Rating.
function
3. Count only one DET per transactional Yes. The command key.
DETs:
• literals Literals such as the screen title are not
counted.
the boundary and
the boundary
Functional Size of 1 Average EQ 4 FP
Conclusion The Job Assignment Implied Inquiry is a unique elementary process and is
counted as an EQ. If a direct inquiry also exists, it would be considered a
duplicate and would not be counted again.

Example: EQ Triggered without Data Entering the

Boundary
User The user requires that the application print the Monthly Membership Report
Requirements automatically every month.
Monthly Membership Report

Name City Country
Angel, A. Milwaukee USA

Boxer, B. London UK
Print Monthly Nair, J. Chennai India
Membership Report Alfonzo, F. Rome Italy
Batista, M. Rio De Janeiro Brazil
Man Bae, C. Seoul Korea
Membership ILF
Member ID
Name
City
Country

Process?



1. It has the primary intent of presenting Yes. The Monthly Membership Report has
information to the user, and it: the primary intent to present information ot
the user.
• references a data function to retrieve Yes. Data is retrieved from the Membership

Conclusion The Monthly Membership Report is one EQ. In this example, the transaction
is triggered by a time event within the boundary.

1. One FTR shall be counted for each The Membership ILF is read. An EQ cannot
unique data function that is accessed maintain an ILF, by definition.


1. Count one DET for each unique user Name, City, Country.
function
3. Count only one DET per transactional There are none. The function is performed
function for the ability to initiate action(s) automatically every month.
DETs:
• literals Literals such as “Name” are not counted.
the boundary and
the boundary

Example: Data Sent to Another Application

User At the end of each day, send a Daily Check File to Application B listing the
Requirements check numbers, the amount and date of each check printed for the day.
Application A Application B
Generate Daily Daily Check File

Check File
Check Number
Check Amount
Check Date
Check ILF
Check Number
Check Amount
...

Process?

from other elementary processes? process that performs this function.


1. It has the primary intent of presenting Yes. The Daily Check file has the primary
information to the user, and it: intent to present information. In this case,
the user is Application B.
• references a data function to retrieve Yes. Data is retrieved from the Check ILF.
data or control information and
Conclusion The Daily Check File is one EQ.

1. One FTR shall be counted for each The Check ILF is read. An EQ cannot
unique data function that is accessed maintain an ILF, by definition.


1. Count one DET for each unique user Check Number, Check Amount, Check
recognizable, non-repeated attribute that Date.
function
3. Count only one DET per transactional There are none. The function is performed
function for the ability to initiate action(s) automatically every month.
DETs:
the boundary and
the boundary

Example: Additional Help Functionality

Requirements additional help functionality was added. Help information is maintained by
a separate application. The Help information is referenced by the Human
Resources, Currency, Fixed Assets, and Benefits applications.
Counting The following diagram shows the Employee Data window.

Process

Employee List
Employee Data
Mark J Manship
345-67-8901
Hourly Rate

When the user selects the Help function at the top of any Window, three
choices become available: Window, Search and About.

Does the Transactional Function meet Yes, Window, Search and About
the requirements of an Elementary appear to perform three independent
Process? functions.

from other elementary processes? performs these functions. These
functions are counted only once
within an application.

1. It has the primary intent of presenting Yes. Window, Search and About all have
information to the user, and it: the primary intent to present information to
the user.
• references a data function to retrieve Window Data is retrieved from the Help
data or control information and EIF based upon the current Window.
Search enables the user to enter a topic and
retrieve Topic Data from the Help EIF.
About is retrieving hard-coded static data
not maintained in the Help EIF. Therefore it
does not meet the definition of an EQ.
• does not satisfy the criteria to be Yes. They perform no calculations, create
classified as an EO no derived data and do not update any ILFs.
Conclusion Window Help is one EQ and the Search capability is one EQ. About Help is
not counted because it is not maintained through an elementary process.
It is important to ensure that you do not count Static Help. Popular
environments, especially web applications, frequently contain static help.
It is also important to ensure that the boundaries are correctly assessed. Help
functionality is often provided by an external application, such as RoboHelp,
which provides all of the help functionality (i.e., maintenance, storage and
display of help). In this instance, no functionality is credited to the application
about which the help pertains.
Window Help and Search Help are each analyzed separately below.

Step 4 Count File Types Referenced (FTRs) for Window Help

Step 5 Count Data Element Types (DETs) for Window Help

1. Count one DET for each unique user Window ID, Window Description (text
recognizable, non-repeated attribute that only).
function
3. Count only one DET per transactional Yes. Selection from the Help Menu.
DETs:
• literals Literals such as screen labels are not
counted.
the boundary and
the boundary
Step 6 Determine Functional Complexity for Window Help

Step 7 Determine Functional Size for Window Help

Step 4 Count File Types Referenced (FTRs) for Search Capability

Step 5 Count Data Element Types (DETs) for Search Capability

1. Count one DET for each unique user Application ID, Topic Entered, Help
recognizable, non-repeated attribute that Message(s) Returned.
function
3. Count only one DET per transactional Yes. Selection from the Help Menu.
DETs:
counted.
the boundary and
the boundary
Step 6 Determine Functional Complexity for Search Capability

Step 7 Determine Functional Size for Search Capability

Example: Security Logon

User The user wants a logon function to control window security. The
Requirements functionality is illustrated below.
The logon function requires the entry of the following fields:

• User Identifier
• User Password
When the user logs on, the Security file is read to validate the user identifier
and password as well as to determine the windows the user can access and
maintain.
Generate error messages and highlight incorrect fields if the fields do not
pass edits. Two (2) error messages and one (1) confirmation message are
included for the security logon transaction.
Security Logon The following illustration shows the window to logon to the system.
Screen

Security Logon
User ID
Password
The user presses enter after all information is entered. The User ID and
Password are validated and logically all user access is assigned.


Process?


• references a data function to retrieve Yes. Data is retrieved from the Security

Conclusion The Security Logon is one EQ.
Step 4 Count File Types Referenced (FTRs) for Search Capability

1. One FTR shall be counted for each The Security ILF is read. An EQ cannot


1. Count one DET for each unique user User ID, Password.
function
2. Count only one DET per transactional Error and Confirmation Messages.
3. Count only one DET per transactional Enter key.
DETs:
counted.
the boundary and
the boundary
Step 6 Determine Functional Complexity for Search Capability
Step 7 Determine Functional Size for Search Capability


Part 4 – Examples Index
Index to Part 4
A Examples
Alternate index example, 1-20 alternate index, 1-20
Application application menus, 2-129
menus counting example, 2-129 batch with multiple and duplicate EIs, 2-70
B control information, 2-63
Batch with multiple and duplicate EIs, 2-70 conversion information, 1-43
C converting data to a new format, 2-80
Control information data conversion, 1-58, 2-80
for reporting, 2-63 data flow diagram to count referenced to multiple
Conversion data model, 1-43 files, 2-76
Conversion information, 1-43 EI with multiple file types referenced, 2-76
Converting data to a new format with additional data field-level help, 1-50
elements, 2-80 hard copy report, 2-105
D Help application, 1-50
Data conversion, 1-58, 2-80 online add transaction, 2-67
Data conversion data model, 1-58 providing data to other applications, 1-48
Diagrams references to multiple files, 2-76
components in EI/EO/EQ Counting Examples, 2-3 referencing data from another application, 1-43, 2-
components in ILF/EIF Counting Examples, 1-5 83
conversion data model, 1-43 referencing data from other applications, 1-39
data conversion data model, 1-58 report output, 2-105
Employee Data for field help input side of inquiry, screen input, 2-67
2-143 summary descriptions of external inputs examples,
Job Assignments Data window, 2-76 2-62
Job Data input screen, 2-67 summary descriptions of external output examples,
menu for input side of inquiry, 2-129 2-104
online reporting screen, 2-108 transaction with formatted record types, 2-70
organization of EI/EO/EQ Counting Examples, 2-2 transaction with multiple types, 2-70
record layout transaction input file example, 1-60 window help, 1-50
E External inputs
EI with multiple file types referenced, 2-76 batch with multiple and duplicate EIs, 2-70
EI/EO/EQ Counting Examples, 2-2 control information, 2-63
Employee Data field help, 2-143 data conversion example, 2-80
January 2010 Function Point Counting Practices Manual i-1

Index Part 4 – Examples
EI with multiple file types referenced, 2-76 N

screen input example, 2-67 New format with additional data elements, 2-80
External inquiries O
application menus example, 2-129 Online add transaction via a screen, 2-67
External interface files Online reporting screen, 2-108
conversion information, 1-43 Organization. See Manual
data conversion example, 1-58 EI/EO/EQ Counting Examples, 2-2
data referenced in other applications, 1-39 P
field-level help, 1-50 Providing data to other applications, 1-48
Help application example, 1-50 R
providing data to other applications, 1-48 Record layout for input file transaction, 1-60
referencing data from another applicaiton, 2-83 Record types, 2-70
referencing data from another application, 1-43 Referenced to multiple files, 2-76
referencing data from other applications, 1-39 Referencing data from another application, 1-43, 2-
window help, 1-50 83
External outputs Referencing data from other applications, 1-39
report output example, 2-105 Report output example, 2-105
F Reports
Field-level help, 1-50 hard copy, 2-105
Formatted record types, 2-70 S
H Screen input, 2-67
Hard copy report, 2-105 Screens
Help application, 1-50 Employees by Assignment Duration, 2-108
Human Resources System window, 2-129 online reporting, 2-108
I Summary description of external input examples, 2-
Internal logical files 62
alternate index example, 1-20 Summary description of external outputs examples,
summary descriptions of examples, 1-8, 2-8 2-104
J Summary descriptions of ILF examples, 1-8, 2-8
Job Assignments Data window, 2-76 T
M Transaction with formatted record types, 2-70
Manual Transaction with multiple types, 2-70
organization of EI/EO/EQ Counting Examples, 2-2 W
organization of ILF/EIF Counting Examples, 1-4 Window help, 1-50
Multiple types, 2-70 Windows
field help, 2-143
i-2 Function Point Counting Practices Manual January 2010

0004 - 3 Part 4 (2009-09-01)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0004 - 3 Part 4 (2009-09-01)

Uploaded by

Copyright:

Available Formats

Part 4 – Examples

This page intentionally left blank.

Contents Part 4 includes the following sections:

January 2010 Function Point Counting Practices Manual 1-1

1-2 Function Point Counting Practices Manual January 2010

Data Function Counting Examples

January 2010 Function Point Counting Practices Manual 1-3

Organization of the Counting Examples

This section explains how the examples are presented.

Outline of the Organization

Diagram of the Organization

Count for Each Example

Each example includes the following components:

1-4 Function Point Counting Practices Manual January 2010

Basis for the Measurement

Counting Rules Table

For Each Identified ILF or EIF,

January 2010 Function Point Counting Practices Manual 1-5

1-6 Function Point Counting Practices Manual January 2010

Introduction This section uses a Human Resources (HR) application to illustrate

Contents This section includes the following examples:

January 2010 Function Point Counting Practices Manual 1-7

Summary Descriptions of ILF Counting Examples

The examples for ILFs are described in the following table.

Example Summary Description Page

1-8 Function Point Counting Practices Manual January 2010

Example: Audit Data for Inquiries and Reports

Attributive Entity Type

Optional One-to-Many Relationship

January 2010 Function Point Counting Practices Manual 1-9

User date, time, user id,

Change screen security info

1-10 Function Point Counting Practices Manual January 2010

Step 1 Identify Data Functions

January 2010 Function Point Counting Practices Manual 1-11

Step 2 Classify Data Functions

1. Classify as an ILF if the data is The Screen Security data function is

Based on the analysis, the Screen Security information is classified as an ILF.

Step 3 Count DETs

1-12 Function Point Counting Practices Manual January 2010

Step 4 Count RETs

January 2010 Function Point Counting Practices Manual 1-13

Step 5 Determine Functional Complexity

2 RETs and 8 DETs Complexity is Low

Step 6 Determine Functional Size

Functional Size of 1 Low ILF 7 FP

1-14 Function Point Counting Practices Manual January 2010

Example: Report Definition

− A unique report identifier

January 2010 Function Point Counting Practices Manual 1-15

Step 1 Identify Data Functions

1-16 Function Point Counting Practices Manual January 2010

Step 2 Classify Data Functions

1. Classify as an ILF if the data is The Report Definition data function is

Based on the analysis, the Report Definition information is classified as an

Step 3 Count DETs

January 2010 Function Point Counting Practices Manual 1-17

Data Function DET Counting Rules Does the Rule Apply?

Step 4 Count RETs

1-18 Function Point Counting Practices Manual January 2010

Step 5 Determine Functional Complexity

1 RETs and 4 DETs Complexity is Low