Some Use Case Guidelines

Here are just a few suggestions:

Use Cases generally are broad enough to contain alternative scenarios.  For example, a use case to "Sell Products" might contain the scenario of selling a UPC coded item and also a scenario for selling an item that has to be weighed on a scale.  This is why UML models have activity diagrams (which, like flow charts, can contain branches and loops in the logic) and can have attached to them multiple sequence diagrams (for various scenarios thru the use case).  So if you have a use case that doesn't contain alternative scenarios, that suggests it isn't really a use case.
The breadth of scenarios generally varies by more than the fine grained data inputs.  For example, while selling an item that costs $1.50 could be considered a different scenario than selling an item that costs $9.45, this doesn't add much breadth.  We get appropriate breadth in a use case when the contained scenarios not only vary by value but also by repetition, by order, and by participation.  So, for our Sell Products use case, it adds more meaning to capture the scenario about buying several items and then getting a discount, about being able to display the total even though all the items aren't priced yet, and taking a credit card rather than accepting only cash.  All of those variations, and their collaborations, fit beneath the use case.
The scope of a use case usually is in terms that justifies a sub-system or system to the use (actor).  So, you shouldn't have a use case called "Login" because no business stakeholder ever bought a system for the purposes of logging in.  Selling Products, Detect Aircraft, Identify Employee, Pay Taxes, Transmit Cargo, etc. are good use cases by this standard.  Login, Update Database, Display Results, etc. are much too fine-grained to be use cases by this standard.  It isn't uncommon for a use case to have a level of abstraction that is on par with release - e.g. a release may contain scope in the range of a couple of use cases to scenarios of a use case.
There generally shouldn't be a similarity between the use cases on the Use Case Diagram and the activities on the Activity Diagram.  If your Use Case Diagram has use cases called "A", "B", "C", etc. then generally you shouldn't see the same names for activities ("A", "B", etc.) on the Activity Diagram.  You might see this for a very high level activity diagram for the system as a whole that shows the flow through the system uses from the scale of the external actors - even so, the scale is as the uses level - Sell Products, Transmit Cargo, etc. and not Login, Update Database, etc.  More often, your high-level activity diagrams are at a level of abstraction below the use cases.  So, if the use case is Sell Products, then the activities are Price Item, Weight Item, Collect Payment, etc.
The comments above reflect what I would consider mainstream use of Use Cases - influenced heavily by Jacobson and the influence he had on Use Cases and UML coming out of Object Oriented Systems Engineering (OOSE).  One of the guiding factors is that general use of Use Cases is as a part of a model that includes many other UML diagrams.  In that case, you use Use Cases in a certain way because other work is done by other diagrams.  That is amplified by how most of the current UML tools work - the Use Case diagram implementation is relatively modest and more capabilities are put into the other diagrams.
If you are primarily, even exclusively, using Use Cases then some other factors come into play.  It would be easy to dismiss such a plan as a "when all you have is a hammer the world seems full of nails" approach but there is some legitimate work in this area.  Cockburn's Effective Use Cases has a much more elaborate approach to use cases as do some of the UP/RUP variants.  If that is the case, then your use cases can become quite detailed but there is some extra notational (use cases with slashes, use cases without slashes) and analytical (user, summary, sub-function) work.
Finally, I'll add that if you are using the Rose and ReqPro integration then you probably want fairly small use cases - smaller than my suggestions above and more like systems functions.  The reason is that Rose and ReqPro only integrate at the use case level.  It would take another post to explain why (it is either obvious...or not) but the effect is that this generally drives the size of your use cases down. Which is odd given that both tools are from Rational, the "Three Amigos" (used) to work at Rational, and they argue for use cases as part of a UML model rather than trying to do everything with use cases.
- Brian

No comments: