Re: Use cases and visualization information

"Rebecca Wirfs-Brock" <rebecca.wirfsbrock@xxxxxxxxx> wrote in message
news:1143349761.814915.149090@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I just wanted to shed some light on what makes a good use case (and why
some requirements aren't really appropriate to describe in a use case).

In my experiences, use cases work best to describe a "chunk" of a
system's behavior from an external user's perspective.. for example, I
as a user want to make a deposit, or file a claim, or accomplish a
specific task. Typically use cases start with a user's goal and then
describe a sequence of steps performed by the user and the system in
order to accomplish a user-specific task.

In the case of a system where there aren't discrete user to describe
(what are the use cases for a computer game for example?) use cases
don't add much value. Instead, it makes more sense to use other forms
of descriptions to describe how your software will respond to events
(given the current state it is in).

Use cases also don't add much value for systems where users issue lots
of small commands (imagine all the menu items on your favorite word
processor). It really doesn't make sense to write a use case for
"Change Font Style", "Make a word Italic", etc., etc. Although you
still might want to describe these functions, use cases aren't the best
form for these functional descriptions.

Group them into a "change text" use case.
The change types (font, size, style etc) can then be briefly described
therein.


Alistair Cockburn mentions four levels (or it might be five) of use
cases--very high level summary, summary, user-task oriented,
subfunction, and low level use cases. He recommends that use cases are
most appropriate to describe user tasks. I've found the best way to
identify task-level use cases is to ask (and then answer the
question--what do you want to do with the system?) and then turn those
into names of use cases.

The way I have done this over 10 years is to consider a system as
undertaking
a set of activities in order to provide some function/service (not standard
UML) .

1. Activities are described using a typical use case format.

2. The activity "actors" are those entities that act as event/data
source/sinks for
the activity.

3. A use case is a special type of activity, where the actors are entities
*external*
to the system being built.


When doing analysis, the lowest-level activities I will ever have is between
subject
areas belong to the same subject domain.


Regards,
Steven Perryman


.

Quantcast