The best way to write use cases?

[Larry Tubbs]

This really is a great discussion. It looks like it was put to bed some time ago, but I have to make one comment. Fintan said:

"I avoid the word 'user' in use case texts and always specify the actor name."

I actually avoid the use of the Actor name in favor of "user" allowing relationships to define which actors can use the use case.

-Lar

[Steve_Straley]

Larry,

I'm not sure "user" works for all situations.  For example, in the system I just UC'd, there were ALOT of system-to-system interactions.  "Actor" is much more "neutral" between an actual person and a system whereas "user" seems to be more restrictive, especially in my situation.

Cheers,

Steve

[Larry Tubbs]

Ah, I see.  You are using the word "Actor" rather than the name of the actor doing the action.  That would be much more generic.  That works.  Thanks,

--Lar

[garbelini]

Hi all,

I really think it´s a matter of knowing the environment and adapting the official recomendations to it. There really is no rulle that works for everybody and every project. (except for this one  )

The deal is to understand the recomendations and know how and when to use them.

I´m just starting to learn this stuff but it´s already clear to me that you can and should adapt the process to your project and not the other way arround.

In other words: I actualy use the word "USER" for any Human<->System interaction within our use cases but I can definitely imagine more complex projects where this would not work.

Cheers,
Marco Garbelini

[darryl_staflund]

Hi there,

If I am developing an n-tier web application I like to write one use case that handles that handles all the different scenarios of a business process being implemented.

When I draw it up using Enterprise Architect, however, I like to create an abstract use case icon for the use case as a whole and then create concrete particular use case icons for each round-trip from the client to the server and back again.  I then use realize relations to connect them back to the abstract use case icon.

I get a number of benefits from doing this:

1.  I can come up with rough estimates on how long it will take to implement the use case by multiplying the number of client/server requests with the average historical time needed to implement a client/server request.

2.  I can create interaction diagrams for each client/server request, making sure to focus on the calls taking place for it.

3.  I can partition the concrete uses cases to my workmates.

I like it :-)  And this way of partitioning use cases goes hand-in-hand with presentation technologies like Jakarta Struts in which the atomic work unit is an 'Action'.

Cheers,
Darryl