This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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
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
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
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
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 email@example.com
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