How are RETs identified within a file?

IFPUG 4.1 Definition

Despite the IFPUG definition, there exists some confusion among FP Analysts as to what a RET is, and how many DETs constitute a sub-group.

Two types of data groups are possible RET candidates:

1. File Sub-Types - i.e. Optional/ Mandatory sub groups of data. For example, an Employee can either be a Permanent Employee or a Contract Employee but not both. The Employee File has two sub-types and potentially two RETs.
2. Repeating Groups - where a group of data can be repeated multiple times within the one logical file. For example, Order Header and Order Line Item information. One Order Header can be linked to multiple Order Line Items. The Order File potentially has two RETs.

In both of the above examples the word "potentially" has been used intentionally. While in both cases we have RET candidates, the existence of a "subgroup" of information must be demonstrated. IFPUG provides no guidance on how many DETs constitute a subgroup.

The IFPUG RET definition implies that one optional or repeating DET is not a subgroup. For example, the marital status of an Employee may be 'Married' or 'Single'. If 'Married' a Spouse name is recorded. Spouse name is an optional attribute but the Employee file does not have two RETs.

Typically there are three groups of DETs that occur in optional/ repeating situations. These are:

1. Primary Key (the unique identifier for the RET. For example, Employee_Id)
2. Foreign Key/s (linking the repeating group to its parent/header record. For example Job_Id)
3. DETs unique to the RET (For example, Date_Assigned_Job, Job_Role)

If in doubt, FP Analysts should not count a sub-group of information as a RET.