Estimating With Use Case Points

If you’ve worked with use cases, you’ve probably felt there should be an easy way to estimate the overall size of a project from all the work that went into writing the use cases. There’s clearly a relationship between use cases and code in that complicated use cases generally take longer to code than simple use cases. Fortunately, there is an approach for estimating and planning with use case points. Similar in concept to function points, use case points measure the size of an application. Once we know the approximate size of an application, we can derive an expected duration for the project if we also know (or can estimate) the team’s rate of progress.

Use case points were first described by Gustav Karner, but his initial work on the subject is closely guarded by Rational Software. This article, therefore, primarily documents Karner’s work as describer by Schneider and Winters (1998) and Ribu (2001).

Use Case Points

The number of use case points in a project is a function of the following:

• the number and complexity of the use cases in the system

• the number and complexity of the actors on the system

• various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases

• the environment in which the project will be developed (such as the language, the team’s motivation, and so on)

The basic formula for converting all of this into a single measure, use case points, is that we will “weigh” the complexity of the use cases and actors and then adjust their combined weight to reflect the influence of the nonfunctional and environmental factors.

Fundamental to the use of use case points is the need for all use cases to be written at approximately the same level. Alistair Cockburn (2001) identifies five levels for use cases: very high summary, summary, user goal, subfunction, and too low. Cockburn’s very high summary and summary use cases are useful for setting the context within which lower-level use cases operate. However, they are written at too high of a level to be useful for estimating. Cockburn recommends that user goal-level use cases form the foundation of a well thought through collection of use cases. At a lower level, subfunction use cases are written to provide detail on an as-needed basis.

If a project team wishes to estimate with use case points, they should write their use cases at Cockburn’s user goal level. Each use case (at all levels of Cockburn’s hierarchy) has a goal. The goal of a user goal-level use case is a fundamental unit of business value. There are two tests for the whether a user goal use case is written at the proper level: First, the more often the user achieves the goal, the more value is delivered to the business; Second, the use case is normally completed within a single session and after the goal is achieved, the user may go on to some other activity.

Use case

In software and systems engineering, the phrase use case is a polyseme with two senses:

1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
2. A potential scenario in which a system receives an external request (such as user input) and responds to it.

This article discusses the latter sense.

A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal. The actor can be a human or other external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements.