Applying the International Function Point Users Group Counting Rules: Frequently Asked Questions (FAQs)
- How to Identify the Scope and Boundary of a Count
- How to Count ILFs and EIFs
- Some Typical Errors in Identifying ILFs and EIFs
- How to Count EIs
- How to Count Transactions
- Some Typical Errors in Identifying EIs
- How to Count EQs
- Some Typical Errors in Identifying EQs
- How to Count EOs
- Some Typical Errors in Identifying EOs
- Source
How to Identify the Scope and Boundary of a Count
The counting scope is determined by the purpose of the count; it identifies all of the systems, applications, and subsets of an application that will be sized. The application boundary indicates the border between the application being measured and external applications or the user domain.
When performing a function point count, how do you determine the scope and application boundary when the system to be counted includes multiple applications?
The scope may include an entire project, but function points are counted separately by application. Development projects and enhancement projects often include more than a single application. In these cases, the multiple application boundaries would be identified within the counting scope, but they would be separately counted by application.
When performing a function point count, how do you determine the application boundary when the system to be counted includes several platforms?
In a function point count, the application should be counted from the perspective of the business solution versus the technical solution. The platforms are part of the physical environment, not part of the functional requirements. As an example, the application boundary of a client/server application consists of all components that collectively meet the business requirements, regardless of physical implementation or platform.
When performing a function point count, how do you determine the scope and application boundary when the system to be counted includes a vendor package? What should be counted when you purchase a package?
There are many potential counts relating to the purchase of a package. First, when you shop for a package, you have a group of requirements that can and should be sized; this is the functionality that you need. A potential vendor may already have an application count, but do you care about the functionality that you do not intend to use? Next, you should be interested in the enhancement project count to make necessary changes to the package and satisfy interfacing requirements. Finally, you need an application count to measure the functionality that will be used after the enhancement.