If you\u2019ve worked with use cases, you\u2019ve 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\u2019s 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\u2019s rate of progress.<\/p>\n
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\u2019s work as describer by Schneider and Winters (1998) and Ribu (2001).<\/p>\n
Use Case Points<\/p>\n
The number of use case points in a project is a function of the following:<\/p>\n
\u2022 the number and complexity of the use cases in the system<\/p>\n
\u2022 the number and complexity of the actors on the system<\/p>\n
\u2022 various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases<\/p>\n
\u2022 the environment in which the project will be developed (such as the language, the team\u2019s motivation, and so on)<\/p>\n
The basic formula for converting all of this into a single measure, use case points, is that we will \u201cweigh\u201d the complexity of the use cases and actors and then adjust their combined weight to reflect the influence of the nonfunctional and environmental factors.<\/p>\n
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\u2019s 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.<\/p>\n
If a project team wishes to estimate with use case points, they should write their use cases at Cockburn\u2019s user goal level. Each use case (at all levels of Cockburn\u2019s 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.<\/p>\n
In\u00a0software<\/a>\u00a0and\u00a0systems engineering<\/a>, the phrase\u00a0use case<\/b>\u00a0is a\u00a0polyseme<\/a>\u00a0with two\u00a0senses<\/a>:<\/p>\n This article discusses the latter sense.<\/p>\n A\u00a0use case<\/i>\u00a0is a list of actions or event steps typically defining the interactions between a role (known in the\u00a0Unified Modeling Language<\/a>\u00a0(UML) as an\u00a0actor<\/a><\/i>) 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\u00a0software engineering<\/a>, often representing missions or\u00a0stakeholder<\/a>\u00a0goals. The detailed requirements may then be captured in the\u00a0Systems Modeling Language<\/a>\u00a0(SysML) or as contractual statements.<\/p>\n","protected":false},"excerpt":{"rendered":"\n