|
|
 | | From: | H. S. Lahman | | Subject: | Re: Use case guidelines | | Date: | Thu, 30 Dec 2004 19:05:09 GMT |
|
|
 | Responding to Bhat...
> I am trying to identify guidelines for identifying use cases. Here's
> what I have come up with so far. Kindly feel free to provide
> additions/alterations.
I would suggest reading a standard text on use cases like Cockburn's
"Writing Effective Use Cases". Also Jacobson's "Object-Oriented
Software Engineering" has some material on extracting use cases in
chapter 7.
>
>
> 1) A use case should be triggered or observed by users (i.e. actors)
> that lie outside the system boundary
True. Use cases are a form of requirements specification. So they
should reflect a software user's black box view of the system.
Caveat: in a large system, particularly one involving hardware,
requirements may be broken down to the subsystem level. In that case
the "user" is not the overall system user but may be other subsystems or
even hardware. However, a black box view of the use cases is still in
order; the scale is now just at the application unit level.
> 2) A use case should only deal with "business functionality" and not
> implementation details
Absolutely, for the reasons above.
However, the notion of what the "business" is may vary depending on the
scope of the requirements, per the caveat above.
> 3) A use case should provide "business value" to the users (i.e.
> actors)
True.
> 4) Use case titles should begin with a verb
I would devote a lot less angst to this. The goal of use cases is to
organize requirements in a manner that reduces the chance of errors by
the developer when resolving the requirements. The primary benefit of
uses cases in doing this is grouping logically related functional
requirements and specifying sequencing constraints.
The format of the use cases is a pretty cosmetic issue by comparison.
In the end, whatever is easiest for the developers to understand is what
one needs.
[The reason starting a step description with a verb is a good idea is
simply because it forces one to think of a single (one verb) function
(logically indivisible action) for the step in hand. As long as you do
that consistently, it really doesn't matter where the verb goes.]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
|
|
| | From: | Alan Gauld | | Subject: | Re: Use case guidelines | | Date: | Fri, 31 Dec 2004 08:21:49 +0000 (UTC) |
|
|
| > Responding to Bhat...
>
> > I am trying to identify guidelines for identifying use cases. Here's
> > what I have come up with so far. Kindly feel free to provide
> > additions/alterations.
> > 1) A use case should be triggered or observed by users (i.e. actors)
> > that lie outside the system boundary
True, but don't forget other systems as actors and time too can
be considered an actor (and indeed has its own symbol in UML2)
What is interesting about these latter types of useczase is that
the benefit of the uisecase is often to an actor other than the
one triggering the usecase - e.g. interest may be paid into a
customers bank account based on a time originated use case...
Also remember to look for the systems administrator type
usecases. How will faults be detected and diagnosed? How will
data be archived etc?
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
|
|
|
