Re: Use cases and visualization information

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.

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.

Hope this helps.
Rebecca
Rebecca Wirfs-Brock
website: www.wirfs-brock.com blog:
http://www.wirfs-brock.com/rebeccasblog.html

.

Quantcast