Howmany use cases

Question

This is an excerpt from "UML Distilled" by Martin Fowler & Kendall scott(pageno.47)
"How many use cases should you have?During a recent OOPSLA panel discussion, several use case experts said that for a 10-person-year project, they would expect around a dozen use cases. These are base use cases; each use case would have many scenarios and many variant use cases. I've also seen projects of similar size with more than a hundred seperate use cases.(If you count the variant use cases for a dozen use cases , the number end up about the same.)As ever, use what works for you."
EXCERpT END
So far my understanding of variant use case is that a variant use case represents a functionality that is reapeating across many use cases. The above excerpt does not seem to fit with this understanding.
During the initial phases of project, if high level use case representation has to be conveyed to a domain expert , making use cases which include a great deal of similar requirements is a good idea as the whole system can be represented in a very simple manner.
For example , a use case like "manage accounts" can be further subdivided in to open , deposit, withdraw, close account in later stages of development. But the issue is could these be called as use case variants. And how these are to correlated to the original use case "manage accounts"?.
thanking you,
sprasad

Answer 1

Be careful with RUP - it's very documentation centric, and I have yet to see a case where all of the required documentation is useful to the successful development of the project.
The hierarchial decomposition of a problem domain is best illustrated through dual mechanisms - both the Use Case diagrams, and actual Use Case documentation. The diagrams can be developed in a hierarchial fashion (i.e. a single use case on a high level diagram decomposes into several more detailed use cases on a separate diagram).
Where you stop the decomposition is really part of the art of use case analysis, and will be impacted by the methodology that your team practices. The teams that I work with practice various "Agile" methodologies (XP, Scrum, Crystal, DSDM, etc.), so what I look for in a "detailed" use case is 1) can a developer build the needed functionality within a single development iteration? and 2) What other functional areas (if any) are similar enough to encourage the development of more generic functionality to address multiple requirements. My guess is that this is equivalent to the "variant" use cases mentioned above (bear in mind I haven't read the book).
So it really depends on how your project team works. If you are practicing a "heavy" methodology like RUP or Waterfall, where all of the analysis is done up front, it is important to define all of the use cases in advance. This doesn't change the issue of how to establish the functional requirements hierarchy, but it does change when you will put in the effort to identify this hierarchy.
If, on the other hand, you are practicing an Agile methodology you will still need to identify the hierarchy, but you do it in stages. For instance, at the beginning of a project I will identify the major functional needs (i.e. an accounting system needs AR, AP, journals, GL, etc), but then I will concentrate on the detailed analysis of only one aspect of the application. From there the team will design and build it. Then we move on to the next aspect of the application. At the end you still have a detailed analysis of the application (hierarchial use case information), but you can much more readily adapt to changing business requirements, and you tend to produce a lot less meaningless documentation.