This paper expands on the information, particularly the notes, provided in the FSM at steps 5.9 and 5.10. These steps provide a record of the count that is auditable, defensible and traceable. The results of the count can then be used by the function point practitioners for subsequent enhancement counts and by measurement process owners and management for analysis, measurement and reporting. 

Documentation of the function point count includes the following basic count information:

• the purpose and type of count;
• the counting scope and boundary of the application;
• the date of the count;
• the version of the CPM used for the count
  • any variations from CPM standards
• the version of local counting standards, if applicable
  • any variations from local counting standards
• a list of all data and transactional functions including their type, complexity and number
  of function points assigned. Additionally, for project counts specify the impact of the
  function on the count (i.e., add, change, delete or conversion);
•  the result of the count;
• any assumptions made and issues resolved, especially, specific counting decisions
  made; e.g., approach taken for the counting of Multiple Media

Optionally, the documentation of the function point count can also include the following:

• dentification of the source documentation on which the count was based;
• identification, roles and qualifications of the participants;
• for each data function, the identity and/or number or range of DETs and RETs;
• for each transactional function, the identity and/or number or range of DETs and FTRs;
• a cross-reference of all data functions to transactional functions;
• a cross-reference of all data functions to the related abstractions (e.g., logical data
  entities, physical tables, requirement identifiers, etc.) in the source documentation;
• a cross-reference of all transactional functions to the related abstractions (e.g.,
  requirement identifiers, screen identifiers, report identifiers, etc.) in the source
  documentation
• any other related information such as estimating factors, development platforms,
  languages, etc. 

The level of documentation should be negotiated with management or the client, based on the related costs and benefits. A fully documented Function Point Count will facilitate traceability, usability and maintainability; however, management may be interested in only the final result, especially if it is an early stage estimate. Local counting guidelines should include specific documentation requirements.

The most common forms for recording the results of a count are function point analysis tools and Excel workbooks. These should have, at minimum, the capability of recording basic count information in the first list above.

Documentation of counts, assumptions and counting decisions provide for ease of subsequent counts as well as fostering consistency of counts within an organization. When the purpose of the count is to estimate the development effort, the assumptions can provide the basis for management of scope during development as well as evaluating the level of confidence in the estimates. Where the purpose of the count is to measure the functionality delivered, the assumptions can help categorize the benchmark data and support any audit requirements.

• Typically, high level sizing estimates early in the life cycle provide an order of magnitude or ball park estimate for early decision making, and the assumptions provide initial information as to the scope and content of the project. It is important to document purpose, scope and assumptions.
• When management or the client requires a firm cost estimate, a more detailed identification of data and transactional functions and counting assumptions is required. All documentation items in the basic count information list are important in order to develop and substantiate the estimate. That information will provide key information in the management of project scope during the construction phase. 
• When measuring the functionality delivered at the completion of a development or enhancement project, the count documentation must contain enough detail to meet the audit requirements specified by the software development process or the client. The documentation also provides the basis or baseline for subsequent counts and should capture any unique counting decisions as well as the detailed identification of data and transactional functions.

Appropriately documenting and reporting the results of a function point count ensure the count is understood by all parties involved. It also adds value to the software delivery process of the client or organization to support improvement processes, consistency and audits.

Login as a member to access this resource.

Non-Members: $20.00, purchase the publication here: https://ifpug.memberclicks.net/fpaelementary