Func­tion Point Analy­sis (FPA) is a tech­ni­que of func­ti­o­na­lity mea­su­re­ment pro­vi­ded by a soft­ware on its users point of view. Func­tion Point (FP) is its mea­su­ring unit, that has as a goal making the mea­su­re­ment tech­no­lo­gi­cally inde­pen­dent. This is, FPA tries to mea­sure what the soft­ware does and not how it was deve­lo­ped.
This being said, the mea­su­ring pro­cess (also cal­led func­tion point coun­ting) is based in a stan­dard eva­lu­a­tion of the user’s func­ti­o­nal requi­re­ments. This stan­dard pro­ce­dure is des­cri­bed by IFPUG in the Coun­ting Prac­tice Manual.
The main deve­lo­ping pro­jects esti­mate tech­ni­ques assume that the soft­ware size is an impor­tant dri­ver for the esti­ma­tion of its deve­lop­ment effort. Thus, knowing its size is one of the first steps of the effort, term and cost esti­mate pro­cess.
At this point it is impor­tant to know that func­tion points do not mea­sure effort, pro­duc­ti­vity nor cost direc­tly. It is exclu­si­vely a soft­ware func­ti­o­nal size unit. This size, among with other vari­a­bles, is what could be used to derive pro­duc­ti­vity, esti­mate effort and cost of the soft­ware project.

The soft­ware requi­re­ments are fun­da­men­tal to the Func­tion Point Analy­sis (FPA), since the mea­su­re­ment pro­cess is based exclu­si­vely on them. The basic inputs of the mea­su­re­ment are the sys­tem requi­re­ments. It should be noted that the Func­tion Point Analy­sis (FPA) mea­su­res only a part of the user requi­re­ments for the sys­tem: the func­ti­o­nal requi­re­ments. Non-functional requi­re­ments are not mea­su­red by the Func­tion Point Analy­sis (FPA). Howe­ver in a model of cost esti­ma­tion based on FP (cost = size x $ / PF), both types of requi­re­ments (func­ti­o­nal and non­func­ti­o­nal) are con­si­de­red: the first will affect the func­ti­o­nal size and the second will affect the unit cost ($ / PF).

Due to this impor­tance of the requi­re­ments for the Func­tion Point Analy­sis (FPA), how bet­ter the qua­lity requi­re­ments is, easier and fas­ter beco­mes the mea­su­re­ment pro­cess, and more accu­rate the result will be. Bad qua­lity requi­re­ments nega­ti­vely affect the entire soft­ware pro­ject, inclu­ding the mea­su­re­ment acti­vity. But a bene­fi­cial side effect of the mea­su­re­ment pro­cess is cle­arly demons­tra­ted fai­lu­res in the requi­re­ments. soo­ner these faults in the pro­ject are iden­ti­fied, lower is the cost to cor­rect them, and gre­a­ter is the chance of the pro­ject success.

There is not a spe­ci­fic docu­ment that is man­da­tory for mea­su­ring a soft­ware (or count func­tion points). Any docu­ment on which can be extrac­ted infor­ma­tion from the user requi­re­ments can be used on a func­tion points count. Whether they are use cases, manu­als, pro­toty­pes, vision docu­ments, data model, class model, etc.. This is con­sis­tent with the very pur­pose of the Func­tion Point Analy­sis (FPA) to be a tech­ni­que that is inde­pen­dent of the soft­ware imple­men­ta­tion. You can imple­ment a soft­ware by using dif­fe­rent methods and tools for analy­sis, mode­ling and cons­truc­tion for vari­ous com­pu­ting plat­forms, but none of this affects the mea­su­re­ment of the same in func­tion points.

It is clear that cer­tain types of docu­ments can pro­vide the neces­sary infor­ma­tion for a func­tion points count more easily. Other docu­ments may con­tain only part of the infor­ma­tion requi­red for the coun­ting of FPs, requi­ring the joint analy­sis of all docu­ments to make the mea­su­re­ment. As well as other docu­ments, because they have a more tech­ni­cal pro­cess for soft­ware deve­lop­ment, may be more dif­fi­cult to extract the user requi­re­ments. The best docu­ment to be used to count FP’s is one that con­tains the expli­cit user requi­re­ments in its busi­ness lan­guage, not on an IT language.

Each orga­ni­za­tion has its spe­ci­fic deve­lop­ment pro­cess, pro­du­cing a num­ber of docu­ments (or arti­facts) dis­tincts in a cer­tain sta­ges of the pro­cess. The­re­fore, the time at which the mea­su­re­ment is done also deter­mi­nes which docu­ments will be avai­la­ble to do the work of measurement(or esti­mate) of the pro­ject func­ti­o­nal size.

Most of the errors found in a sys­tem of func­tion points count is cau­sed by four factors:

- Lack of the tech­ni­que : there is still a large num­ber of staff that are assig­ned to count func­tion points of a sys­tem without the neces­sary kno­wledge of the coun­ting pro­cess. Perhaps this occurs because there is wides­pread belief that the Func­tion Point Analy­sis (FPA) is very sim­ple. And indeed it is, but this does not mean it is not neces­sary pro­fes­si­o­nal trai­ning or a more dedi­ca­ted study of the tech­ni­que. With only a super­fi­cial kno­wledge of Func­tion Point Analy­sis (FPA) it’s quite likely that the analyst makes mis­ta­kes. On this aspect, the IFPUG esta­blished its pro­fes­si­o­nal cer­ti­fi­ca­tion pro­gram CFPS, which aims to ensure that the cer­ti­fied pro­fes­si­o­nal knows all the defi­ni­ti­ons and rules of its Coun­ting Prac­ti­ces Manual in its latest version.

- Allow the count be “con­ta­mi­na­ted” by the imple­men­ta­tion: Func­tion Point Analy­sis (FPA) is a tech­ni­que for mea­su­ring the func­ti­o­nal requi­re­ments of a soft­ware. In other words, mea­su­res what the user requests and recei­ves from the soft­ware regar­dless of how it was imple­men­ted. The­re­fore, the result of a func­tion points count must be the same, wha­te­ver the solu­tion of imple­men­ta­tion (pro­cess, archi­tec­ture, tools, com­pu­ting envi­ron­ment, etc.) taken by the deve­lo­per. Count func­tion points of a sys­tem is an exer­cise for abs­trac­tion of the user’s busi­ness pro­blem that the soft­ware must attend . But this is not always an easy task and even expe­ri­en­ced func­tion points analysts can shift the focus from the count to the deve­lo­per imple­men­ta­tion solu­tion. Often the analyst is indu­ced to this way for lack of pro­per documentation.

- Lack of busi­ness kno­wledge: there is no use being a spe­ci­a­list in Func­tion Point Analy­sis (FPA) and do not know the user busi­ness. To the func­tion points count be done cor­rec­tly, in other words, from the user’s point of view, it is neces­sary that the func­tion point analyst seeks to unders­tand the busi­ness first and only then do the func­tion points coun­ting. Often there is no time avai­la­ble to the point analyst seeks this kno­wledge. In this case he will act in part­nership with a busi­ness analyst or a user to be able to do the func­tion points count .

- Qua­lity of the requi­re­ments avai­la­ble: much is said in soft­ware engi­ne­e­ring on the impor­tance of the gathe­ring requi­re­ments and the impact that it has on the whole pro­ject when this task is not well exe­cu­ted. To the func­tion points count it’s not dif­fe­rent. If the docu­ments from where the func­tion point analyst extracts the user requi­re­ments to con­duct the count are ambi­guous, incom­plete or poorly writ­ten, almost cer­tainly that the result of the count will be affected.

This rela­tion of fac­tors is not pre­sen­ted in any par­ti­cu­lar order, but it’s fairly repre­sen­ta­tive of the main fac­tors that cause func­tion points count being in an incor­rect way.