For the moment, they are a reasonable good design tool. Reasonably good, because non technical users seem to understand the system better than the previous, rather technical specifications we designers wrote.
With lots of people designing Use Cases, it is not surprising that a new method has been proposed to estimate the size of systems for development based on Use Cases.
Let's give a short recap of the main stuff a Use Case consists of:
- Actor(s) : Actors can be persons, but also interfaces with other systems.
- Goal: An Actor should have a goal that (s)he tries to accomplish
- Main scenario: This scenario describes the steps to take to accomplish the earlier described goal.
- Alternative scenarios: Due to business rules such as constrictions, or due to judgment by the actor, alternate scenarios may be described.
- Pre- condition: Conditions that must be fullfilled before at the Start of the Scenario
In addition, some other sections should be part of any good template:
- Post-condition: A condition that must be satisfied at the end of the Use Case
- LOM references
- Business Rules referenced
- Author: The author of the Use Case
- Extensions: Note that some gurus believe these should be forbidden
- Includes: Some situations may be part of multiple Use Cases. In such a case, it may be a good idead to create a separate Use Case which is regarded as "included" in other Use Cases.
- Other requirements: usually technical requirements, such as : batches for 200.000 people should be processed in no more than 4 hours.
That having said, lets proceed to Use Cases Points.
These are base on work by Gustav Karner in 1993. In a way, they are a sequel to Function Point Analysis.
Let me describe Use Case Points in more detail. Use Case Points are intended to estimate the amount of hours required to realize a series of Use Cases.
The Use Case Point method also slightly seems to be based on the FPA system.
Let's start with the formula:
UCP = (UUCW+UAW) * TCF * ECF
Legenda:
UCP = Use Case Points
UUCW = Unadjusted Use Case Weight
UAW = Unadjusted Actor Weight
TCF = Technical Complexity Factor
ECF = Environment Complexity Factor
This number of Use Case Points is multiplied with a PF (Productivity Factor) to get a number of hours required to realize the scenario.
Note that this is a slight deviation from the descriptions you will find elsewhere.
Most descriptions have the PF as part of the formula, but I think this is not a good way to represent it. Use Case points, like Function Points, should be a measure for the size of the application, not a number of hours.
Let's have a closer look at each of these variables, and how to count them. My apologies that all tables in this post have a lengthy blank space above them, I'll try to figure out what causes them but at the moment lack the time to do so.
UUCW: Unadjusted Use Case Weight
Other classifications can also be found. One text i encountered uses the word "transactions" instead of scenarios. IBM states: fewer than 4 key scenarios or execution paths in the UC.
Personally I feel that the nuber of classes involved certainly is also a degree for the complexity. A Use Case which has only 1 scenario (calculate Gross-Netto for wage) may have only 1 step, but may, dependant on the fiscal system of a country and the payment system of the company, easily involve anywhere from 10-30 of even more classes. For this reason I have left them in.
The Weight column gives the number of Unadjusted Use Case Points (UUCP) for each Use Cases with these characteristics.
Example:
The same logic is applied to Actors: Actors are classified as simple, average and complex.
Example:
The sum of Unadjusted Use Case Weight and Unadjusted Actor Weight gives the Unadjusted Use Case Points, or in formula:
UUCP = UUCW + UAW
These UUCP are adjusted for Technical and Environment Factors to arrive at the Adjusted Use Case Points AUCP.
A list of 12 Technical factors are considered, and again each factor is assigned a weight:
Every factor is estimated on a scale of 0-5 for its perceived value. Then the Technical Correction Factor is calculated with the formula:
TCF = 0.6 + sum(perceived value*weight)/100
Example:
TCF = 0.6 + 30.5/100 = 0.905
The Environment Correction Factor represents things in the environment that greatly influence the project. Again, these variables are processed the same way that Technical Correction Factors are treated: Each factor is assigned a relative weight, each factor is estimated on a scale of 0-5 and the product is the EF for that Factor.
ECF = 1,4 - 3 * sum(perceived value * weight)/100
Example:
We have a team that knows the application inside out, and also has years of experience with objectorientation. Alas the requiremebnts are known to be vulnerable for change. The team consists for a majority of part time workers.
This gives a total of 8,5, making the environment correction factor:
ECF = 1.4 - 3*8.5/100 = 1.145
Sources:
- http://www.bfpug.com.br/Artigos/UCP/Karner%20-%20Resource%20Estimation%20for%20Objectory%20Projects.doc Gustav Karner, 1993, doctoral thesis.
- http://www.uea.ac.uk/~a168955/effort_estimation/use_case_points.html, Use Case Points Method
- http://www.codeproject.com/KB/architecture/usecasep.aspx Project Estimation with Use Case Points, by Roy Clemmens
- http://www.methodsandtools.com/archive/archive.php?id=25 Estimating With Use Case Points, by Mike Cohn,
- http://www.stsc.hill.af.mil/crosstalk/2006/02/0602Clemmons.pdf Project Estimation With Use Case Points, by Roy Clemmens
- http://www.ibm.com/developerworks/rational/library/2870.html Dr Use Case at IBM
