The problem is that there are two completly different ways of "use case and scenario" methods/methodologies.
The Ivar Jaccobson one (also used in the book Advanced Use Case Modeling) and the Alistair Cockburn approach --
http://alistair.cockburn.us -- (also described in Bernd Oestereichers Book OOSE Object Oriented Software Engineering).
Rule of thumb:
A Use Case has a textual description with branches (alternate pathes, error handling). Such a description can be transformed into an activity diagram.
A Scenario has a textual description as well, but without any branch conditions. It has associated sample data (use able to make a test case). The "way" through the Scenario is one possible path through the Use Case (so you define which path is choosen at every branch point by defining suitable data). A scenario is best described with a sequence diagram.
Note: I never use sequence diagrams with branches (which are possible according to UML).
Both diagram types can be used to discribe more than I proposed above and both can be used to describe simpler or different stuff.
I would also opt for a)
However I did not understand the <<include>> remark.
Well ... the standard dependencies <<include>> and <<extend>> are defined different everywhere anyway ... <<extend>> e.g. has a complete different meaning depending wether you use Ivar Jaccobsons or Alistair Cockburns method to describe use cases.
So for <<include>> I can only say: the usecase which is included usually can not stand for it self. Include in terms of use case modeling is analogous to calling a function/method in terms of programming. While a function can stand alone ... it simply serves no purpose alone. A use case which is ment to be included often usually has no human actor associated, but only device actors. That means, it is never used individually as stand alone use case.
Example: famous ATM machine. Use Case might be: "withdraw money", "check account balance", "wire transfer money" and in USA: "deposite money". All can be triggered by the user/customer. So ... no "identify" use case so far. But all or one of the use cases likely has a <<include>> relation to "identify customer".
Rule of thumb: only "extract" use cases for later <<include>> reference which you plan to reference often and unchanged.
In short Use Case modeling is synthesis, not analysisHe he, I think that confuses the novice reader. But from a philosophical standpoint its right. You can "design/synthesize" with use cases as good as with classes. Every single method in classes can be split into more fine grained methods. The fine grained methods can be moved to (and delegated to) aggregated classes (<<included>> use cases) or to super or sub clases ((extensionpoint foo) and <<extend>>)
Anyway, what ever you want to do: keep the sequence diagrams aas simple as possible. It does not matter if you find 5 use cases with 6 scenarios each or wether you find 6 use cases with 5 scenarios each. The worst case is: you find X use cases with *one* scenario each!! But if your analysis is correct: all scenarios together show all ways to use your final system.
The art is t find a minimum set of usse cases with a suitable way to describe them and easy scenarios. Because then the implementation will be more easy.
Greetings,
angel'o'sphere
P.S.
TrtnJohn e.g. has his opinion because he (obviously to me) uses the Alistair Cockbun approach, sargasso likely as well. Their posts are fine nevertheless.
