In some software development activities the use cases may be unconstrained.

A team can generate use cases as long as they have ideas and budget.

The use case method provides a metric that assigns a software complexity metric to any set of use cases.  This complexity metric may then be used to estimate the cost and level of effort associated with any use case set.

Whatever the name (generally some variant of Function Points), the aim is to measure the respective size and complexity of business requirements on one hand, functionalities and quality of service supported by systems on the other hand.

That will be used to manage options and plan projects with regard to the expected business value.

http://caminao.wordpress.com/about/community/requirements-functionpoints/

Use case points are a measure of size, just like Function Points.

Just like Function Points, they do not incorporate any notion of quality.

With respect to Function Points, they are expected to be much easier to measure, hence faster and cheaper. In fact, once you have drawn your use case diagram, you just have to assign a complexity rate (high, medium or low) to actors and use cases. This is much easier than analysing all data and transactions of the system, as required by Function Point Analysis.

The problem with use cases is that they are much more coarse grained than Function Points: in Function Point Analysis, every transaction is weighted individually, while a use case is weighted according to the range of transactions it includes, regardless their complexity. For instance, a use case including 4 simple transactions has the same weight (i.e., size) as a use case including 7 complex transactions.

As a consequence, you may have that two systems have the same size in unadjusted use case points, but quite different sizes in Function Points.

For estimating purposes, Function Points are expected to be much better, since they provide a more accurate measure of size. However, I found that use case points can perform well when used in conjunction with measures of data processing: see Luigi Lavazza, Gabriela Robiolo "Using Functional Complexity Measures in Software Development Effort Estimation", International Journal on Advances in Software, vol 5 no 3 & 4, 2012

1. Provides early during Market Requirement Development phase from object oriented analysis perspective. Generally at this stage design(Class, functions, APIs, Data...) is not available.

2. Though tors, uses case scenarios, required third party integration needs, environment etc. are known.

3. Its simple and quick that can help the Product Owners to take decision of feature list prioritization (High Business Value with least cost FIRST).

Respected  Luigi Lavazza,

Can u please elaborate this "use cases is that they are much more coarse grained than Function Points" further.

I guess  Yaeghoob Yavari et al. have clearly mentioned that the complexity rather the weight factor assigned to any transaction cannot be given just considering the no. of  transactions rather they designed a new use case complexity metrics to incorporate   various factors so that well defined transaction standard  to decide that weight factor  is framed .

Even further  in another study the authors  further refined the use case complexity by  estimating use case complexity based on the steps involved rather than transaction.(Rui Alves et al)

A use case is defined as a sequence of steps --involving interactions between an actor and the software system-- to achieve a goal. This sequence may involve several elementary operations. For instance, placing an order could include authentication, colouring a picture may include setting a default colour, etc.

Function point analysis defines precise rules to decide whether each of these operations is an elementary process (which should be measured separately) or not. Instead, when writing a use case diagram, the modeller can put together the 'place an order' and the 'authentication' operation in a single use case, or he/she can decide to have two separate use cases.

Of course, this choice results into different sizes for the same software application.

When a use case is defined, the emphasis is on capturing the user goals and how these goals are achieved via interactions with the system. There are no specific guidelines for building a model that can be used to derive a unique size measure. The consequence is that usually all the transactions (or elementary processes, in function point terminology) that are necessary to achieve a goal are put together into a single use case. In this sense use case points (as originally defined by Karner) are coarser-grained than function point.

This type of problems has been recognized by researchers, who have proposed several ways of measuring use cases.

@Luigi Lavazza

thanks for response.. and hope for  better cum productive communication ahead..