• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

CRUD based use cases

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
We are working on a generic table maint. application that is to be "everything to everybody" .. so we are having trouble deciding how to draw up use cases .. since many books suggest that we shud not be drawing up use cases based on CRUD (Create/Retrieve/Update/Delete)model, we are having a tough time deciding use cases based on functionality. Since Add update delete will be the generic user requirements ..
does anybody have any ideas, link, books t suggest ??
thanks,
vik
 
John Wetherbie
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have requirements/the need to do CRUD on something in your system then you should write use cases for these interactions. There hasn't been a system I've worked on that hasn't had these types of use cases. Do what you need to do to make your system successful!
John
 
Junilu Lacar
Bartender
Posts: 7486
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alistair Cockburn (pronounced Co-burn, long o) discusses this in his book "Writing Effective Use Cases"
His approach is to lump everything together in a "Manage whatever" use case and then write subordinate use cases as needed for any operation that gets too complex to lump in with the others.
J.Lacar
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you get your end-users to write up use-cases? I firmly believe initial use cases should only show what is happening from a users perspective. Also, if this is a "everything to everybody," then this will help you understand your user's biggest needs, and what needs to be quickly acessible to the user.
One way to do this requires training them what use cases are, and then having them write this up. That might take too much time.
A second way might be to simply ask them to give examples of what they want to happen. You'll need to giv ehtem a little guidance, like "how many steps from login to <data retrival>". Then you need to go thorugh all the use cases, and fix them up, make them clearered, and fractor out the common cases.
A third method might be to have a facilitator sit down with groups of users and "play computer." Think of it like an old faschion computer adventure game, like Zork. The facilitator stands in front of a white board and draws a login screen. The user says, "I enter my username and password, and press enter." The facilitator than draws the first data screen. The user says, "I use my flaming sword +2, er, I mean, I press the select database button." The facilitator draws a dialog with a list of databases, etc. This type of work will usually only give you mainlines, you'll need to add exception cases yourself. You should inso include some metric as youwak through it, sinc eht euser may not be awaythat he had to navigate through 4 screens to get somewhere, when he really wanted only to go through 2.
--Mark
hershey@vaultus.com
 
David Roberts
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am pro-CRUD. I submitted a suggestion Allistair Cockburn that a new terminology be defined to described making a Extension a Extension Use Case. This also applies to CRUD, when you use an Extension that starts to become to important to be part of the CRUD Use Case. You can see a blurb about my concept at: http://www.usecases.org/cgi-bin/wiki.pl?GraduatingUseCases
It's also a good site to check out...
------------------
David Roberts, SCJP2
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic