Use Case Points: an analysis phase estimating technique

Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases. Use Case Points are derived from another software development estimating technique called “Function Points.” However, Function Points are used by systems analysts as a development phase technique that requires technical detail for estimating. (Note that this article assumes that the reader knows and understands the technique of use case. In this article, the term “system use case” or simply “use case” is a sequence of steps that accomplishes a user goal in a single online session.)

Probably the scariest word in the world is estimate. Whether we are looking at auto repair work or software development, estimating can bring the best of us to our knees. The purpose of an estimate is to set expectations. However, as soon as we provide an estimate, it is judged. It is either too high or too low (must be missing something).

Once I consulted for a firm that had outsourced all its software development. The firm still conducted the analysis phase for its applications internally resulting in a Business Requirements Document (BRD). The BRD was then passed by the firm to the outsourcer for software development implementation. For major efforts, the outsourcer always provided an estimate to the firm prior to development. During one consulting session, the firm’s management expressed a concern that a recent estimate was too high. Upon hearing this evaluation, I asked what they expected. The response was that there was no real expectation; they just “felt” the estimates were too high! Obviously what was missing was a preliminary estimate from the analysis phase to establish a baseline to compare with the outsourced estimate. Without a baseline, the discussion is pointless (pun intended).

Enter the World of Use Case Points

Assuming the Business Analyst composes system use cases for describing functional requirements during the analysis phase, the BA can estimate the development effort using a technique called Use Case Points; caveat, this estimate does not include work associated with project management, infrastructure and other support effort, and testing. Use Case Points are used as an analysis phase estimating technique developed by Gustav Karner in 1993 (1). They are derived from a development phase estimating technique called Function Points which was developed by Allan AlBrecht (2). In 2005, Agilis Solutions and FPT Software published a study (3) showing the estimation accuracy achieved using Use Case Points. The estimates were less than 9 percent from actual cost on 95 percent of the projects. The study included over 200 projects over a period of 5 years with the average project being 60 work months.

Both Use Case Points and Function Points techniques result in the number of hours needed to develop the software. The difference between the two techniques is in the information used for building the estimate.

• Use Case Points

  • Conducted by business analysts during the analysis phase of a project

  • Can be classified as a class IV or III estimate (4)

  • Is based on information contained in a business requirement document

    • Functional requirements as modeled via system use cases, actors, and scenarios

    • Nonfunctional requirements

    • Assumptions on developmental risks

• Function Points

  • Conducted by systems analysts during the development phase

  • Can be classified as a class II or I estimate which should be more detailed (4)

  • Is based on information contained in a technical specification

    • Data Functions using internal and external logical files

    • Transaction Functions using external inputs and external outputs, plus external inquiries

Calculating Use Case Points

To use this estimating technique, the business analyst uses four tables and four formulas.

• Tables

  • Two tables represent functional requirements as described by system use cases. Note that both of these tables are entitled “unadjusted” since the totals from these tables need to be adjusted by the work entailed by nonfunctional requirements and the risk due to the characteristics of the development team.

    • Unadjusted Actor Points

    • Unadjusted Scenario Points

  • Nonfunctional Requirements Adjustment Table

  • Developmental Risk Adjustment Table

• Formulas

  • Nonfunctional Adjustment Factor

  • Developmental Risk Adjustment Factor

  • Total Adjustment Factor

  • Total Unadjusted Use Case points

  • Total Adjusted Use Case Points

  • Development Work Estimate excluding project management, Infrastructure plus other supporting work, and testing – there has been some effort to include testing using a similar method with historical average testing hours per use case point (5)

Step 1 – Functional Requirement Tables

The first table (Table 1) considers the system use case actors. The purpose of the Unadjusted Actor Point Table is to classify and score different types of system use case actors. System use case actor roles can be portrayed by internal systems, external systems or people/time/sensors depending on the application. Respectively, these role types can be classified on the Karner weighted scale: simple – 1, average – 2, complex – 3. For example:

Table 1. Unadjusted Actor Points

The next table (Table 2) considers the system use cases. The purpose of the Unadjusted Use Case Point Table is to classify and score use cases on the basis of the number of dialogue exchanges. A dialogue exchange is defined as an actor request and a system response. Note that even though the system may have different responses to the same actor request, for example an error message, it is still considered a single dialogue exchange. These exchanges can be classified on a Karner weighted scale of simple (1-3 exchanges), average (4-7 exchanges), and complex (over 7 exchanges). For example:

Table 2. Unadjusted Use Case Points

Step 2 – Nonfunctional Requirement Table

The next table (Table 3) considers the nonfunctional requirements in order to adjust the system use case and actor points for application complexity. The purpose of the Nonfunctional Requirement Adjustment Factor Table is to classify and score nonfunctional requirements or general characteristics of the application. The total nonfunctional score along with the total developmental risk score (next step) is used as a factor to adjust the total unadjusted actor and use case points. The nonfunctional requirements are weighted (0-5, 5 being most concern) on importance and on a complexity scale (0-5, 0 being least complex, 3 being average, and 5 being most complex). Note that in the example, I have stated nonfunctional requirements, associated weights and complexity per my own experience; this means that the “constant” in the nonfunctional requirement adjustment factor formula needs to be determined for the average application.

Table 3. Nonfunctional Requirement Adjustment Factor (may be augmented with columns on weight and complexity rational)

Step 3 – Developmental Risk Table

The next table (Table 4) considers the development risk to adjust the system use case and actor points for risk associated with the team. The purpose of the Developmental Risk Adjustment Factor Table is to classify and score perceived risk with the team in developing the application. As stated previously, the total developmental risk score along with the total nonfunctional score is used as a factor to adjust the total unadjusted actor and use case points. As with the nonfunctional requirements, the developmental risk is weighted (0-5, 5 being most concern) on importance and rated on a scale (0-5, 0 being low, 3 being average, and 5 being high).

However, in the case of developmental risk, some risks are opposite in nature and should have a negative weight. For example, part-time members * (see Table 4) rather than full-time members have a negative impact. Therefore, a high rating for part-time members should have a negative score. Note that in the example, I have stated development risks, associated weights and ratings per my own experience; this means that the “constant” in the development risk adjustment factor formula needs to be determined for the average application.

Table 4. Developmental Risk Adjustment Factor (may be augmented with columns on weight and rating rational)

Step 4 - The Formulas

The business analyst uses the first two formulas to calculate the nonfunctional adjustment and the developmental risk factors. But before we delve into the formulas, I want to encourage the reader to understand the formulas. I recently read an article on blindly following templates (6); I feel the same way about formulas. Don’t just blindly use them. Understand how the formula works. As mentioned before, if you change the tables (modify entries or weights), ensure you adjust the formula “constants” so that the formulas still yield factors of 1 for an average system..

With the above adjustment factors calculated, the business analyst proceeds with final formulas for the use case point estimate. The business analyst first determines total adjustment factor by multiplying the nonfunctional and development risk factors. Given the nonfunctional requirements and developmental risks I have stated, the total adjustment factor ranges from a minimum of .3025 to a maximum of 2.735. The BA then adds up the total unadjusted scenario case and actor points, and finally multiplies the total adjustment factor and total unadjusted use case and actor points to produce the total adjusted use case points (see formulas and examples below).

The Conversion Formula

With the total adjusted use case points, the business analyst can now determine the work effort estimate in units of time for developing the use cases (note caveat at the beginning of this article). The key element in this conversion is the development hours per use case point. Unfortunately, the historical average development hours per use case point are probably not available for your firm. However, averages for function points are available ranging from 15 to 45 hours per function point depending on the industry (7). These averages may be used in lieu of established use case point averages. When in doubt, practitioners recommend to use 20 hours (8).

Summary

Figure 1 depicts a high-level view of the Use Case Points estimates process. As with any estimating technique, the purpose of Use Case Points is to set expectations. The 2005 Agilis Solutions and FPT Software results have provided some evidence of its accuracy. Business Analysts can use this estimating technique during the analysis phase of a project to generate class II or III estimates. Note the caveat of project management and testing exclusion, ensure the correct constant is used in the adjustment factor formulas, and limited availability of historical averages on use case points per hour.

References

1. Karner, Gustav. “Resource Estimation for Objectory Projects” Objective Systems SF AB, 1993.

2. Albrecht, A.J. “Measuring Application Development Productivity” Proc. of IBM Applications Development Symposium, Monterey, CA, 14-17 Oct. 1979: 83.

3. Carroll, Edward R. “Estimating Software Based on Use Case Points” 2005 Object-Oriented, Programming, Systems, Languages, and Applications (OOPSLA) Conference, San Diego, CA, 2005.

4. http://www.aacei.org/technical/rps/17r-97.pdf

5. http://www.scribd.com/doc/956228/Test-Effort-Estimation

6. http://www.batimes.com/articles/its-time-for-template-zombies-to-die.html

7. http://www.rebootrethink.com/justTheFacts/industrybyindustry.php

8. http://www.codeproject.com/KB/architecture/usecasepoints.aspx

Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].