Producing Use Cases

http://www.codeproject.com/gen/design/pusecase.asp

Introduction
The foundation of a good application begins with a good design and the foundation of a good design
begins with good use cases. Of all the artifacts produced from a software design, use cases are the most
important. Use cases capture the business process and, collectively, describe the software application’s
functionality from the user’s perspective.
This article overviews use cases and the challenges associated with them, offers tips in their creation and
suggests a structured approach to produce them.
What are Use cases?
Use cases are a necessary artifact of object-oriented application system design and development.
Actually, more than that, they provide the foundation for the design of the entire application since
application classes and their relationships emerge from the use cases.
At its simplest, a use case is simply a structured narrative of a domain process that describes the
requirements of a software system. Dr. Alistair Cockburn, one of the industry's use case Gurus describes
use cases as “sequences of interactions between the system and its external actors, related to a
particular goal.” The idea is that users (and systems) have domain goals that need the help of computer
systems to achieve them. Examples of goals are registering students, recording sales, and determining
baselines. The point is to express the requirement in a way that is simple and understandable to anyone
within the problem domain.
The vocabulary of the use case must be expressed in the terminology of the business domain.
Strictly speaking, use cases are not object-oriented artifacts and can be used with any software
development paradigm. However, they are typically associated with UML Use Case Diagrams that depict
associations (or relationships) between the actors of a system, their responsibilities (or goals) and their
boundaries. The use case diagrams provide a visual table of contents, an overview, of the system's actors
and use cases.
While UML Use Case diagrams graphically depict use cases, they do not define them.
The real value of a use case lies in its textual description, or its scenario. A scenario is a sequence of
action steps the use case takes in order to achieve its goal including any pre and post conditions. A goal
can either be successful or it can fail. The use case contains scenarios that describe the goal’s successes
and failures. A success scenario is one in which the goal is achieved, a failure scenario is one in which
the goal fails but still protects the interests of the stakeholders.
The main success scenario is the typical or normal success path.
Think of the scenario as the execution model (the object instance) of the use case. Use case scenarios,
then, provide the foundation for test cases. Additionally, scenarios provide the basis for system
documentation and User Manuals.
Use cases, are strategic goals that consist of scenarios that provide value to a business domain.
Stakeholders
A stakeholder is someone of some "thing" with a vested interest in the behavior of the system. Not all of
the stakeholders are present while the system is executing but the system must protect and satisfy the
stakeholders interests at all times. Examples of the stakeholders include company shareholders,
customers, vendors, and government regulatory and reporting agencies.
A use case describes the behavior that protects and satisfies the stakeholder’s interests.
Actors
An actor is anyone or any "thing" that interacts with the system to achieve the system’s goals: individuals,
organizations, and other computer systems. Actors are stakeholders who interact with the system.
Typically, Actors have behavior and are represented by the roles they play in the use cases; ex: Student,
Instructor, Software Developer, etc.. However, Actors are not job descriptions - ex: Programmer I,
Manager II - unless the business domain requires it.
Actors have goals that are achieved by use cases.
An Actor stimulates the system by providing input or receiving something from it. The primary actor is the
stakeholder that initiates or triggers an interaction with the system to achieve a goal. The primary actor
will be the user sitting at a computer or another computer system.
The primary actor is the one that initiates the use case's main success scenario.
Supporting actors are actors that assist the primary actor to achieve the goal. They interact with the use
case but do not trigger it. They are often external systems or third party components.
An actor can be the primary actor for one use case and the secondary actor for another.
Use case identification
Identifying use cases is not as simple as it might initially seem. Several issues need to be considered that
can be tricky and crucial to the successful modeling of the business domain. In no particular order, some
of them are:
• Finding the boundaries of the system.
• Searching for actors and their responsibilities, or goals.
• Establishing the scope and level of the use case.
• Searching for exceptional and failure situations
• Linking use cases (one use case's post-condition is another's pre-condition).
Moreover, different types of use cases exist and are described by different people in different ways.
However, most begin with high level use cases - call them System or Essential use cases - and proceed
from there to define more detailed types of use cases.
Use cases can be identified using several methods:
• Identify all the actors in the system and define their roles and responsibilities.
• Identify and partition the system into major areas of functionality.
• Identify and relate all the events in which the system needs to respond.
Regardless of the method used (or combination), the process usually starts with a brainstorming session,
at the high level, and, iteratively, drills down to the details - in other words, breadth-first. Iterations
encourage focus. Each iteration focuses on one aspect of the use case. Working too quickly and
attempting to capture too much can quickly lead to unrealistic use cases with too much complexity that
don't reflect the actual needs of the domain users.
Breadth-First approach
Using the breadth-first approach insures the entire system is covered, if only at a high level. At a
minimum, the breadth-first approach identifies all the features of the system from the requirements.
Some of the benefits are:
• Complexity is gradually developed and better understood.
• Initial use cases are developed quickly.
• Tight schedules can produce as much as needed.
• Works well with all development methodologies; eXtreme Programming, Agile, etc..
• Design is reusable and extensible; later releases will increase depth; each level is a new iteration
(or series of iterations).
So, for example, a typical iteration might look like the following:
• Iteration 1: Identify the stakeholders, the primary actors and their goals.
• Iteration 2: For each goal identified in iteration 1, define the main success scenario.
• Iteration 3: For each success scenario identified in iteration 2, define the alternate scenarios.
• Iteration 4: For each scenario identified in iteration 3, define the exception conditions.

In Figure 1, the iterations proceed from the right and move down. As they do, problems will surface that
provide the motivation to forming new use cases, linking existing use cases, and discarding and
combining use cases. In this sense, use cases are refactored during each iteration.
Problems in the early iterations are good and to be expected, but, as the iterations continue, beware of
the becoming too focused on the implementation. Use case names that begin with, "Perform..." or
"Process..." indicate the use case was written from an implementation perspective rather than from a
domain user Perspective.
Use cases are not function calls.
Domain charts
As the use cases are identified, related use cases will emerge. In the Model Driven Architecture
approach, related use cases are grouped together into application domains from which a Domain Chart is
developed. Domains are autonomous entities logically grouped by their function. Domain charts depict the
system as distinct, independent domains that work together to provide the application’s functionality.
In Figure 2, related use cases for a Book store have been grouped together that shows, at a glance, the
major domains in the application. Each domain contains subsystems that implement the domains
functionality.
Domain Charts encourage parallel design and development.
Validation
Validation determines the credibility of the use cases and it critical to capture the business process. As the
use cases are refactored, ask the following questions:
• Does the use case capture the business process?
• Are there any details that need to be added?
• Will the actor's goal be met?
• Can the use case be simplified?
• Are there any additional goals that are not addressed?
• Are there any additional actors that are not represented (directly or indirectly)?
Use Case formats
Many use case formats exist and some provide more content than others. There is no single use case
format that exists for all projects. Some projects follow a lightweight development methodology that
requires less documentation, perhaps because of a tight schedule, other projects are heavyweight and
require more documentation, perhaps for mission critical projects.
In Writing Effective Use Cases, Dr. Cockburn describes the following formats:
• Fully Dressed: The most elaborate. This template describes the actors, stakeholders, protection
of stakeholder’s interests, performance issues, pre- and post conditions, exceptions, notes and
annotations. Used when formal and complete documentation is required.
• Casual: Written in paragraph style, a few paragraphs at most. Less formal and contains less
content than the fully dressed format.
• Brief: One paragraph that summarizes the business process. It mentions only the significant
steps in the main success and failure scenarios.
Additionally, two other formats can be considered:
• Normal: This would be the normal methodology that specifies and defines the design model in
more detail than the casual format, but still less than the fully dressed format. Design reviews
would be tighter and less forgiving than the Agile approach (below) and more precision and rigor
would be applied.
• Agile: Projects using this format would practice an Agile Modeling and Development methodology
to produce the software very quickly but still contain an acceptable design. The UML artifacts,
while complete, would contain less detail than for the normal development methodology and
would be oriented more towards the higher level perspective. Smaller projects or projects with
tight deadlines might fall within this scenario.
Choose the format that best fits the project.
Modeling Create, Read, Update, Delete (CRUD)
Ideally, CRUD functionality is expressed in terms of a business process - the action the user performs.
The semantics in use cases are extremely important and should be expressed in the language of the user
– not in the language of the developer, the functionality of the system or in database modeling terms.
Good design perceives the system from the user perspective.
The problem with CRUD use cases is that they describe the technical implementation without explaining
how this is valuable to the user. At best, it is a low level goal that is fulfilled within the context of the use
case scenario.
Consider the use cases for a Word Processor. Which states the business case best: Create Style, Update
Style, Import Style, Delete Style, or Insure Consistent Formatting within a Document? The latter
expresses the goal of the user best. While Create Style, Update Style, Import Style, and Delete Style
reflect the functions that occur within the business domain, they don’t express the user’s goal to format
her document. Instead the goal has been decomposed into discrete functionality.
Resist the tendency to decompose use cases into functions.
Or, consider another example. For security purposes, its typical for users to login to an application.
However, logging in is not a business goal of the user. In other words, the user of say, an inventory
system, doesn’t say to herself, “Today, my goal is to login and logout of the inventory system in the most
efficient manner possible.” Moreover, the user isn’t evaluated by how well she logs into the system. She
won’t get a raise for logging in 45 times in a single day.
Rather than including CRUD and ancillary functionality (like Login) with the business use cases, separate
them into system use cases that separately exist at a level of detail lower than the business use cases.
State the system process in technical terms.
Its natural for developers to think in terms of implementation. Yet, this tendency needs to be resisted and
continually guarded against for the business use cases. Moreover, developers should not force users to
adopt implementation language. Its the developers who need to adopt the user’s language, not the other
way around.
State the business process in terms of the user.
Producing Use Cases
The following steps suggest a structured outline to produce use cases. They are meant to be followed in a
group session and attended by the members of the development team - and customer representatives, if
possible. The design session atmosphere is open and relaxed and discussion, even vigorous, is
encouraged. Ideally, the session facilitator is experienced in summarizing and clarifying the ideas
presented by the group into coherent statements.
Materials needed: Markers, whiteboard (for brainstorming), flipcharts
Note: The steps assume the requirements have already been collected.
1. Produce an initial Actor-Goal list from the requirements.
The Actor-Goal list describes the behavior of the application at the highest level. Still, each
primary actor has been identified and associated with its goals. The goals will eventually result in
use cases.
o Identify the stakeholders and their interests.
o From the stakeholders, identify and list primary actors. If necessary, begin with brief
narrative to identity initial actors and goals.
o For each actor, identify goals, refactoring as necessary.
2. Verify Actor-Goal list and produce project narrative.
o In group discussion, slowly step through a narrative, capturing the essential steps in
written form on a whiteboard.
o Referring to the narrative, insure that the Actor-Goal list captures the narrative’s. All of the
actors and their goals should be evident in the narrative. If not, refactor the Actor-Goal list
as necessary.
o When finished, each team member should understand and be able to repeat the narrative

This step will produce two artifacts:

o A verified Actor-Goal list that captures the behavior of the system and protects the
interests of the stakeholders.
o A detailed project narrative that identifies all the project stakeholders and their interests.
The narrative serves as great project documentation and helps to insure the use cases
 will protect the interests of the stakeholders. It also insures that all developers share a
common understanding of the project since all developers participated in the narrative.

Note: If the narrative has already been produced prior to step 2, revisit it with the entire group.
Undoubtedly, it will change and improve as questions and critiques arise.

3. Iteratively, produce the initial Use case briefs.

Focus on the primary actors and their main success scenarios in the first iteration. In later
iterations, add the detail necessary for the desired use case format.

Select the Actor-Goal from the verified Actor-Goal list that significantly influences the core
o
architecture.
o Express the goal in terms of the business process; address the user's need, not the
implementation of it.
o Avoid CRUD terminology. The use case must be expressed in the business vocabulary -
it should make sense to the business user. For example, instead of "Create Student",
perhaps, "Register Student to a Class" is more appropriate. CRUD Use case are more
appropriate as "system" Use Cases...not "user" use cases.
o Avoid determining Use cases by functionality.
4. Produce Domain chart
o Partition Use cases into related, autonomous domains.
o Consider that each domain can be designed and even implemented independently.

Conclusion
Use cases are the first step towards designing and ultimately delivering quality software that works the
way the user desires. Since use cases capture the business requirements from the user perspective, no
other design activity has a larger return on investment. Similar to the specifications for a house, use cases
provide the specifications for software applications. From these specifications, design artifacts are
produced that are used in the construction of the system. Ultimately, application design, construction and
user acceptance of the software rests on solid use cases. Don’t neglect this essential step in the lifecycle
of the software application.

Project Estimation with Use Case Points

http://www.codeproject.com/gen/design/usecasep.asp

Introduction
Object-oriented applications frequently rely on Use Cases to describe the business processes of a
software application. Since use cases consist of the strategic goals and scenarios that provide value to a
business domain, they can also provide insight into an application’s complexity. Deriving a reliable
estimate of the size and effort an application needs, is possible by examining the actors and scenarios of
a use case. Use Case Points is a project estimation method that employs a project’s use cases to
produce an accurate estimate of a project’s size and effort.
Use Case Points
Use case modeling is an accepted and widespread technique to capture the business processes and
requirements of a software application. Since they provide the functional scope of the application,
analyzing their contents provides valuable insight into the effort and size needed to design and implement
the application. In general, applications with large, complicated use cases take more effort to design and
implement than small applications with less complicated use cases. Moreover, the time to complete the
application is affected by:
• The number of steps to complete the use case.
 • The number and complexity of the actors.
• The technical requirements of the use case such as concurrency, security and performance.
• Various environmental factors such as the development teams’ experience and knowledge.
Use Case Points (UCP) is an estimation method that provides the ability to estimate an application’s size
and effort from its use cases. Based on work by Gustav Karner in 1993, UCP analyzes the use case
actors, scenarios and various technical and environmental factors and abstracts them into an equation.
The equation is composed of four variables:

1. Technical Complexity Factor (TCF).

2. Environment Complexity Factor (ECF).
3. Unadjusted Use Case Points (UUCP).
4. Productivity Factor (PF).

Each variable is defined and computed separately, using perceived values and various constants. The
complete equation is:
UCP = TCP * ECF * UUCP * PF
The necessary steps to generate the estimate based on the UCP method are:

1. Determine and compute the Technical Factors.

2. Determine and compute the Environmental Factors.
3. Compute the Unadjusted Use Case Points.
4. Determine the Productivity Factor.
5. Compute the product of the variables.

Technical Complexity Factors

Thirteen standard technical factors exist to estimate the impact on productivity that various technical
issues have on an application. Each factor is weighted according to its relative impact. A weight of 0
indicates the factor is irrelevant and the value 5 means that the factor has the most impact.

Technical Factor Description Weight

T1 Distributed system 2
T2 Performance 1
T3 End User Efficiency 1
T4 Complex internal 1
Processing
T5 Reusability 1
T6 Easy to install 0.5
T7 Easy to use 0.5
T8 Portable 2
T9 Easy to change 1
T10 Concurrent 1
T11 Special security features 1
T12 Provides direct access for 1
third parties
T13 Special user training 1
facilities are required
Figure 1: Technical Factors.
For each project, the technical factors are evaluated by the development team and assigned a value from
0 to 5 according to their perceived complexity – multithreaded apps. require more skill and time than
single threaded applications, for example, as do reusable apps. A perceived complexity of 0 means the
technical factor is irrelevant for this project; 3 is average; 5 means it has strong influence.
Each factor’s weight is multiplied by its perceived complexity to produce its calculated factor. The
calculated factors are summed to produce the Total Factor.
So, using sample perceived complexity values, the Technical Total Factor might be computed as follows:

Technical Description Weight Perceived Calculated Factor

Factor Complexity (weight*perceived
complexity)>
T1 Distributed System 2 5 10
T2 Performance 1 4 4
T3 End User Efficiency 1 2 2
T4 Complex internal Processing 1 4 4
T5 Reusability 1 2 2
T6 Easy to install 0.5 5 2
T7 Easy to use 0.5 3 2
T8 Portable 2 3 6
T9 Easy to change 1 3 3
T10 Concurrent 1 2 2
T11 Special security features 1 2 2
T12 Provides direct access for third 1 5 5
parties
T13 Special user training facilities 1 3 3
are required
Total Factor 47
Figure 2: Calculating the Technical Total Factor.
In Figure 2, the Total Factor is 47 derived by summing all the calculated factors. To produce the final TCF,
two constants are computed with the Total Factor. The complete formula to compute the TCF is as
follows:
TCF = 0.6 + (.01*Total Factor). For Figure 1, the TCF = 1.07
Environmental Complexity Factors
Environmental Complexity estimates the impact on productivity that various environmental factors have
on an application. Each environmental factor is evaluated and weighted according to its perceived impact
and assigned a value between 0 and 5. A rating of 0 means the environmental factor is irrelevant for this
project; 3 is average; 5 means it has strong influence.

Environmental Description Weight

Factor
E1 Familiarity with UML 1.5
E2 Application Experience 0.5
E3 Object Oriented Experience 1
E4 Lead analyst capability 0.5
E5 Motivation 1
E6 Stable Requirements 2
E7 Part-time workers -1
E8 Difficult Programming language 2
Figure 3: Example Environmental Factors.
Each factor’s weight is multiplied by its perceived complexity to produce its calculated factor. The
calculated factors are summed to produce the Total Factor.
Using sample values for perceived impact, the Environmental Total Factor might be computed as:

Environmental Description Weight Perceived Calculated Factor

Factor Impact
(weight*perceived
complexity)
E1 Familiarity with UML 1.5 4 6
E2 Application Experience 0.5 2 1
E3 Object Oriented Experience 1 5 5
E4 Lead analyst capability 0.5 2 1
E5 Motivation 1 1 1
E6 Stable Requirements 2 5 10
E7 Part-time workers -1 0 0
E8 Difficult Programming language 2 1 2
Total Factor 26
Figure 4: Calculating the Environmental Total Factor.
In Figure 4, the Total Factor is 26 derived by summing all the calculated factors. To produce the final ECF,
two constants are computed with the Total Factor. The complete formula to compute the ECF is as
follows:
ECF = 1.4 + (-0.03*Total Factor). For Figure 4, the ECF = 0.62
Unadjusted Use Case Points (UUCP)
Unadjusted Use Case Points are computed based on two computations:

1. The Unadjusted Use Case Weight (UUCW) based on the total number of activities (or steps)
contained in all the use case Scenarios.
2. The Unadjusted Actor Weight (UAW) based on the combined complexity of all the use cases
Actors.

UUCW
Individual use cases are categorized as Simple, Average or Complex, and weighted depending on the
number of steps they contain - including alternative flows.

Use Case Type Description Weight

Simple A simple user interface and touches only a single 5
database entity; its success scenario has 3 steps
or less; its implementation involves less than 5
classes.
Average More interface design and touches 2 or more 10
database entities; between 4 to 7 steps; its
implementation involves between 5 to 10 classes.
Complex Involves a complex user interface or processing 15
and touches 3 or more database entities; over
seven steps; its implementation involves more
than 10 classes.
Figure 5: Use Case Categories.
The UUCW is computed by counting the number of use cases in each category, multiplying each category
of use case with its weight and adding the products.

Use Case Type Description Weight Number of Use Result

Cases
Simple A simple user interface and touches only 5 8 40
a single database entity; its success
scenario has 3 steps or less; its
implementation involves less than 5
classes.
Average More interface design and touches 2 or 10 12 120
more database entities; between 4 to 7
steps; its implementation involves
between 5 to 10 classes.
Complex Involves a complex user interface or 15 4 60
processing and touches 3 or more
database entities; over seven steps; its
implementation involves more than 10
classes.
Total UUCW 220
Figure 6: Computing UUCW.

UAW
In a similar manner, the Actors are classified as Simple, Average or Complex based on their interactions.

Actor Type Description Weight

Simple The Actor represents another 1
system with a defined API.
Average The Actor represents another 2
system interacting through a
protocol, like TCP/IP.
Complex The Actor is a person interacting via 3
an interface.
Figure 7: Actor Classifications.
The UAW is calculated by counting the number of actors in each category, multiplying each total by its
specified weighting factor, and then adding the products.

Actor Type Description Weight Number of Actors Result

Simple The Actor represents another 1 8 8
system with a defined API
Average The Actor represents another 2 12 24
system interacting through a
protocol, like TCP/IP
Complex The Actor is a person 3 4 12
interacting via an interface.
 Total UAW 44
Figure 8: Computing UAW.
Finally, the UUCP is computed by adding the UUCW and the UAW. For the sample data used in the
figures, the UUCP = 220 + 44 = 264.
Productivity Factor
The Productivity Factor (PF) is a ratio of the number of man hours per use case point based on past
projects. If no historical data has been collected, a figure between 15 and 30 is suggested by industry
experts. A typical value is 20.
Final Calculation
The Use Case Points is determined by multiplying all the variables:
UCP = TCP * ECF * UUCP * PF
For the sample values used in this article:
UCP = 1.07 * 0.62 * 264 * 20 = 3502.752 or 3503 hours.
Dividing the UCP by 40 hours (for one man work week) = 88 man-weeks. Therefore, for the sample
values in this article, it would take one developer 88 weeks (or about 22 months) to complete the
application.
Caveats
The Use Case Points estimate tends to be high when compared to human experts. This might be a good
thing since many software projects are late, but, the estimate may still be too high. In order to produce
accurate results, the variables in the equation need to be adjusted and tweaked – especially in the
beginning.
• The number of steps in a scenario affects the estimate. A large number of steps in a use case
scenario will bias the result towards complexity and increase the Use Case Points. A small
number of steps will bias it towards simplicity. Sometimes, groups of steps can be reduced to a
fewer number without sacrificing the business process. Strive for a uniform level of detail but don’t
force a use case to conform to the estimation method.
• Including and extending use cases increases the complexity. Count these as a single use case.
• The number of actors in a use case also affects the estimate. If possible, generalize the actors
into a single superactor. This reduces the complexity without affecting the use case. On the other
hand, don’t force a generalization where none exists.
• The values for the Technical and Environmental Factors need to be adjusted over time as actual
data is obtained. The more projects that employ Use Case Points for their estimations will yield
more accurate values for the perceived values.
• Compare the Use Case Point estimate with a human expert’s estimate. Where there is
disagreement, err on the side of the human expert and adjust the Use Case Point factors
accordingly.
• The Productivity Factor can only be obtained over time. Track the time spent designing and
implementing the use cases and adjust the Productivity Factor accordingly.
Conclusion
Use Case Points have the potential to produce reliable results because its estimates are produced from
the actual business processes – the use cases - of a software application. Additionally, in many traditional
estimation methods, influential technical and environmental factors are often not adequately given enough
consideration. Use Case Points includes and abstracts these subjective factors into an equation. When
tweaked, over time, Use Case Points can provide estimates that are very reliable.

How to Prepare Quotation Using Use Case Points

http://www.codeproject.com/gen/design/usecasepoints.asp
Introduction
"You can not plan if you can not measure, and if you fail to plan, you have planned to fail."
Quotation: It's a financial document send from supplier to customer regarding service to be provided. It's
also called as temporary financial document for negotiations. "A statement of price, terms of sale, and
description of goods or services offered by a supplier to a prospective purchaser, a bid. When given in
response to an inquiry, a quotation often is considered an offer to sell."
Definition reference from here.
Quotation is one of the important aspects of software cycle. Any prediction less or more will affect the
project a lot. Let's look at how basically day to day businesses manage their ways of handling quotations.
“Mr. Harry gets a contract of delivering 10 tons of steel from place “X” to place “Y”. He has 2 trucks, each
can carry 5 tons each. Place “X” and place “Y” are 1 KM (Kilometer) apart.”
So, here’s Harry’s calculations on experience basis. One truck if delivering 5 tons for 1 KM is 500$. So for
two trucks, it is 1000$. So the quotation is 1000$. Just wondering, can we do that with software industry.
There are 100 modules, and the company has 5 programmers. Every programmer can complete 20
modules in 3 months. A programmer's salary is 1000$. So, 5 X 1000 X 3 = 15000$. The truck quotation
calculation is more confident than software quotation, why?
In trucks' quotation, Harry had followed the following process:
• Harry had measurement of his work: 10 tons to be delivered. 1 KM to be traveled.
• Harry knew what effort will be required: 5 tons/per truck/per KM.
• So the quotation: 1000$.
So basically, Harry had measurement of his work. He knew the volume of what he has to deliver. That’s a
problem with software industry. As software industry output is more in to logical output, it's difficult to
measure linearly the effort required to complete a project and hence the quotation. Software industry has
been struggling for the past 40 years to come to a standard of measurement, and that’s where all the
mess is. Many ideas and measurement methodologies have been proposed by researchers. Each have
there own advantages and disadvantages. Here are some of the measurement methodologies used:
• McCabe’s Measurement of complexity.
• Henry and Kafura’s Information Flow.
• Halstead measurement of complexity.
• Lines of Code (LOC).
• Function Points. (My old tutorial on function points.)
• Use Case Points.
Do not be tensed by some unheard technology described above, it's only provided for knowledge base.
Links are provided for McCabe's complexity, Henry and Kafura's information flow, Halstead measurement
complexity and LOC. I have just mentioned them as they are old measurement technologies. If any one
wants to explore them, see my References section. This tutorial will look into Use Case Points
methodology, its advantages and disadvantages. So in this article, we will basically go through Use Case
Point theory, and then take up a practical example of a Use Case, and prepare a quotation according to it.
Acronyms and Abbreviation:
Note: have these acronyms in hand always as they are used throughout the tutorial. Do not be tensed by
the acronyms below. They are for reference sake, and as you proceed ahead with the tutorial, you will
have a more clear picture of what exactly they are.

Table 1.0
Acronym Full form Definition
Use Case Points method is a software sizing and estimation
UCP Use Case Point
based on Use Case document.
 A numeric sum of value of actors after giving the classification
Unadjusted Actor and before multiplying the technical complexity factor of the
UAW
Weights system. (When you go through steps of how to calculate UAW,
this will be more clear.)
A numeric sum of value of Use Cases after classifying and
Unadjusted Use before multiplying the technical complexity factor of the system.
UUCW
case Weight (When you go through steps of how to calculate UUCW, this will
be more clear.)
Unadjusted Use
UUCP Sum of UAW and UUCW
Case Points
Application
Application programs used for accessing services provided by
API Programming
some lower-level module (such as operating system).
Interface
Graphical User A computer terminal interface, such as Windows, that is based
GUI
Interface on graphics instead of text.
Use Case It's an atomic set of activities that are either performed entirely
Transactions or not at all.
Total of all technical factors. See for more details in Steps in
Tfactor Technical Factor
estimation. See table 4.0 for more details.
Factor which defines the complexity of the project. For more
Technical
TCF details, see steps for UCP estimation. TCF is calculated from
Complexity Factor
Tfactor.
EF Environment Factor This is multiplying factor.
Adjusted Use Case This is the value obtained after multiplying with Efactor and
AUCP
Points Tfactor.
Lines of code is a counting metrics to measure the volume of a
LOC Lines of Code
software product.
A programming technology in which program components are
Object Oriented
OOP put together from reusable building blocks known as objects.
Programming
[Glossary]
Stands for Unified Modeling Language. UML is a standard
notation and modeling technique for analyzing real-world
objects, developing systems, and designing software modules in
Unified Modeling
UML an object-oriented approach. UML has been fostered and now is
Language
accepted as a standard by the group for creating standard
architecture for object technology, OMG (Object Management
Group). [Definition taken from here]
Unadjusted Use
UUCFP Details are provided in this article.
Case Flow Points
A sizing methodology for software projects based on functions of
FP Function Points
the software.
Assumptions:

1. Readers have basic knowledge of how to write Use Cases. This tutorial does not cover Use
Cases and is only limited to estimation by "Use Cases". So if you are reading this article with out
a clear concept of Actor, Role, Scenarios, it's better not to read.
2. Use Case structure varies from organization to organization which can seriously impact the
estimation. This tutorial has used Alistair Cockburn's template from Writing Effective Use Cases
(**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans and technology.
Scope
This tutorial is only till understanding Use Case points and does not get in to details of how to write Use
Cases. This article will not concentrate on how to write Use Cases. There are lots of tutorials on the
Internet. And also in the References section of this article, a list is provided.
History and Definition of Use Case Points
Working in Ericsson in the late 1960s, Ivar Jacobson devised Use-Case Documents. Thanks to Ivar
Jacobson to come out with such a wonderful way of communication by using Use Case Documents.
Later, Use Case Documents became a subset of UML. In 1994, Alistair Cockburn constructed the 'Actors
and Goals conceptual model' while writing Use Case guides for the IBM Consulting Group. It provided
guidance as to how to structure and write Use Cases. It’s the document which can stand not only for
programmer or architect, but also for the stake holders. It's a document which stands between the
Customer and Programmers/Architects/Business analysts/etc. It also serves as handover when any new
programmer comes in the project. Use Case Document also serves as a valuable input to the design of
software. In short, it serves in the whole life cycle of software development. Karner identified that this
document can also be used to measure and estimate effort. This tutorial will make a walk through of
Karner's work and give one simple example. So, let’s start with the definition.
Use Case Point is software sizing and measurement based on Use Case Document. "Use Case Point" is
based on work by Gustav Karner in 1993. It was written as a diploma thesis at the University of Linkoping.
This work is a modification of work by Allen Albrecht on function points.
Steps for UCP (Use Case Points) Estimation

1. Determine the UAW (Unadjusted Actor weight): The first step is to classify all the actors in to the
following classification. Table 2.0 will give you a clear idea of how to classify the actors. Second
column is the litmus test for making a decision of which type of actor falls in which category. The
last column provides the factor of complexity:

Table 2.0
Classification Litmus test to recognize classifications Value/Factor
Simple actors Simple actors are those which communicate to 1
system through API.
Average actors Average actors are recognized if they have the 2
following properties:

o Actors who are interacting with the system

through some protocol (HTTP, FTP, or
probably some user defined protocol).

o Actors which are data stores (Files,

RDBMS).
Complex Complex actor is interacting normally through GUI. 3
2. Determine number of UUCW (Unadjusted Use case Weight): The second step is to count Use
Cases and assign weights depending on number of scenarios and number of transactions.
Table 3.0
Use Case
Litmus test to decide the Classification Value/Factor
Type
Simple Greater than or equal to 3 transactions 5
Average Between 4 to 7 transactions 10
 Complex Greater than 7 transactions 15
3. Determine Total UUCP (Unadjusted Use Case Point): Total UUCP = Total UAW + Total UUCW.
4. Computing technical and environmental factor: Final step is to take into account the technical
complexity. All technical factors will be assigned a value from 0 to 5 depending on complexity.
Table 4.0
Technical factor Weight Description
t1 Distributed 2 Is the system having distributed architecture or
System centralized architecture?
Does the client need the system to fast? Is time
t2 Response time 1
response one of the important criteria?
End user
t3 1 How's the end user's efficiency?
efficiency
Is the business process very complex? Like
Complex internal
t4 1 complicated accounts closing, inventory tracking,
processing
heavy tax calculation etc.
Do we intend to keep the reusability high? So will
t5 Reusable code 1
increase the design complexity.
Is client looking for installation ease? By default, we
get many installers which create packages. But the
client might be looking for some custom installation,
probably depending on modules. One of our client
t6 Installation ease 0.5 has a requirement that when the client wants to
install, he can choose which modules he can install.
Is the requirement such that when there is a new
version there should be auto installation? These
factors will count when assigning value to this factor.
t7 Easy use 0.5 Is user friendliness a top priority?
Is the customer also looking for cross platform
t8 Portable 2
implementation?
Is the customer looking for high customization in the
t9 Easy to change 1 future? That also increases the architecture design
complexity and hence this factor.
Is the customer looking at large number of users
t10 Concurrent 1 working with locking support? This will increase the
architecture complexity and hence this value.
Is the customer looking at having heavy security like
t11 Security objectives 1 SSL? Or do we have to write custom code logic for
encryption?
Does the project depend in using third party
controls? For understanding the third-party controls
Direct access to
t12 1 and studying its pros and cons, considerable effort
third parties
will be required. So, this factor should be rated
accordingly.
Will the software from user perspective be so
User training
t13 1
complex that separate training has to be provided?
facilities
So this factor will vary accordingly.
5. Equation for Tfactor = sum(T1....T13)
6. TCF (Technical Complexity Factor): TCF = 0.6 + (0.01 * Tfactor).
7. EF (Environmental Factor): There are other factors like trained staff, motivation of programmers
etc. which have quiet a decent impact on the cost estimate.
 Table 5.0
Environmental
Weight Description
Factor
e1 Familiarity with 1.5 1.5
project
Are all the people working in the project familiar with
domain and technical details of the project? Probably
you will spend most of your time in explaining them
all know-how's.
e2 Application 0.5 How much is the application experience?
experience
e3 Object-oriented 1 As use-case documents are inputs to object oriented
programming design, it's important that people on the project
experience should have basic knowledge of OOP concepts.
e4 Lead analyst 0.5 How is the analyst who is leading the project? Does
capability he have enough knowledge of the domain?.
e5 Motivation 1 Are the programmers motivated for working on the
project? Instability in the project will always lead to
people leaving half way through their source code.
And the hand over becomes really tough. This factor
you can put according to how software industry is
going on? Example, if the software market is very
good, put this at maximum value. More good the
market, more the jobs and more the programmers
will jump.
e6 Stable 2 Is the client clear of what he wants? I have seen
requirements clients' expectations are the most important factor in
the stability of requirements. If the client is of highly
changing nature, put this value to maximum.
e7 Part-time Staff -1 Are there part-time staff in projects, like consultants
etc.?
e8 Difficult -1 How much is the language complexity, Assembly, VB
programming 6.0, C++, C etc.
language

8. Efactor = SUM(e1...e8).
9. Calculating Environmental Factor = EF = 1.4 + (-0.03 * Efactor).
10. AUCP (Adjusted Use Case Points). Finally, calculating the Adjusted Use case points: AUCP =
UUCP * TCF * EF
11. Multiplying by Man/Hours Factor: AUCP * Person/Hours/AUCP.

Karner[13] proposed a factor of 20 staff hours per Use Case point for a project estimate. While
Sharks states that field experience has shown that effort can range from 15 to 30 hours per Use
Case point.

Schneider and Winters proposed number of staff hours per Use Case point depends on the
environmental factors. The number of factors in E1 through E6 that are below 3 are counted and
added to the number of factors in E7 through E8 that are above 3. If the total is 2 or less, the
general idea is to use twenty staff hours per UCP; if the total is 3 or 4, use twenty-eight staff hours
per UCP. If the number exceeds 5, it is usually recommended that changes should be made to
 the project so the number can be adjusted, because in this case, the risk is unacceptably high.
Another possibility is to increase the number of staff hours to thirty-six per Use Case points.

Sample project scope (Sample Data Entry Project):

Let's start with a sample fiction project. Here's the scope of the project. TNC company till now was using
manual way of maintaining its customer database and there credit card information. Data entry operator
manually validates credit card information from external payment gateway. They maintain customer code,
customer name, customer address, customer phone and validated customer credit card information in
Customer registry. Customer code is unique for a customer. So, TNC manually checks for the validations
and enters in the customer registry. TNC wants the data entry project to be automated. TNC is looking for
the following automation:
• Customer code assigned should be checked for uniqueness automatically.
• Customer code should not exceed 8 length.
• Credit card validation should be automatic for the current system. TNC has already given the API
documentation of how to interact with the third party payment system.
• Credit card length should not exceed more than 10 length.
• Data entry operator should be able to add/update/delete customer information.
• The database will be in the TNC head office and only data entry operators will be allowed to use
the data entry software.
• Software should work on Windows platform. At this moment, TNC has Windows 2000 client
installed in all computers.
Writing Use Case for Sample Data Entry Project:
I have used Alistair Cockburn's template for the "Use Case point" example. Use Case template varies
from person to person, project to project, and organization to organization. I found Alistair's template to be
complete, so just took it. But there's no hard and fast rule that you have to follow this template. What will
matter is what steps you write in the Use Case.
Use Case Transactions: It’s an atomic set of activities that are either performed entirely or not all. What is
a Use Case transaction and what’s not: just see if the transaction is adding any business value or else do
not include it as a transaction. Example: the user switches on the computer, user clicks on add button or
any GUI, are not valid business transaction steps. But the customer code validated for credit card
information is a valid business transaction. Use Case points are heavily affected by the way the Actors
and their transactions are identified. So a Use Case Document should be written by predefined
guidelines, uniformly in a project. Just take a meeting with the whole project team before starting writing
Use Cases. The depth of the Use Case Document will affect estimation by 40%.

Table 6.0
Use Case # DATAENTRYPROJECTCUST-1009
Use Case name Maintain Customer

Description This Use Case depicts full maintenance of customer from project "Data
Entry".
Scope and level • Data Entry System (Internal)

• Credit Card System (External)

Level
Primary and secondary actors
Stakeholders and interests
User Goal Level (If this property is not understood, look at the reference for
the book Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair
Cockburn Humans and technology)
Data Entry operator.
Trigger Data entry operator clicks on menu: "Add New Customer"
Preconditions • Data entry operator should be logged in.

• Data entry operator should have access to Internet.

Assumptions Customer information received is entered manually. No automated import
routine is in the scope.
Failed End condition • Customer is not added to database and appropriate error message
is displayed.
• Customer code already existing in the customer database.
• Customer code length limit is exceeded.
• Customer credit card limit is exceeded.

• Customer credit card validation failed with the payment gateway.

Action Add new customer
Main success scenario (or 1. Data entry operator receives customer information.
basic Flow): 2. Data entry operator enters following information:
o Customer code
o Customer name
o Customer address
o Customer phone
3. Customer code is checked if it exists in Customer table.
o If the customer code is existing then "Duplicate Customer
Code" error is raised.
o If the customer code is more than 8 length, then
"Customer code length limit crossed" error is raised.
4. After step 3 is passed OK. Data entry operator enters credit card
information. If the credit card length is more than 10 length, then
"Credit card length limit crossed" error is raised.
5. Credit card information is send to the external payment gateway.
Appropriate APIs of the external payment gateway will be used for
validity.
6. External payment gateway returns "OK" if credit card is validated
or else will return "NOT VALID" flag.

7. Data entry operator then adds the customer in database.

Alternate scenario Update Existing Customer
(Extensions):
1. Data entry operator enters customer code to retrieve the customer
who has to be updated.
2. Data entry operator makes appropriate changes to the customer
information. All steps and business validation from 1 to 6 of Add
new Customer is repeated.

3. Data Entry operator updates the customer information.

Alternate scenario Delete Existing Customer
(Extensions):
1. Data entry operator enters customer code to retrieve the customer
who has to be deleted.
2. Data entry operator deletes the customer. Data entry operator is
alerted "Are you sure you want to delete the Customer?”
 o If the data entry operator clicks "Yes", then the customer is
deleted from the database.

o If the data entry operator clicks "NO", no action is taken.

Success Guarantee (Post • Customer is added to Customer database.
conditions): • Customer is updated to Customer database.

• Customer is deleted from Customer database.

Special Requirements
(including business rules):
Technology and Data Variations If credit card payment gateway API changes, the interaction of the data
List: entry customer module will have to be changed accordingly.
Frequency of occurrence:
Notes and Open Issues:
Applying Use Case Points:
Let's start applying Use Case Points to the above given document.
• Determining Unadjusted Use Actor Weights (UAW): In this project, we have identified only one
actor “Data Entry Operator”. The upper Actor (data entry operator) is complex as data entry
operator will be interacting through GUI. So UAW=3 as per Table:2.0.
• Determine number of UUCW (Unadjusted Use case Weight): There are 12 transactions [Adding
also the alternative flows] in Table 6.0 Use Case. So the above Use Case is complex according to
Table:3.0. So referring Table:3.0, UUCW=15.
• Now calculating the total UUCP = 15 + 3 = 18.
• Determining the technical factor
Table 7.0
Weighted
Technical factor Weight Value Explanation
Value
t1 Distributed System 2 1 2 Simple two tier architecture is
decided.
t2 Response time 1 4 4 Speed is of importance as the data
entry operator has to enter data
quiet fast.
t3 End user efficiency 1 3 3 Data entry operator has high user
efficiency.
t4 Complex Internal 1 2 2 Its simple entry screen and no
Processing business process has been scoped
by the client. Only credit card check
and duplicate customer code is the
business check.
t5 Reusable Code 1 1 1 No reusability as project is small
and customer is not looking for any
further changes for at least two
years.
t6 Installation Ease 0.5 0 0 TNC has good in house
development team, and installation
problems will be handled by them.
Technology thought is C#, and .NET
 setup wizard will be enough to
make the installation process easy.
t7 Easy use 0.5 4 2 Yes, data entry operator has to
have user friendly menus and
shortcut keys for fast entry of data.
t8 Portable 2 1 2 TNC has Windows 2000 client as
specified in the scope document.
t9 Easy to change 1 0 0 None specified by client.
t10 Concurrent 1 0 0 Client has not clarified about this
issue as such in the scope
document. So assumed least
concurrent.
t11 Security objectives 1 0 0 None specified by client. Even
credit card information will be
passed with out encryption.
t12 Direct access to third 1 3 3 Using the credit card check API.
parties
t13 User training facilities 1 0 0 The screen is simple, and data
entry operator can operate without
any training.
Total 19
• Depending on the table, calculating the Technical Factor: TCF = 0.6 + (0.01 * Tfactor) = 0.6 +
(0.01 * 19) = 0.79
• Calculating environmental factor
Table 8.0
Environmental Weighted
Value Weight Explanation for the value assigned
Factor Columns
e1 Familiarity with 5 1.5 7.5 It’s a simple project, so familiarity with project
project is not so much needed.
e2 Application 5 0.5 2.5 It's a simple application.
experience
e3 Object-oriented 5 1 5 Every one has good OOP knowledge.
programming
experience
e4 Lead analyst 5 0.5 2.5 It's a simple project; no lead analyst needed
capability till now.
e5 Motivation 1 1 1 Motivation is little down as programmers are
reluctant to work on the project because of its
simplicity.
e6 Stable 4 2 8 Client is very clear with what he wants?
requirements
e7 Part-time Staff 0 -1 0 No part time staff.
e8 Difficult 3 -1 -3 C# will be used. And most of the programming
programming guys are new to C# and .NET technology.
language.
• According to [Kirsten Ribu Master of Science Thesis], Environmental factor plays a very important
role in the estimation. A slight variation will increase the Use Case point by a very, very drastic
amount. Even small adjustments of an environmental factor, for instance by half a point, can
 make a great difference to the estimate. Difference of 3 to 2.5 increased the estimate by 4580
hours, from 10831 to 15411 hours, or 42.3 percent. This means that if the values for the
environmental factors are not set correctly, there may be disastrous results -- Sources [Kirsten
Ribu Master of Science Thesis]. Do see links below.
• Using formulae for calculating EF = 1.4 + (-0.03 * Efactor) = 1.4 + (-0.03 * 23.5) = 0.695.
• Calculating AUCP = UUCP * TCF * EF = 18 X 0.79 X 0.695 = 9.88 approx = 10 Use Case Points.
I have done the approximation as its only creates 3 to 4 hours of difference.
• Calculating according to Karner, i.e., 20 staff hours per Use Case points = 10 X 20 = 200 hours
for the total project.
• If programmer works for 8 hours for a day, then 340/8 = 25 days.
• Calculating according to Schneider and Winters, from e1 to e6 there are only 3 properties that are
below 3. And from e7 to e8, there are none whose value is above 3. So the total is 3. We use 28
staff hours. 10 X 28 = 280 hours. If programmer works for 8 hours, then 35 days. If this step is not
understood, look at the steps defined in theory of Use Case points.
• If we apply sixth sense, we will find Karner approach is coming to round about figure. It really
depends what you want to follow: Karner or Schneider approach. Best is that after two or three
projects, whatever is coming accurate from history, take that approach. Best approach is to use
Excel and incorporate formulas properly.
Final Quotation:
So here is the final quotation to the scope defined and the Use Case document.

Table 9.0
XYZ SOFTWARE COMPANY
To:
TNC Limited, Western road 17, California.
Quotation number: 90
Date: 1/1/2004
Customer ID: - 20090DATAENTRY
Quantity Description Discount Taxable Total
1 Data Entry Module 0% 0% $840
Quotation valid for 100 days
Goods delivery date within 25 days of half payment
Quotation prepared by: XYZ estimation department
Approved by : SPEG department XYZ
In this quotation, I have taken Karner's value, that’s 25 days. One programmer will sit on the project with
around $1000 salary. So his 25 days' salary comes to 840 dollars approx. The upper quotation format is in
its simplest format. Every company has its quotation format accordingly. So no hard and fast rule for
quotation templates. But still if interested, Microsoft has a good collection of decent templates.
Use-Case Structure Matters:
The structure of Use-Case matters a lot. According to (Bente Anda, Hege Dreiem, Dag I.K Sjoberg and
Magne Jorgensen), the following aspects of structure have an impact:
• The use of generalization between actors: If two actors have 80 percent in common, put them in
generalization relationship and count them only once. This will increase the accuracy of the
estimate.
• The use of included and extending Use Case: Karner recommends that included and extending
Use Case should not be counted. But Bente Anda, Hege Dreiem, Dag I.K Sjoberg and Magne
Jorgensen have a different opinion in their practical experience. In some Use Cases, they found
include and extended Use Cases as essential functionalities, and reducing them will reduce steps
and hence the estimation.
 • The level of detail in the Use Case description (this is dependent on the guy who writes the Use
Case): The level of detail and transaction in Use Case impact the Use-Case estimation a lot. If
you see the Use-Case above, I have written steps like user switches on the PC etc. The
transaction would have increased and hence estimation. So if that transaction step is not adding
business value, do not add it as transaction step. This will also increase the estimation to a good
level.

Including the above recommendation by Karner and (Bente Anda, Hege Dreiem, Dag I.K Sjoberg
and Magne Jorgensen), here are also my inputs which can be followed to make an estimate
better:

• Use-Case Splitting and Merging: Simple Use-Case masters matter a lot. Writing Use-Cases, for
example “Adding Country Master". User can write three different Use Cases for Add, Update,
Delete; or he can write one Use-Case and put the Update and Delete in alternate scenarios. If the
Update and Delete do not have different business validations, put them in one Use-Case. During
my counting, I had seen that accuracy increases if for simple master we put them in one Use-
Case.
Advantages of Using Use-Case Points
• Automation: Use Case document if structured properly for a company (uniformly), we can use
automation tools. In case of FP, this is difficult.
Disadvantages of Using Use-Case Points
• Cannot be used during initial phase: Estimations are normally done at earlier stage of projects.
When we say earlier, it means during the first and second meetings with the client. Use Case
documents are mostly prepared after the project sign off. So during earlier stage, this document
will not be available. Preparing Use Case document during first and second meeting with the
client means wasting your resources in case you do not get the project. For initial phase of
project, you can use “Function points”. For function points, no formal document is needed. My old
tutorial on function points.
• No Standard Use Case Document: The document structure of use is not standard still. It varies
not only from company to company but also from project to project. So the estimation has
significant variance according to the structure of Use Case documents. Even the writing matters
to a large extent. And also, how one identifies Use-Case and the transaction associated with it.
Free textual descriptions may lead to ambiguous specifications [AP98].
• Maintenance estimation problems: Function point [article] failed for maintenance projects. It will
be difficult from Use Case Points to do maintenance estimation.
• Actor identification need technical details: In order that the actor be classified, we need to
know technical details like which protocol the actor will use. So estimation can be done by
technical guys. FP is not technical dependent [article].
Other General Practical Factors
The below points are not related to Use Case as such, but general while making estimation:
• Change of psychology: Estimator should not be biased. If you are an employee of the company,
do not add extra charge or subtract extra charges. These things will be handled at the negotiation
table between the software company director and the customer. An estimator's job is to show the
real cost of the software to the company. In short, an estimator should not be bothered about
negotiation phase and whether the company gets this project or not? Leave that work to the
company's director. And if you are the director of the company, think about that thing after the
estimation is over.
• Sixth Sense Approach: Any of the software measurement ways (Use Case, Function points,
LOC etc.) are evolving and under practice. After looking at the figure, try to give sixth sense
based on your past experience. Some times, estimation will be fair if going the ad hoc way.
 • Modular Estimation: In huge projects with 100s of modules, it's better to estimate module wise.
Example, if a client is asking for a customer module, supplier module and accounts module,
estimate them differently so that on negotiation table with client, you can show him the complete
break up. Second, this approach is very useful for phase wise estimation. Client can decide either
to not take the module (due to financial concerns) or move it to phases.
• Information Creep and Grey Areas: Estimation is normally done at the initial phase itself.
Probably with one or two meetings with the client, we have to give the estimation. But naturally, in
many of the areas there can be creep. The best way for such situations is to think about the
maximum possibility and estimate. Example, if a customer says that he needs a chat module and
no clarification is made about what the depth of it is, estimate to maximum possibility of how can
a chat application be made. Later in the negotiation table, show the client the estimation basis. So
according to the client's financial budget, changes will be made.
• Other Costing: None of the software estimation methodologies give cost for non-software factors.
o If the software is using any third-party component, example Crystal Reports etc., estimate
them in a ad hoc way.
o Example, if in the project, company is also providing web hosting, domain name,
hardware etc., put them separately.
o If any training is involved, estimate them separately.
• Assumptions: As estimation is done at the initial stage, there can be lot of creep and gray areas.
Gray areas estimation has to be supported by proper assumptions.
• Review from Third Party: Before sending the costing to the client, review it internally from a third
person who is not involved in the project.
• Iterations: Iterate it as many as times possible and at various phases. Example, use function
points to iterate during scoping phase, that's initial phase, and Use Case Point during the system
requirement phase. This gives a good idea before implementing that the costing is proper.
• Two teams estimation: During estimation, have two teams which will do the estimation. So that
cross verification can be done on the error percent of the estimation.
References
It would be selfish on my part to say that the whole article is my own wisdom. So I have provided all the
links I have referred to prepare this article. If any of the link is copyright and not to be produced, please
email me at shiv_koirala@yahoo.com. I will see to my best that I preserve the copyright.
• I work presently in Ag-technologies. Thanks to www.ag-technologies.com for providing me a role
in the estimation phase.
• Estimating, Software development effort based on Use Case experiences from industry (Bente
Anda, Hege Dreiem, Dag I.K Sjoberg and Magne Jorgensen)
• Use Case Points.
• Use Case Points.
• Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans and
technology.
• For dictionary meaning of quotation.
• If your are looking at test effort using Use Case Points, have a look at the paper by Cognizant
Technology Solutions in the Quality Week 2001, San Francisco, California, USA, June 2001 by
Suresh Nageswaran.
• In this paper, they experimented using UUCFP (Unadjusted Use Case Flow Points) for accuracy.
By Gautam Banerjee (Annual IPML Conference 2004)
• Excellent quotation templates at Microsoft.
• Templates. Not necessary to follow exactly as it is but just for reference.
• Estimation using Use Case points
• http://heim.ifi.uio.no/~kribu/oppgave.pdf
• Basics of UML.
• My old function point tutorial.
 • International Function Point user group.
• An Introduction to Function Point Analysis.
• A good PDF tutorial.
• Master thesis by Sofia Nystedt.
• Good thesis which has details about McCabe's complexity, Henry and Kafura’s Information Flow,
and Halstead measurement of complexity.
• Definition of UML.
• Definition of Object Oriented Programming.
Last Words
Software war for the best estimation has been going on for years. I am not pointing in this article that Use
Case Point is the best way to do estimation. So you will find I have introduced the advantages and
disadvantages section. But definitely, we have to measure. One day, we have to unify on a common
measurement principle. If we can say in real life, city "xyz" is 100 kilometers far, why can not we say this
project is of 1000 complexity, 200 function points or 650 Use Case points? Different languages, different
compliers, different processes companies follow have made it difficult to come to common grounds and
common measurement. But the largest hurdle we see is the software companies' attitude to come to
common conclusion of how to measure. If software can automate human complexity, then software
measurement also can be automated.
"We should no longer ask if we should measure, the question today is how?" - Dieter Rombach
Eurometrics 1991"
"Do not quote too less that programmers work for over night, you lose the project or end doing social
service, or loss. Do not quote too high that you lose the project. Be fair to yourself and your customer."