Use case points
Use case points
Main page
U

Use case points

logo
Community Hub0 subscribers
Read side by side
Use case points
View on Wikipedia
from Wikipedia

Use case points (UCP or UCPs) is a software estimation technique used to forecast the software size for software development projects. UCP is used when the Unified Modeling Language (UML) and Rational Unified Process (RUP) methodologies are being used for the software design and development. The concept of UCP is based on the requirements for the system being written using use cases, which is part of the UML set of modeling techniques. The software size (UCP) is calculated based on elements of the system use cases with factoring to account for technical and environmental considerations. The UCP for a project can then be used to calculate the estimated effort for a project.

History

[edit]

The UCP technique was developed by Gustav Karner in 1993 while employed at what was known at the time as Objectory Systems, which later merged into Rational Software and then IBM. The UCP method was created to solve for estimating the software size of systems that were object oriented. It is based on similar principles as the Function Point (FP) estimation method, but was designed for the specific needs of object oriented systems and system requirements based on use cases.[1][2][3]

Method

[edit]

The method for determining the size estimate to develop a system is based on a calculation with the following elements:

  • Unadjusted Use Case Weight (UUCW) – the point size of the software that accounts for the number and complexity of use cases.
  • Unadjusted Actor Weight (UAW) – the point size of the software that accounts for the number and complexity of actors.
  • Technical Complexity Factor (TCF) – factor that is used to adjust the size based on technical considerations.
  • Environmental Complexity Factor (ECF) – factor that is used to adjust the size based on environmental considerations.

Once the previous four elements have been calculated, the final size estimate can be calculated. This final number is known as the use case points or UCP for a software development project.

The following sections walk through the various calculations to determine the UCP for a project.

Unadjusted Use Case Weight (UUCW)

[edit]

The UUCW is one of the factors that contribute to the size of the software being developed. It is calculated based on the number and complexity of the use cases for the system. To find the UUCW for a system, each of the use cases must be identified and classified as Simple, Average or Complex based on the number of transactions the use case contains. Each classification has a predefined weight assigned. Once all use cases have been classified as simple, average or complex, the total weight (UUCW) is determined by summing the corresponding weights for each use case. The following chart shows the different classifications of use cases based on the number of transactions and the weight value assigned for each use case within the classification.

Use Case Classification No. of Transactions Weight
Simple 1 to 3 transactions 5
Average 4 to 7 transactions 10
Complex 8 or more transactions 15
UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15)

Unadjusted Actor Weight (UAW)

[edit]

The UAW is another factor that contributes to the size of the software being developed. It is calculated based on the number and complexity of the actors for the system. Similar to finding the UUCW, each of the actors must be identified and classified as Simple, Average or Complex based on the type of actor. Each classification also has a predefined weight assigned. The UAW is the total of the weights for each of the actors. The following chart shows the different classifications of actors and the weight value assigned.

Actor Classification Type of Actor Weight
Simple External system that must interact with the system using a well-defined API 1
Average External system that must interact with the system using standard communication protocols (e.g. TCP/IP, FTP, HTTP, database) 2
Complex Human actor using a GUI application interface 3
UAW = (Total No. of Simple actors x 1) + (Total No. Average actors x 2) + (Total No. Complex actors x 3)

Technical Complexity Factor (TCF)

[edit]

The TCF is one of the factors applied to the estimated size of the software in order to account for technical considerations of the system. It is determined by assigning a score between 0 (factor is irrelevant) and 5 (factor is essential) to each of the 13 technical factors listed in the table below. This score is then multiplied by the defined weighted value for each factor. The total of all calculated values is the technical factor (TF). The TF is then used to compute the TCF with the following formula:

TCF = 0.6 + (TF/100)
Factor Description Weight
T1 Distributed system 2.0
T2 Response time/performance objectives 1.0
T3 End-user efficiency 1.0
T4 Internal processing complexity 1.0
T5 Code reusability 1.0
T6 Easy to install 0.5
T7 Easy to use 0.5
T8 Portability to other platforms 2.0
T9 System maintenance 1.0
T10 Concurrent/parallel processing 1.0
T11 Security features 1.0
T12 Access for third parties 1.0
T13 End user training 1.0

Environmental Complexity Factor (ECF)

[edit]

The ECF is another factor applied to the estimated size of the software in order to account for environmental considerations of the system. It is determined by assigning a score between 0 (no experience) and 5 (expert) to each of the 8 environmental factors listed in the table below. This score is then multiplied by the defined weighted value for each factor. The total of all calculated values is the environment factor (EF). The EF is then used to compute the ECF with the following formula:

ECF = 1.4 + (-0.03 x EF)
Factor Description Weight
E1 Familiarity with development process used 1.5
E2 Application experience 0.5
E3 Object-oriented experience of team 1.0
E4 Lead analyst capability 0.5
E5 Motivation of the team 1.0
E6 Stability of requirements 2.0
E7 Part-time staff -1.0
E8 Difficult programming language -1.0

Use Case Points (UCP)

[edit]

Finally the UCP can be calculated once the unadjusted project size (UUCW and UAW), technical factor (TCF) and environmental factor (ECF) have been determined. The UCP is calculated based on the following formula:

UCP = (UUCW + UAW) x TCF x ECF

Example

[edit]

To illustrate the process of calculating the UCP, an Online Shopping System will be used. The diagram below depicts the Use Case Diagram for the system to be developed.

Online Shopping System Use Case Model

Unadjusted Use Case Weight (UUCW)

[edit]

To calculate the UUCW, the use cases must be defined and the number of transactions for each use case identified. The Online Shopping System use case diagram is depicting that nine use cases exist for the system. Assuming 2 of these use cases are simple, 3 are average and 4 are complex, the calculation for UUCW is as follows:


UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15)
For the Online Shopping System, the UUCW = (2 x 5) + (3 x 10) + (4 x 15) = 100
UUCW = 100

Unadjusted Actor Weight (UAW)

[edit]

To calculate the UAW, the actors must be identified. The Online Shopping System use case diagram is depicting five actors; One simple for the Payment Processing System and four complex for each of the human users actors (i.e. Online Customer, Marketing Administrator, Warehouse Clerk, Warehouse Manager.) The calculation for UAW is as follows:

UAW = (Total No. of Simple Actors x 1) + (Total No. Average Actors x 2) + (Total No. Complex Actors x 3)
For the Online Shopping System, UAW = (1 x 1) + (0 x 2) + (4 x 3) = 13
UAW = 13

Technical Complexity Factor (TCF)

[edit]

To calculate the TCF, each of the technical factors is assigned a value based on how essential the technical aspect is to the system being developed. The diagram below shows the assigned values for the Online Shopping System. The values are multiplied by the weighted values and the total TF is determined.

Factor Description Weight Assigned Value Weight x Assigned Value
T1 Distributed system 2.0 5 10
T2 Response time/performance objectives 1.0 5 5
T3 End-user efficiency 1.0 3 3
T4 Internal processing complexity 1.0 2 2
T5 Code reusability 1.0 3 3
T6 Easy to install 0.5 1 0.5
T7 Easy to use 0.5 5 2.5
T8 Portability to other platforms 2.0 2 4
T9 System maintenance 1.0 2 2
T10 Concurrent/parallel processing 1.0 3 3
T11 Security features 1.0 5 5
T12 Access for third parties 1.0 1 1
T13 End user training 1.0 1 1
Total (TF): 42

Next, the TCF is calculated:

TCF = 0.6 + (TF/100)
For the Online Shopping System, TCF = 0.6 + (42/100) = 1.02
TCF = 1.02

Environmental Complexity Factor (ECF)

[edit]

To calculate the ECF, each of the environmental factors is assigned a value based on the team experience level. The diagram below shows the assigned values for the Online Shopping System. The values are multiplied by the weighted values and the total EF is determined.

Factor Description Weight Assigned Value Weight x Assigned Value
E1 Familiarity with development process used 1.5 3 4.5
E2 Application experience 0.5 3 1.5
E3 Object-oriented experience of team 1.0 2 2
E4 Lead analyst capability 0.5 5 2.5
E5 Motivation of the team 1.0 2 2
E6 Stability of requirements 2.0 1 2
E7 Part-time staff -1.0 0 0
E8 Difficult programming language -1.0 4 -4
Total (EF): 10.5

Next, the ECF is calculated:

ECF = 1.4 + (-0.03 x EF)
For the Online Shopping System, ECF = 1.4 + (-0.03 * 10.5) = 1.085
ECF = 1.085

Use Case Points (UCP)

[edit]

Once the Unadjusted Use Case Weight (UUCW), Unadjusted Actor Weight (UAW), Technical Complexity Factor (TCF) and Environmental Complexity Factor (ECF) has been determined, the Use Case Points (UCP) can be calculated with the following formula:

UCP = (UUCW + UAW) x TCF x ECF
For the Online Shopping System, UCP = (100 + 13) x 1.02 x 1.085 = 125.06
UCP = 125.06

For the Online Shopping System, the total estimated size to develop the software is 125.06 Use Case Points.

Now that the size of the project is known, the total effort for the project can be estimated. For the Online Shopping System example, 28 man hours per use case point will be used.

Estimated Effort = UCP x Hours/UCP
For the Online Shopping System, Estimated Effort = 125.06 x 28
Estimated Effort = 3501 Hours

Further development

[edit]

One major weakness of the Use Case Points method is that it has never been thoroughly calibrated using regression analysis due to a lack of a statistically sufficient number of projects. Moreover, the linear model of Karners approach does not take the diseconomies of scale into account that occur in software development projects.[4] Still, the easily applicable sizing approach and counting rules provide many benefits for estimations in early phases and thus allow to quickly yield the FSM (functional size measurement, in this case UUCW + UAW) of an application or IT product. This FSM can then be combined with statistically validated estimation models like COCOMO II to gain more reliable estimation results.[4]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Use case points

View on Grokipedia
from Grokipedia
Use case points (UCP) is a software estimation technique that measures the functional size of an application based on the number and complexity of its use cases and actors, which are then adjusted by technical and environmental factors to derive project effort and duration.[1] Developed by Gustav Karner in 1993 for object-oriented projects using the Objectory method, UCP enables early-phase sizing similar to function point analysis but leverages use case models instead of data flows.[2] The method begins by calculating the unadjusted use case points (UUCP) as the sum of the unadjusted actor weight (UAW)—assigning 1 point for simple actors (e.g., API interfaces), 2 for average (e.g., protocol-driven), and 3 for complex (e.g., graphical user interfaces)—and the unadjusted use case weight (UUCW)—assigning 5 points for simple use cases (≤3 transactions), 10 for average (4-7 transactions), and 15 for complex (>7 transactions).[1] These are then adjusted by a technical complexity factor (TCF), computed as 0.6 + (0.01 × sum of 13 weighted technical factors rated 0-5, such as distributed data processing weighted at 2), and an environmental factor (EF), computed as 1.4 + (-0.03 × sum of 8 weighted environmental factors rated 0-5, such as team experience with the process weighted at 1.5).[2] The final UCP value is UUCP × TCF × EF, which is typically converted to effort in person-hours by multiplying by an empirical constant of 20-28 hours per UCP, depending on the project's velocity.[1] UCP has been empirically validated in case studies, such as on five web application projects at Hitachi Systems & Services, where tool-assisted UCP calculations showed high precision in actor and use case classification (0.40-1.0), though discrepancies arose from ambiguous transaction definitions, demonstrating its utility for early estimation in Java and VB.NET environments.[1] Widely adopted in agile and unified process contexts, UCP remains relevant for object-oriented and UML-based projects due to its simplicity and reliance on requirements artifacts available in initial phases.[2]

History and Background

Origins and Development

The Use Case Points (UCP) method was invented by Gustav Karner in 1993 while working at Objectory AB, a software development company founded by Ivar Jacobson focused on object-oriented methodologies.[3] Karner's work addressed the need for a sizing technique tailored to Objectory's process, which emphasized use cases as a core artifact for capturing requirements.[3] Inspired by function point analysis—a metric originally proposed by Allan Albrecht in 1979 for measuring functional size in structured programming—UCP adapted the concept to object-oriented systems by leveraging use case specifications instead of data functions and transactions.[3] This adaptation incorporated Objectory's requirements analysis phase, enabling early-phase functional size measurement (FSM) for software projects to support resource estimation in man-hours and cost prediction.[3] The method's initial purpose was to provide a standardized, repeatable way to forecast effort after requirements capture but before detailed design, overcoming limitations in traditional function points such as subjectivity in counting and lack of consideration for personnel factors.[3] Key events in UCP's early evolution include its publication in Objectory's internal documentation through Karner's 1993 paper, "Resource Estimation for Objectory Projects," which outlined the core model.[3] Following Rational Software's acquisition of a majority stake in Objectory AB in 1995, the methodology transitioned into the Rational Objectory Process and later the Rational Unified Process (RUP) in the late 1990s, facilitating broader dissemination as Rational merged with IBM in 2003.[4] This integration with RUP and UML—where use cases became a standard modeling element—marked the shift from proprietary Objectory tool to a widely referenced estimation technique in object-oriented software engineering post-1990s.[5]

Adoption in Software Engineering

The use case points (UCP) method, proposed by Gustav Karner in 1993, experienced early adoption in the 1990s primarily within object-oriented software development projects that emphasized UML-based modeling.[6] As UML was standardized in 1997, incorporating use case diagrams as a core artifact for capturing functional requirements, UCP emerged as a complementary estimation technique for sizing efforts in these environments, particularly in projects following methodologies like Objectory.[6] This integration aligned UCP with the growing prevalence of use cases in requirements engineering, enabling early-phase predictions in OO paradigms.[7] Adoption expanded significantly in the 2000s, driven by the widespread use of modeling tools such as Rational Rose, which supported UML use case creation and facilitated UCP calculations within Rational Unified Process (RUP) workflows—a structured approach that served as a precursor to agile practices.[8] Interest peaked around 2005, with UCP applied in diverse software projects to validate estimates against historical data, as demonstrated in a 2002 ISECON study that compared UCP predictions to expert judgments and found promising accuracy for practical application.[9] The method also featured prominently in IEEE publications on software estimation, with over 27 studies by 2020 exploring its refinements and empirical validations in conference proceedings.[6] As of 2021, UCP maintains relevance in requirements-driven software projects, particularly those relying on use case specifications for effort forecasting, with a systematic review identifying 75 studies focused on its calibration and adaptation using techniques like regression and machine learning.[6] Ongoing research underscores its utility in object-oriented contexts, though adoption remains more limited in fully agile environments favoring story points.

Fundamental Concepts

Use Cases and Actors

In the Use Case Points methodology, a use case represents a description of the system's functionality from a user's perspective, outlining the interactions between actors and the system to achieve a specific goal.[3] Use cases typically involve primary actors, who initiate the interaction to accomplish their objectives, and secondary actors, who assist the system or are impacted by the outcome during the process. This structure ensures that use cases capture complete sequences of system behavior, including preconditions, postconditions, and flows of events. Actors are external entities that drive or participate in use case executions, such as human users, other software systems, or hardware components interacting with the target system.[3] In this methodology, actors are classified as simple if they are external systems interacting via a defined API (weight 1); average if interactions occur via protocols (e.g., TCP/IP) or humans use a terminal interface (weight 2); complex if humans interact via a graphical user interface (weight 3).[3][10] These classifications reflect the varying levels of interface simplicity and system responsiveness required. Within a use case, transactions form the core units of measurement, consisting of the steps in the main success path along with alternative paths and exception handling scenarios.[3] Each transaction details a discrete system response to an actor's action, ensuring the use case provides a comprehensive view of potential interaction flows without branching into implementation details.[11] The methodology benefits from use cases authored according to consistent standards, such as those in the Unified Modeling Language (UML), to ensure clear, unambiguous descriptions of actor-system interactions, goals, and scenarios to enable reliable analysis.[3]

Complexity Assessment

In use case points estimation, the complexity of use cases is evaluated based on the number of transactions they encompass, where a transaction represents an atomic unit of interaction between the actor and the system. Use cases are classified as simple (1-3 transactions, weight 5), average (4-7 transactions, weight 10), or complex (more than 7 transactions, weight 15). This classification provides a structured way to gauge the functional scope and effort required for implementation.[2] Actor complexity is assessed according to the nature of the interface and interaction mechanism. Actors are classified as simple (API interactions, weight 1), average (protocol-based like TCP/IP or text-based human interaction, weight 2), or complex (graphical user interfaces for humans, weight 3). Such distinctions account for the varying levels of integration challenges posed by different actor types.[2] To accurately count transactions, count the steps in the main success scenario of the use case; alternative and exception flows are generally not included unless they add unique steps, while excluding post-conditions that merely describe the resulting system state without additional processing. This approach ensures a comprehensive yet focused measure of the system's behavioral demands. For instance, validating user input and updating a database record would each count as separate transactions if they occur in sequence or branch.[2] Common pitfalls in this assessment include overcounting trivial steps, such as basic data displays or acknowledgments that do not alter system state, which can artificially elevate complexity ratings. Conversely, underestimating the number of branches in alternative flows—such as error handling paths or conditional decisions—may lead to incomplete complexity evaluations and subsequent estimation inaccuracies. Adhering to consistent definitions of transactions mitigates these issues.[2]

Estimation Methodology

Unadjusted Actor Weight (UAW)

The Unadjusted Actor Weight (UAW) represents the initial measure of system size contributed by its actors, which are external entities interacting with the system, such as users or other systems.[2] Actors are weighted according to their complexity because the nature of the interface required for interaction influences development effort; for instance, integrating with a simple automated system demands less effort than supporting a human through a sophisticated graphical interface.[2] This weighting scheme originates from Gustav Karner's 1993 Use Case Points method, as documented in subsequent analyses.[2] The formula for calculating UAW is:
UAW=(number of simple actors×1)+(number of average actors×2)+(number of complex actors×3) \text{UAW} = (\text{number of simple actors} \times 1) + (\text{number of average actors} \times 2) + (\text{number of complex actors} \times 3)
This equation sums the weighted contributions of all identified actors to yield a total unadjusted value.[2] To compute UAW, first identify all actors from the use case model, then classify each based on established criteria for complexity (as outlined in the broader complexity assessment process).[2] Next, assign the corresponding weight to each classified actor—simple actors receive 1 point, average actors 2 points, and complex actors 3 points—and finally sum these weighted values to obtain the UAW.[2] This process ensures a standardized quantification of actor-driven size before any environmental or technical adjustments. For example, consider a system interacting with 2 simple actors (such as external APIs), 3 average actors (such as human users via text interfaces), and 1 complex actor (such as a hardware device requiring detailed control): the UAW would be (2×1)+(3×2)+(1×3)=11(2 \times 1) + (3 \times 2) + (1 \times 3) = 11.[2]

Unadjusted Use Case Weight (UUCW)

The Unadjusted Use Case Weight (UUCW) represents the initial measure of functional size contributed by the use cases in a software project, serving as a key component in the Use Case Points (UCP) estimation method developed by Gustav Karner in 1993.[12] This weight quantifies the complexity of user interactions without considering technical or environmental factors, focusing solely on the scenarios described in the use cases. To calculate UUCW, use cases are first classified based on the number of transactions, where a transaction is a step in the main success scenario, with extensions counted only if they represent new actions that advance the use case toward its goal. Use cases are categorized as simple (3 or fewer transactions, weighted at 5 points), average (4 to 7 transactions, weighted at 10 points), or complex (more than 7 transactions, weighted at 15 points).[2] The process involves: (1) identifying and counting all use cases from the project's requirements; (2) determining the transaction count for each use case by analyzing its main flow and relevant extensions; (3) assigning each use case to the appropriate complexity category; and (4) summing the weighted values across all use cases. The resulting formula is:
UUCW=(number of simple use cases×5)+(number of average use cases×10)+(number of complex use cases×15) \text{UUCW} = (\text{number of simple use cases} \times 5) + (\text{number of average use cases} \times 10) + (\text{number of complex use cases} \times 15)
This approach provides a structured way to assess size early in development.[13] The rationale for UUCW lies in its ability to reflect the functional complexity inherent in achieving user goals through detailed scenarios, where higher transaction counts indicate greater implementation effort due to increased logic, data handling, and interface requirements.[2] By weighting use cases proportionally to their transaction volume, the metric captures variations in scope without delving into implementation details, promoting consistency in estimation across projects. For illustration, consider a project with 3 simple use cases, 4 average use cases, and 2 complex use cases: UUCW = (3 × 5) + (4 × 10) + (2 × 15) = 15 + 40 + 30 = 85.[13] This value contributes to the overall unadjusted size when combined with actor weights, though UUCW itself focuses exclusively on use case contributions.

Technical Complexity Factor (TCF)

The Technical Complexity Factor (TCF) adjusts the unadjusted use case points for the technical attributes of the project that influence development effort, such as system architecture and performance demands. Introduced by Gustav Karner in his 1993 resource estimation model for Objectory projects, the TCF scales the estimate based on 13 technical factors, each rated on a scale from 0 (irrelevant) to 5 (essential), with a neutral default of 3 if no specific information is available.[3] The TCF is calculated using the formula:
TCF=0.6+(0.01×TFactor) \text{TCF} = 0.6 + (0.01 \times \text{TFactor})
where TFactor is the sum of each factor's rating multiplied by its assigned weight, and the weights total 14 across all factors. This yields a TCF value typically ranging from 0.6 (minimal technical complexity) to 1.3 (high complexity), thereby increasing or decreasing the effort estimate proportionally. The calculation process involves: (1) rating each of the 13 factors based on project requirements; (2) multiplying each rating by its weight; (3) summing these products to obtain TFactor; and (4) applying the formula to derive TCF. For example, if all factors are rated neutrally at 3, TFactor = 42, resulting in TCF = 1.02.[3][13] The 13 technical factors, along with their weights and brief descriptions, are as follows:
Factor IDDescriptionWeight
F₁Distributed systems (e.g., data or processing across multiple sites)2
F₂Application performance objectives (e.g., response time constraints)1
F₃End-user efficiency (e.g., online transaction speed for users)1
F₄Complex internal processing (e.g., intricate algorithms)1
F₅Reusability (e.g., code components intended for reuse in other projects)1
F₆Installation ease (e.g., simplicity of setup for end users)0.5
F₇Operational ease and usability (e.g., intuitive interface design)0.5
F₈Portability (e.g., adaptability across hardware or software platforms)2
F₉Changeability (e.g., ease of future modifications)1
F₁₀Concurrency (e.g., handling multiple simultaneous users)1
F₁₁Special security features (e.g., custom encryption or access controls)1
F₁₂Direct access for third parties (e.g., API exposure to external systems)1
F₁₃Special user training facilities (e.g., need for extensive documentation or sessions)1
This weighting scheme emphasizes factors like distribution and portability, which have higher impacts on effort.[3][14] The rationale for the TCF lies in accounting for implementation challenges that arise from technical decisions, such as the added effort for reusable components or stringent security measures, ensuring the estimate reflects real-world development hurdles beyond functional size. By incorporating these factors early in the analysis phase, the TCF helps mitigate underestimation in projects with non-trivial technical demands.[3][15]

Environmental Complexity Factor (ECF)

The Environmental Complexity Factor (ECF) adjusts the unadjusted use case points to account for environmental and human factors that influence development productivity, such as team experience, motivation, and project stability. These elements can either enhance efficiency or introduce challenges that extend effort requirements.[2] Originally proposed by Gustav Karner in 1993 as part of the Use Case Points method for Objectory projects, the ECF incorporates eight specific factors weighted to reflect their relative impact on overall project performance.[12] The ECF is computed using the formula:
ECF=1.4+(−0.03×EFactor) \text{ECF} = 1.4 + (-0.03 \times \text{EFactor})
where EFactor is the sum of each environmental factor's rating multiplied by its weight, with ratings assigned on a scale of 0 to 5 (0 indicating no influence and 5 a strong influence; 3 is neutral). The weights are calibrated such that an EFactor of approximately 13.5 (all ratings at 3) yields an ECF near 1, resulting in no net adjustment; typical ECF values range from 0.5 to 1.4.[2][12] The eight environmental factors, their weights, and brief descriptions are as follows:
FactorWeightDescription
Familiarity with the project domain1.5Assesses the team's prior experience with the project's domain; higher ratings for greater familiarity enhance productivity.
Application experience0.5Evaluates the team's domain knowledge in the application's field; beneficial for reducing learning curves.
Object-oriented experience1.0Measures proficiency in object-oriented analysis and design; crucial for projects using OO methodologies.
Lead analyst capability0.5Gauges the skill and experience of the lead requirements analyst; strong leadership streamlines development.
Motivation1.0Reflects the team's overall drive and commitment; high motivation accelerates progress.
Stable requirements2.0Considers the likelihood of requirements remaining unchanged; stability (high rating) minimizes rework.
Part-time staff-1.0Accounts for the percentage of part-time workers; higher proportions (high rating) negatively affect coordination and output.
Difficult programming-1.0Examines the complexity of the programming language or tools; more challenging environments (high rating) increase effort.
To calculate EFactor, rate each factor based on project specifics, multiply by the weight (positive for advantageous factors, negative for hindering ones), and sum the values; insert this into the ECF formula to scale the unadjusted points accordingly.[2] This factor's rationale lies in recognizing that team capabilities and environmental conditions profoundly shape development velocity, allowing the estimation to adapt unadjusted use case points—which derive from actors and use cases—to real-world organizational dynamics for more precise effort forecasting.[12]

Calculating Use Case Points (UCP)

The calculation of use case points (UCP) integrates the unadjusted components and adjustment factors to yield a normalized measure of software size, originally proposed by Gustav Karner in 1993 for Objectory projects.[12] The process begins with the summation of unadjusted elements to form the unadjusted use case points (UUCP), which captures the baseline functional size without environmental or technical adjustments. The unadjusted actor weight (UAW) and unadjusted use case weight (UUCW), derived from actor and use case complexity assessments, are added together as follows:
UUCP=UAW+UUCW \text{UUCP} = \text{UAW} + \text{UUCW}
[1] This UUCP value is then adjusted for project-specific technical and environmental influences by multiplying it by the technical complexity factor (TCF) and environmental complexity factor (ECF), both of which are typically values around 1 that scale the size upward or downward based on predefined weights.[1] The resulting UCP serves as a standardized size metric, independent of implementation details, enabling comparisons across projects and facilitating effort forecasting. The complete formula is:
UCP=UUCP×TCF×ECF \text{UCP} = \text{UUCP} \times \text{TCF} \times \text{ECF}
[1] To estimate development effort from the UCP, the metric is multiplied by an organization-specific velocity factor representing hours per UCP, often calibrated from historical project data.[12] Karner's original method suggests a baseline of 20 hours per UCP, though empirical studies indicate a typical range of 15 to 30 hours depending on team experience and project constraints.[1] The effort in person-hours is thus computed as:
Person-hours=UCP×Hours per UCP \text{Person-hours} = \text{UCP} \times \text{Hours per UCP}
[12] For improved accuracy, the hours-per-UCP velocity should be calibrated using regression analysis on completed projects, correlating actual effort against calculated UCPs to derive an organization-tailored factor that accounts for variations in productivity.[16] This calibration step is essential, as unadjusted defaults may overestimate or underestimate effort by 20-50% without historical refinement.[17]

Advantages and Limitations

Advantages

Use case points estimation provides significant advantages due to its applicability early in the software development lifecycle. By leveraging use cases developed during the requirements phase, it enables project size measurement before detailed design or coding commences, facilitating timely planning and resource allocation.[2] A key strength lies in its technology independence, as the method assesses functionality based on use case interactions and actors without reliance on specific programming languages, platforms, or implementation choices, making it versatile across diverse project environments.[2] The approach is characterized by its simplicity, employing straightforward, formula-based calculations that reduce complexity compared to expert judgment or analogy-based techniques, thereby enhancing consistency in estimates.[2] Additionally, its structure supports automation, allowing integration with use case management tools to automate complexity weighting and point computation, which minimizes manual errors and accelerates the estimation process.[2] Empirical validation underscores these benefits, with studies confirming its effectiveness in object-oriented projects, where Ribu (2001) derived effort rates of 15 to 30 hours per use case point based on practical applications.[18] For web projects, a case study involving seven teams developing a real-world web application demonstrated accurate effort predictions using adjusted use case points, aligning closely with actual development times.[19]

Limitations

One significant limitation of the Use Case Points (UCP) method is the inherent subjectivity involved in classifying the complexity of actors, use cases, and adjustment factors such as the Technical Complexity Factor (TCF) and Environmental Factor (EF). Estimators must rely on judgment to categorize elements—for instance, determining whether a use case is simple, average, or complex based on transaction counts—which can lead to variability in estimates across different teams or individuals. This subjectivity arises particularly in counting transactions, where alternative interpretations (e.g., grouping sub-steps as one or multiple) can alter weights significantly.[6][20] Another challenge is the lack of proper calibration in the UCP model's linear assumptions, which fail to account for scale diseconomies or non-linear effort growth in larger projects. The fixed weights (e.g., 5 unadjusted use case points for simple use cases with 1-3 transactions, jumping to 10 for 4-7) create abrupt discontinuities, potentially over- or underestimating size without historical data to refine velocity rates. Limited availability of calibrated datasets further exacerbates this, as most studies rely on small or educational project samples, reducing generalizability and reliability for diverse software contexts. Recent studies (2023–2025) have explored machine learning integrations, such as neural networks and fuzzy logic, to improve calibration and reduce these issues.[16][6][21][22] UCP estimation is highly dependent on the quality and completeness of use case specifications, making it vulnerable to inaccuracies if requirements are vague, incomplete, or poorly structured. Without standardized templates for use case documentation, inconsistencies in detail levels can propagate errors throughout the weighting process, leading to substantial deviations in final effort predictions. This dependency is particularly problematic in early project stages, where use cases may evolve, requiring frequent recalibration.[6][20] Recent critiques, particularly post-2020, highlight UCP's reduced effectiveness in modern development paradigms without adaptations, such as agile methodologies common in microservices architectures. The method struggles with iterative requirement changes and lacks stable techniques for translating points to effort in dynamic environments, limiting its adoption in agile settings where use cases may not fully capture distributed system complexities.[6][23]

Applications and Examples

Illustrative Calculation Example

Consider a hypothetical web-based system for making investment decisions and trading mutual funds to illustrate the use case points estimation process. This system involves actors weighted to yield an unadjusted actor weight (UAW) of 40: simple actors (e.g., API) at 1 point each, average (e.g., protocol-driven) at 2 points, and complex (e.g., graphical user interfaces) at 3 points. The use cases include 40 simple ones (3-4 transactions, 5 points each), 21 average ones (5-7 transactions, 10 points each), and 10 complex ones (>7 transactions, 15 points each), resulting in an unadjusted use case weight (UUCW) of 560.[2] The unadjusted use case points (UUCP) are then UAW + UUCW = 40 + 560 = 600.[2] To adjust for technical and environmental complexities, factor ratings are applied. The technical complexity factor (TCF) is calculated as 0.6 + (0.01 × TFactor), where TFactor=42 from weighted sum of 13 technical factors rated 0-5, yielding TCF=1.02. The environmental complexity factor (ECF) is 1.4 + (-0.03 × EFactor), where EFactor=17.5 from 8 environmental factors, yielding ECF=0.89. These assume typical project conditions. The use case points (UCP) follow as UUCP × TCF × ECF = 600 × 1.02 × 0.89 = 545.[2] Finally, effort is estimated by multiplying UCP by 20-28 hours per UCP, yielding 10,900 to 15,260 hours total development effort for a moderately experienced team. With 10 developers working 30 hours per week, this equates to approximately 19-26 two-week iterations (38-52 weeks).[2]

Real-World Applications

Use case points have been applied in web development projects, such as a multi-company case study developing a web-based issue tracking system for a research laboratory, where the method yielded an initial estimate of 413 hours against actual efforts ranging from 431 to 943 hours across different development processes.[24] In lighter, code-and-fix approaches, the estimate was accurate within 4%, demonstrating improved precision when aligned with simpler workflows, though heavier processes emphasizing quality led to up to 128% overruns due to unaccounted factors.[24] In agile environments, use case points have been adapted for sprint planning in Scrum by using unadjusted weights on burndown charts, allowing teams to track progress by burning down points for completed use cases (e.g., 5 points for simple, 10 for average, 15 for complex), which supports iterative estimation without requiring a full upfront model.[2] This semi-agile variant facilitates velocity tuning in Scrum teams, enabling relative sizing of requirements while aligning with incremental delivery principles.[2] Adoption is notable in banking for requirements-heavy systems, as seen in three industrial case studies involving finance applications like credit card support and customer relationship management (CRM) software, where use case points provided early estimates within 30% of actual efforts (e.g., 2550 estimated vs. 3670 actual hours for one project).[25] In healthcare, the method has been used for estimating health surveillance applications, achieving a high correlation (0.984) between estimated and actual efforts across 12 projects, with an adjusted effort rate of 8 hours per point reflecting efficiencies from reusable components.[26] Calibrated use case points, particularly when incorporating historical experience data, have reduced project overruns by approximately 10% in accuracy compared to baseline models, as evidenced in analyses of multiple software projects where refined factors lowered misestimations from 20-30% to tighter ranges.[27] Systematic reviews of industrial applications report mean magnitude of relative error (MMRE) around 31.5% and 80.6% of predictions within 25% accuracy, establishing better overrun control in sectors like finance and IT when environmental factors are tuned.[6] A 2025 systematic review further confirms the ongoing use of UCP alongside expert judgment for effort estimation, highlighting best practices that enhance accuracy in diverse software projects.[28]

Comparisons and Extensions

Comparison with Function Points

Both use case points (UCP) and function points (FP) are functional size measurement (FSM) techniques designed to estimate software size and development effort independently of programming language or technology. They share a core structure involving an unadjusted measure of functional components followed by adjustments for technical and environmental complexities to derive a calibrated size metric. This commonality allows both to serve as inputs for parametric effort models, such as those based on historical productivity rates.[29][30] Key differences arise in their foundational approaches and application timing. UCP focuses on behavioral, goal-oriented descriptions captured in use cases, weighing actors and use case complexity based on transactional steps and scenarios to reflect user-system interactions. In contrast, FP is data-oriented, quantifying size through elementary processes like external inputs, outputs, inquiries, internal logical files, and external interfaces, which emphasize the system's data handling capabilities. UCP is typically applied early in the lifecycle during requirements elicitation, leveraging use case artifacts without needing detailed design, whereas FP requires more mature specifications, often post-design, to identify data elements accurately.[29][2][31] UCP is particularly suited for projects driven by use cases, such as those employing UML or object-oriented analysis, where functional requirements are expressed through actor goals and system responses. FP, however, excels in transactional or data-centric systems, like database applications or legacy maintenance, where precise counting of data movements provides reliable sizing. Empirical studies highlight trade-offs in their performance: one analysis of public service applications found UCP variants achieving 11.9% deviation from actual effort compared to 27.8% for FP, suggesting higher accuracy for UCP despite its greater number of adjustment factors (21 versus 14), though FP's simpler process may enable faster estimation in practice. Additionally, FP benefits from broader standardization and larger benchmark datasets, such as the ISBSG repository with over 4,000 projects, while UCP data remains more limited and organization-specific.[30][31][29]

Integration with Other Estimation Models

Use case points (UCP) can serve as a size metric input to the COCOMO II model, where the adjusted UCP value replaces traditional lines of code or function points to drive parametric effort calculations, particularly beneficial for early-stage estimates in object-oriented projects.[32] This integration leverages UCP's focus on functional requirements to calibrate COCOMO II's effort multipliers, yielding more accurate predictions by incorporating use case complexity early in global software development contexts.[33] In agile environments, UCP can be adapted by decomposing use cases into user stories, then mapping unadjusted use case weights (e.g., simple: 5 points, average: 10, complex: 15) directly to story points for relative sizing.[2] Velocity calibration follows by tracking completed use case weights per sprint via burndown charts, allowing teams to derive historical productivity rates (e.g., story points per iteration) and refine sprint planning without full upfront use case modeling.[2] For large-scale projects, UCP extensions incorporate factors like the Equivalent Modification Factor (EMF) to account for incremental use case breakdowns and an Overhead Factor (OF) for integration overheads, improving accuracy in distributed, iterative developments.[34] Hybrid approaches with test estimation apply UCP to derive test case volumes from use case scenarios, adjusting for technical factors to compute testing effort (e.g., AUCP × conversion rate in man-hours), as outlined in use-case methodologies among standard test estimation techniques.[35][36] Emerging directions involve AI-assisted classification, where machine learning models like Gaussian Process Regression combined with fuzzy logic process UCP inputs to mitigate subjectivity in actor and use case weighting, achieving up to 92% improvement in effort prediction accuracy on historical datasets.[37]

References

  1. [PDF] Estimating effort by use case points: method, tool and case study
  2. Estimating With Use Case Points - Mountain Goat Software
  3. [PDF] Resource Estimation for Objectory Projects
  4. The History of the Unified Process - Scott Ambler
  5. https://ieeexplore.ieee.org/document/5364515
  6. Predicting software effort from use case points: A systematic review
  7. Estimating Effort by Use Case Points: Method, Tool and Case Study
  8. https://ieeexplore.ieee.org/document/1357913
  9. [PDF] estimation using use case points - ISCAP Conference
  10. (PDF) Use Case Points - ResearchGate
  11. [PDF] Use Case Points - www3.fiit.stuba.sk
  12. (PDF) Project Estimation With Use Case Points - ResearchGate
  13. [PDF] Chapter 6 - Use Case Points
  14. Estimation Techniques - Use-Case Points
  15. https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1905/Use-Case-Points-an-analysis-phase-estimating-technique.aspx
  16. (PDF) Calibrating Use Case Points - ResearchGate
  17. Simplifying effort estimation based on Use Case Points - ScienceDirect
  18. [PDF] Estimating Object-Oriented Software Projects with Use Cases
  19. An Empirical Study on the Estimation of Software Development Effort ...
  20. [PDF] enhancing-use-case-points-estimation-method-using-soft ...
  21. Early Estimation in Agile Software Development Projects - MDPI
  22. [PDF] A Multiple-Case Study of Software Effort Estimation based on Use ...
  23. [PDF] Estimating Software Development Effort based on Use Cases
  24. Using Use Case Points Method In a Health Surveillance Application ...
  25. (PDF) Efforts Estimation by Use Case Point using Experience Data
  26. Function Points or Use Case Points | PDF | Use Case | Measurement
  27. Lines of Code vs. Function Points vs. Use Cases for Sizing - Galorath
  28. A Comparative Study of Software Development Size Estimation ...
  29. An Amplified COCOMO-II Based Cost Estimation Model in Global Software Development Context
  30. Integrating functional metrics, COCOMO II and earned value ...
  31. [PDF] Effort Estimation of Use Cases for Incremental Large-Scale Software ...
  32. (PDF) Test effort estimation using use case points - ResearchGate
  33. 7 Software Test Estimation Techniques | BrowserStack
  34. Enhancing software development effort estimation with a cloud ...
User Avatar
No comments yet.