File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes when it use use cases Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "when it use use cases" Watch "when it use use cases" New topic

when it use use cases

william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
I have this recurring ambiguity as to when to go in for use cases and what to document as a part of usecases.
For ex
If in my application user can add,modify,delete user information will it be useful if i document each user goal(Add,modify,delete user info) as use cases.
I personally feel there will not be much value addition in documenting in a use case the fact that user submits necessary in formation to add/modify/delete user info thru the manage user screen and system updates the information in the db .
My question is how else can i express such functionalities(is there any other UML artifact?).Is a use case style of expressing functionality only useful where are many user-system interactions.

Help me!Help you!!!
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'm on a team that still appreciates its use cases. You'll also find much literature about agile methods that don't do use cases. It's good to ask yourself for any artifact who will create it, who will use it, how much does it cost to make, how much is it worth, does it help you make better software, is there a lower-effort way to get the same results? The bad news is only you can answer those for your particular developers, customers and managers.
We keep making use cases because we have business subject matter experts and users and their managers in multiple locations, and they like to run multiple levels of review and sign-off on the use cases. In our world, all functional requirements are in use cases or concrete UI design documents. If it's not there, we don't build it. Keeps everybody honest.
If you are close to your customer (physically and in partnering) you might get by with less. Most agile methods build one "story" at a time, usually roughly a use case flow. A developer talks through the story with the customer, does minimal design and then builds it. There is usually no permanent documentation, no formal sign-off before build, no archives of old requirements.
As a compromise, we build one story at a time, but document the requirements in use cases as we go.
Any of that help? See Scott Ambler's for many essays on this kind of thing.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
te thompson

Joined: Jan 05, 2004
Posts: 7
In a perfect world with no schedule/budget constraints, it would be best to write a seperate UC for each of the 3 scenarios you mentioned. I do not live in a perfect world and am responsible for producing far too many use cases. One way I have dealt with this same problem, is to write a more abstracted use case and capture the 3 flows in the basic and two alternate flows. The one drawback to using this approach, is alternates and exceptions become very hard to document if the UC is complex and has many. You begin to run into the case where there are alternates to alternates to alternates etc. But this is a simple one and has worked for me.
Title: Manage Users
Basic Flow: User is added to the system.
Alt1: User is updated within the system.
Alt2: User is deleted from the system.
Expt1: User already exists (on add).
Expt2: User does not exist (on update and delete).
Hope this helps.
I agree. Here's the link:
subject: when it use use cases
It's not a secret anymore!