For more than 50 years, Auerbach Publications has been printing cutting-edge books on all topics IT.

Read archived articles or become a new subscriber to IT Today, a free newsletter.

This free newsetter offers strategies and insight to managers and hackers alike. Become a new subscriber today.



Interested in submitting an article? Want to comment about an article?

Contact John Wyzalek editor of IT Performance Improvement.


A Guide to Sizing and Estimating Projects

David Garmus

Stakeholders involved with the development of software are frequently challenged to provide early and accurate software project estimates. It speaks poorly of the software community that accurate estimation practices, early in the lifecycle, have not been adequately resolved and standardized.

Three significant issues play a role in the estimating challenge:

  • The need to identify and express, as early as possible in the project, the application software functional requirements requested by the user.
  • The need to identify and express the application software non-functional requirements taking into account all of the technical and quality issues for the project.
  • The need to understand the software development team's capability to deliver the required software solution within a specified environment taking into account all of the risk factors relating to the environment and people's skills and motivation. Once these issues are resolved, the effort required to deliver the product can be more accurately predicted.

The software requirement can be defined as the scope of the required software functionality impacted (to be built or customized) by the project activities as well as the technical and quality issues. The software requirement must be accurately identified by users or those individuals who have requested the software to be built, and then assessed for its size and complexity. To complicate the situation, experience tells us that at the point in time when we need an initial estimate (early in the system's life cycle), we typically do not have all of the necessary information available. Therefore, we must follow a relatively rigorous process that enables a further determination of the requirements.

Functional size can be measured using the International Function Point Users Group (IFPUG) functional size measurement method discussed in the IFPUG Counting Practices Manual [1], based on the functional user requirements. Function Point Analysis measures the functionality requested and received by the user independent of the technical and quality details involved. Function Points provide a more precise measurement of software size and are designed to remove the ambiguity from consideration of the software being examined. Instead of an abstract notion of size, we derive a more accurate estimate of a project's size. Function Point Analysis conforms to the ISO/IEC 14143-1:2007 standard for functional measurement.

IFPUG has recently developed a sizing measure that can be used to size nonfunctional requirements for the development and delivery of a software product known as Software Non-functional Assessment Process (SNAP), which is presented as a separate chapter in this book. The main objective of IFPUG's Framework for Non-Functional Sizing (2008) project was to provide a non-functional framework that could be used to establish a link between non-functional size and the effort to provide the non-functional requirements. The non-functional assessment provides information that can identify requirements that impact quality and productivity by quantifying the size of non-functional requirements of the software that the user requests and receives. The resulting framework has been released by IFPUG as the SNAP Assessment Practices Manual [2].

Having both Function Point data and non-functional requirements provides a more complete and accurate picture of software development. However, the SNAP scope will always be limited to the "product" non-functional requirements assessment, rather than including "external" requirements related to the organization delivering the project/product. Organizational, personnel, and support requirements for the project certainly have an impact on the overall project effort estimation, but they are not included in the SNAP point calculation.

Risk factors relating to the environment and people's skills and motivation influence the organization's capability to deliver. The identification and assessment of these project risks should also be completed at the beginning of each project when a project manager is better positioned to develop a plan that works. The resulting plan should focus on the project team's capability and capacity to deliver requested functionality in accordance with customer requirements. In the world of continually evolving technologies, project managers face ever-increasing challenges in managing software development projects. Is your organization building software with new technologies in new environments? Client/Server platforms, multitiered architectures, object-oriented design, web-based users, and e-business customers are the norm today. If you are facing the technology revolution, your project managers may need new skills to succeed in today's complex software development environments. A project manager should not commence a project without evaluating the team's capabilities, before committing to an estimate of time and effort. An effective project manager focuses on the successful delivery of quality software within time and budget constraints. Once the project manager understands the delivery capability of the team's current resources, he or she is better positioned to quantify the size (scope) of each project and develop project plans with remarkable precision, plans that work!

It is recommended that project managers follow an ISO standard for sizing software that has the flexibility to modify estimates as the project progresses. Experience tells us that although a project manager needs an estimate early in the development process, the estimate is rarely based on complete information. Therefore, the project manager should follow a rigorous estimating process that permits further clarification of the requirements as the project proceeds through the development cycle. The methodology should enable an estimate to be quickly revised and subsequent changes to be captured while maintaining the basis of the original estimate.

Effective estimation requires that a historical baseline of performance including size, resources, and schedule be maintained. An organization should develop profiles that reflect rates of delivery for projects of a given functional size, nonfunctional assessment, and risk. In turn, this information can be used to predict and explore "what-if" scenarios for future projects.

An effective estimating model, as shown in Figure 1, considers three elements: size, non-functional assessment, and risk to determine an estimate.

Figure 1. Estimation Model

Project Size

By far, the project-sizing technique that delivers the greatest accuracy and flexibility is the IFPUG Function Point methodology. Based on logical user-defined requirements, IFPUG Function Points permit the early sizing of the software requirement. In addition, the IFPUG Function Point methodology presents the opportunity to size a user requirement regardless of the level of detail available. An accurate Function Point size can be determined from the detailed information included in a thorough user requirements document or a functional specification. An adequate Function Point size can even be derived from the limited information available in an early proposal.

The IFPUG Function Point methodology is dependent upon identification of five elements: inputs, outputs, inquiries, internal stores of data, and external references to data. Within the IFPUG methodology, these are known as external inputs, external outputs, external inquiries, internal logical files, and external interface files. During the early stages of development, these elements are exposed at a functional level (e.g., an output report will be required although the detailed characteristics of that report might not be known). The Function Point counting methodology identifies these five elements. As more information becomes available regarding the characteristics of these elements (that is, data attributes, file types referenced, and so on), the more detailed the Function Point count becomes. During the early phases of a count, it may be necessary to assume levels of complexity within the system (e.g., is the report going to be simple or complex). Point values are assigned to each transactional and data function using tables contained in the IFPUG Counting Practices Manual. The value in the concept of using IFPUG Function Points is that it allows for accurate functional sizing, and in fact requires it early in the process.

Function Point Analysis permits us to estimate the size of a planned application and measure the size of an existing application. It can also be used to measure the size of changes to an existing application, whether those changes are in the detailed design phase or have already been completed. Knowing the functional size allows many other useful metrics to be determined.

Alternative sizing methods, such as counting lines of code, are dependent upon information that is not available until later in the development life cycle. Other functional measurement methods require detailed knowledge about system processing that is not available early enough for accurate counting, for example, states and transitions.

IFPUG Function Points accurately size the stated requirement. If the requirement is not clearly or fully defined, the project will not be properly sized. When there are missing, brief, or vague requirements, a simple interview process with the requesting user can be conducted to more fully define the requirements. Function Points can be utilized to better identify stated external inputs, external outputs, external inquiries, internal logical files, and external interface files. For an average size project, hours, not days, are required to complete the diagramming and sizing task.

Non-Functional Assessment

In addition to the project size, a non-functional assessment must be performed for the project. Before IFPUG's Framework for Non-Functional Sizing was developed, earlier versions of the IFPUG Counting Practices Manual acknowledged the existence of 14 general system characteristics (GSCs):

  1. Data communications
  2. Distributed data processing
  3. Performance
  4. Heavily used configuration
  5. Transaction rate
  6. Online data entry
  7. End-user efficiency
  8. Online update
  9. Complex processing
  10. Reusability
  11. Installation ease
  12. Operational ease
  13. Multiple sites
  14. Facilitate change

Each of these 14 characteristics was assigned a degree of influence between 0 and 5; consequently, the total degree of influence ranged between 0 and 70, which then was applied in a formula to become a value adjustment factor to the Function Point count. Although this was part of the Function Point methodology for many years, IFPUG embarked upon the effort to replace these GSCs through the use of SNAP, a more realistic and practical methodology to establish a link between the non-functional size and the effort to provide the non-functional requirements.

The SNAP assessment provides information that can identify items impacting quality and productivity by quantifying the size of non-functional requirements of the software that the user requests and receives. ISO has defined technical requirements as those requirements that relate to the technology and environment for the development, maintenance, support, and execution of the software. ISO has defined quality requirements as those characteristics that form part of the quality model: functionality, reliability, usability, efficiency, maintainability, and portability. SNAP offers a project assessment method that uses a series of questions grouped by category to measure the impact of non-functional requirements on the development and delivery (size) of the software product. The result will be the size of the non-functional requirements, just as the functional size is the size of the functional requirements.

Categories focus on those non-functional requirements that impact the development and delivery (size) of the software product but exclude on-site specific organizational factors that impact development effort and project duration but do not affect the delivered product size. Categories are generic enough to allow for future technologies. Each category includes subcategories or individual components, which are evaluated using assessment questions in order to produce an estimated impact of the category on product size.

Categories and subcategories include the following:

  • Data operations
    • Data entry validations
    • Logical and mathematical operations
    • Data formatting
    • Internal data movement
  • Interface design
    • UI changes
    • Help methods
    • Multiple input methods
    • Multiple output formats
  • Technical environment
    • Multiple platforms
    • Database technology
    • Configuration
    • Batch processing system
    • Multiple technologies
  • Architecture
    • Mission critical (real-time system)
    • Component-based software development (CBSD)
    • Design complexity

Assessment questions for each subcategory are related to specific attribute(s) that allows for the non-functional assessment of the given subcategory. Ratings will be ranges, qualitative values, ordinal values, and so on, depending upon the particular subcategory. Ratings are converted into SNAP counting units (SCUs); the SCU can be a component, a process, or an activity identified according to the nature of the subcategory. The complexity level of an assessment rating or the value of the SCU within each subcategory is mapped to a size, which is the arithmetic sum of the sizes of all SCUs identified in each subcategory. SNAP points are the final non-functional size obtained by combining all category values.


1. The International Function Point Users Group. 2010. Function Point Counting Practices Manual, Release 4.3. Princeton Junction. New Jersey: IFPUG Standards.

2. The International Function Point Users Group. 2011. SNAP Assessment Practices Manual. Princeton Junction. New Jersey: IFPUG Standards.

Read more IT Performance Improvement

This article is an excerpt from:

The International Function Point Users Group (IFPUG), a nonprofit and member-governed organization, has become the recognized leader in promoting the effective management of application software development and maintenance activities. Edited by IFPUG's Management and Reporting Committee, The IFPUG Guide to IT and Software Measurement brings together 52 leading software measurement experts from 13 different countries who share their insights and expertise. Covering measurement programs, function points in measurement, new technologies, and metrics analysis, the text is useful for IT project managers, process improvement specialists, measurement professionals, and business professionals who need to interact with IT professionals and participate in IT decision-making. It includes coverage of cloud computing, agile development, quantitative project management, process improvement, measurement as a tool in accountability, project ROI measurement, metrics for the CIO, value stream mapping, and benchmarking.

About David Garmus

David Garmus is an acknowledged authority in the sizing, measurement, and estimation of software application development and maintenance. As a cofounder of the David Consulting Group, he supports software development organizations in achieving software excellence with a metric-centered approach. He serves as a past president of the International Function Point Users Group (IFPUG), a past member of the IFPUG Counting Practices Committee and a current member of the Software Non-functional Assessment Process Working Group. Mr. Garmus is a Certified Function Point Specialist, having fulfilled all IFPUG requirements for this title under all releases of the IFPUG Counting Practices Manual, and a past Certified Software Measurement specialist.