Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

when it use use cases

Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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'm so happy! And I wish to make this tiny ad happy too:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic