Function Point Analysis (FPA)

ISTQB Glossary  definition 

Method aiming to measure the size of the functionality of an information system. The measurement is   independent of the technology. This measurement may be used as a basis for the measurement of productivity, the estimation of the needed resources, and project control.

In Simple English,

Functional Point Analysis is a common method used to come up with estimate on the size of a functionality. 

At the most basic level it is the simple process of breaking down the functional requirement into smaller pieces and then assigning a rating on each of them so that you can add them together to get a total which indicates how big or small the functionality is.

Imagine you are asked to come up with the weight of a satellite that is already in the orbit. you wouldn't be able to weigh it now. Right.? so one way to do this would be to ask how much each of the component that went in to making the satellite weighs and then to add all those values together to come up with the weight of the satellite. This approach is similar to what you do in a Functional Point analysis.
     
you take a requirement and break it down to individual parts and then measure each of them.

Field Notes 

1. Though this is the most used way of estimating, often people seem to be in a hurry to do a formal through Functional point analysis and end up with not so great results.
2. This is just a method to do analysis and by it self does not guarantee correct sizing.
3. This method relies on the discipline and experience of the  person doing the analysis to work successfully.
4. This method also assumes that the person doing the analysis has at the very least some knowledge about what is being analysed. Domain expertise is the technical jargon for this.
5. Excel is sufficient tool to this analysis. often it is the tool of choice.
6. It is not essential to use this tool all the time, based on past experience with similar kind of work and the perceived size of the work at hand, someone has to decide if FPA is the correct choice.
7. The unit used to measure the functionality could be different at different situations. Sometimes the unit is just and label of simple, medium, complex, sometimes it is the number of hours a developer might need to develop it, some other times it is a a teams estimate of time needed to deliver the functionality.
8. Another often held misconception is that one functional point analysis will answer all sorts of questions. This is not true. A functional point analysis is always aimed at answering one main question, its either "how complex is the functionality? or How much time will be needed to develop this? or how many people are needed?.\
9. don't try to answer all questions with just one Functional point analysis. However, once a functional point analysis is done to answer a single question (this is called to measure a single dimension in technical jargon), you can use that value to derive answers to other questions.
10. One often not understood by many outcome of a functional point analysis is a list of questions about the functionality also known as clarification log or query log in the technical jargon.
11. One of the most over looked items in functional point analysis is the list of assumptions. For some reason everyone just assumes that all the other people reading the analysis would understand the assumptions. this is somehow the worst problem because most often management and project managers would not have any clue about the intricate details of the functionality and  would disagree with the findings of the functional point analysis. It also serves the purpose of clarifying that the assumptions made are agreed by all the stake holders.
12. Another most popular misconception about this analysis is that this is a stand alone activity with just one person doing it once. This is not true. Functional point analysis should be a iterative and collaborative process. That is to say that the analysis should be done at least a few time to refine the results closer to reality and to do that participation of more than one person would be needed. for example, a business user would be needed to clarify some specifics about the requirements.
13. Note of Caution: :)  while this is a logical way of sizing please do not get too invested in the outcomes. do not assume that the result of this will be used to set the project timelines or budget. most often it is used along with other tools to ensure that the time and money allocated to the projects are enough. Most often the results of this analysis will also be ignored for various business and personal reasons. This should not stop you from doing a through functional point analysis as you as the QA person in the project would need some basis to defend your timelines. same holds good for any person in charge of  delivery of the functionality.

For Example:
Take for example making coffee.
Say that you are asked how long it will take for you to make 4 cups of coffee. you would simply say may be 15 minutes without much hesitation. you would not need an functional point estimate here. :)

Instead say you were asked how long will it take for you to make 400 cups of coffee, now you have a entirely different take at hand though it is still about just making coffee. you would need an Functional point analysis here.

you would have to break the desired functionality into smaller pieces that make sense and then split those pieces further down to make it easier.

coffee for 400 people:
1. Plan phase
2. Prepare phase
3. deliver Phase
4. clean up phase. ( I bet you did not think about this earlier)

1. Plan phase

• Identify ingredients.
• Get the ingredients.
• Get tools needed.
• Get manpower needed.

now this gives raise to other questions, like..,
1. what kind of coffee are we serving? hot or cold?
2. do we have to personalize the coffee for each of 400 people? or make a few common variants?
3. will all of them need to be served at once or will people come in batches?

now these are questions you add to a query log.