Early Function Point Analysis
Nesma recognizes three function point analysis methods:
- Detailed function point analysis
- Estimated function point analysis
- Indicative function point analysis
All these three methods are a self-contained Functional Sizing Measurement (FSM) method on their own. The high level FPA method and the indicative FPA method do not require detailed user requirements, while the functional size determined using these methods is very close to the functional size determined using the detailed FPA method. That’s why these two methods are very suited to be applied early in de software development life cycle or in case the functional size needs to be determined fast.
The information on this page is also available as a free document
in Dutch, English, Portuguese and Japanese.
Detailed FPA
This is the usual function point analysis method and is performed as follows:
- Determine all functions of all function types (ILF, EIF, EI, EO, EQ)
- Rate the complexity of every function (Low, Average, High)
- Calculate the total unadjusted function point count
High-level FPA (a.k.a. estimated FPA)
The high-level function point analysis method is performed as follows:
- Determine all functions of all function types (ILF, EIF, EI, EO, EQ)
- Rate the complexity of every data function (ILF, EIF) as Low and of every transactional function (EI, EO, EQ) as Average
- calculate the total unadjusted function point count
So, the only difference of this approximation with the detailed function point analysis method is that the complexity is not determined per individual function, but by default.
Indicative FPA
The indicative function point analysis method is performed as follows:
- Determine the number of data functions (ILFs and EIFs);
- Calculate the total unadjusted function point count of the application as follows: indicative size (fp) = 35 x number of ILFs + 15 x number of EIFs
So this approximation is based solely on the logical files (ILFs and EIFs).
The indicative function point analysis is based on the assumption that there will be about three EIs (to add, change, and delete information in the ILF), two EOs, and one EQ on average for every ILF, and about one EO and one EQ for every EIF.
Example of indicative, high-level and detailed FPA
This section illustrates the three FPA methods by a small case study: an application that maintains Customer data and Product data, and references Supplier data. The more accurate functional size one wants, the more detailed user requirements one needs. That’s why this case study presents the three methods of function point analysis in the order of increasing accuracy:
- Indicative function point analysis
- High-level (estimated) function point analysis
- (Detailed) function point analysis
Indicative FPA
For an indicative function point analysis just information about the data functions is needed.
User requirements:
- user wants to maintain Customer data and Product data, and to reference Supplier data.
This (rough) specification is enough for an indicative function point count:
- ILF: Customer and Product
- EIF: Supplier
| Data function |
Function type |
Function points |
|---|---|---|
| Customer |
ILF |
35 |
| Product |
ILF |
35 |
| Supplier |
EIF |
15 |
| Indicative functional size |
85 fp |
High-level FPA
To perform a high-level function point analysis we also need information about the transactional functions, so more detailed user requirements are necessary: User requirements:
- User wants to add, change, delete Customer data, wants to inquire on Customer, and also requires four different reports on Customer with calculated data
- User wants to add, change, delete Product data, wants to inquire on Product, and also requires a report on Product with calculated data
- User wants to inquire on Supplier using supplier number, and also requires a report on Supplier with totaling results
This more detailed specification of the user requirements shows the actual amount of transactional functions, and therefore enables an estimated function point count.
| Data or transactional function |
Function type |
Complexity (by default) |
Function points (unadjusted) |
|---|---|---|---|
| Customer |
ILF |
Low |
7 |
| Product |
ILF |
Low |
7 |
| Supplier |
EIF |
Low |
5 |
| Add Customer |
EI |
Average |
4 |
| Change Customer |
EI |
Average |
4 |
| Delete Customer |
EI |
Average |
4 |
| Inquire on Customer |
EQ |
Average |
4 |
| Report 1 on Customer |
EO |
Average |
5 |
| Report 2 on Customer |
EO |
Average |
5 |
| Report 3 on Customer |
EO |
Average |
5 |
| Report 4 on Customer |
EO |
Average |
5 |
| Add Product |
EI |
Average |
4 |
| Change Product |
EI |
Average |
4 |
| Delete Product |
EI |
Average |
4 |
| Inquire on Product |
EQ |
Average |
4 |
| Report on Product |
EO |
Average |
5 |
| Inquire on Supplier |
EQ |
Average |
4 |
| Report on Supplier |
EO |
Average |
5 |
| Estimated functional size |
85 fp |
Detailed FPA
To carry out a detailed function point count, one does not only need the number of functions of each function type (EI, EO, EQ, ILF, EIF), but one also needs to determine the functional complexity of each individual function (Low, Average, High). In FPA, the functional complexity of a (data or transactional) function is determined, based on the number of DETs, RETs and File Types Referenced that are relevant to this function. That’s why the user requirements (as they were stated above in this example when we discussed the estimated function point count) need to be analyzed in more detail: which data elements (DETs) and logical files (File Types Referenced) are used by a transactional function (EI, EO, EQ), and which logical data groups (RETs) and data elements (DETs) a data function (ILF, EIF) consists of. This detailed analysis of the user requirements could result in the following function point count:
| Data or transactional function |
Function type |
Complexity |
Function points (unadjusted) |
|---|---|---|---|
| Customer |
ILF |
Average |
10 |
| Product |
ILF |
Low |
7 |
| Supplier |
EIF |
Low |
5 |
| Add Customer |
EI |
High |
6 |
| Change Customer |
EI |
Average |
4 |
| Delete Customer |
EI |
Low |
3 |
| Inquire on Customer |
EQ |
Low |
3 |
| Report 1 on Customer |
EO |
Low |
4 |
| Report 2 on Customer |
EO |
Average |
5 |
| Report 3 on Customer |
EO |
Low |
4 |
| Report 4 on Customer |
EO |
High |
7 |
| Add Product |
EI |
Average |
4 |
| Change Product |
EI |
Low |
3 |
| Delete Product |
EI |
Low |
3 |
| Inquire on Product |
EQ |
Average |
4 |
| Report on Product |
EO |
Average |
5 |
| Inquire on Supplier |
EQ |
Low |
3 |
| Report on Supplier |
EO |
Average |
5 |
|
Functional size |
85 fp |
Conclusion
In this particular case study all three methods result in the same functional size of 85 function points. Usually the results are not exactly the same, but still are pretty close to each other. Below the results of research on the accuracy of the estimated and indicative function point analysis methods are shown.
Results of research based on a 100+ projects data base
Using a database of about 100+ developed and implemented applications Nesma did research on the accuracy of the estimated and indicative FPA approximation methods. The implemented applications were simultaneously measured using all three FPA methods. The results are presented in two graphs:
1. the size measured via the high-level function point analysis method versus the size measured via the detailed function point analysis method:
2. the size measured via the indicative function point analysis versus the size measured via the detailed function point analysis method:
There is a good correlation (straight line) in both cases. In the graph of the indicative function point analysis, however, there are considerable deviations (up to about 50%) in some cases. That is why one should be careful using the indicative function point analysis. The strength of this indicative FPA method is that one easily gets a rough estimate of the size of an application in only a very short time.
In an application with more (or less) than a normal amount of inputs or outputs, one might need to change the multipliers of 35 and 15, but the philosophy behind the approach can generally be used.
When to use which method for function point counting
A detailed function point analysis is more accurate than an estimated or an indicative analysis, but it also costs more time and needs more detailed specifications. It’s up to the project manager and the phase in the system life cycle as to which function point analysis method is used.
The results of the high-level function point analysis and the detailed function point analysis are very close. There is no statistically significant difference in the outcomes of both FPA methods. That’s why many organizations have chosen to use the high-level FPA method by default, instead of the detailed FPA method.
In many applications an indicative function point analysis gives a surprisingly good estimate of the size of the application. It is often relatively easy to carry out an indicative function point analysis, because a data model is available or can be made with little effort. Be careful in using this method, because it provides just a rough indication of the size, and deviations are possible.