Hi James- Thanks for the reply.
Agree with you that tasks and use cases need to be separate, and was not suggesting tickets be used for use cases but possibly that theyd reside in a separate table alongside tickets and are entered and tracked in a similar way. But yes a good point that then it's not quite as easy to copy and paste one to another. Don't care too much for the notion of two separate trac instances and pretending use cases are tickets in the one, and you sorta defeat your own argument here with the point about copying and pasting.. Take a look at this one of Daversy's: http://www.svn-hosting.com/trac/Daversy/wiki/UseCases the idea seems like it should work pretty well. For some particualar use case they can reference the ticket(s) required, for a ticket they can refernce back to the wiki use case entry. Seems pretty good -- probably good enough for what i want to do.. I really would work hard to not have some spreadsheet correlating use cases requirements and tickets. Again i haven't yet looked at templates, hope to get a chance of these days.. Was hoping for a little more feedback from the group. It's funny because searching Trac and Trac-dev i see lots of chatter about use cases but is no one else really tracking these? Great that the list seems to be so responsive for more technical q's tho. And indeed there doesn't seem to be much out there for tracking use cases -- a quick search on sourceforge shows maybe a dozen use case packages, compared to 100x that for 'issue tracking'. And those use case packages seem to be mainly local xml-based clients, which sucks if you've got more than one person entering them. What is the format of your 'use case document', is that just an informal write up or are you using some tool for that or what? cheers dave On Nov 19, 2007 9:51 PM, James Guyton <[EMAIL PROTECTED]> wrote: > I would argue against the use of the ticketing system for managing your > use cases for a few reasons, which you may or may not find applicable: > > a.) Managing the use cases in the same system as > defects/enhancements/tasks breaks a task oriented ticket approach > > b.) It is possible that you may have multiple variants of a use case > for minor modifications to baselines, which would be painful to duplicate in > ticket form > > c.) Re-use of use cases for a similar program/project would probably > require re-creating the ticket again, or making two tickets that are very > similar > > > > The first item is probably the most important for development; it is > typically more useful/productive to try to enter tickets in some > task-oriented manner. The overall goal is then to have 0 non-resolved > tickets. > > The next two are pretty much along the same vein, and affect those > defining your requirements(if you have separate . It is far easier and > quicker to copy/paste/modify a wiki or a document than it is a ticket. If > you do this only a few times it is not a particular issue, but grows very > tiresome. (On the flip side, if you have to change systems, all of your data > is neatly packaged, and isn't too bad to migrate) > > > > I guess the better question at the moment is how you currently manage your > requirements or requirements mapping. Typically you have a requirement UID, > which maps to one or more use case UIDs, which are then referenced by one or > more tasks. That would be an ideal scenario, but what level of detail or > granularity you have can definitely vary by the industry you are in, and the > project you are working on. > > > > We will typically have a separate use case document(if they are > generated), and reference the use case #s in tickets(implement x-y of > #13123). An excel document maps test cases UIDs to use case UIDs to > requirements UIDs which map to customer requirements. If use cases are > considered necessary for the scope, mapping to requirements occurs. > > > > As it sounds, it's a fairly labor-intensive process (and painful) to > initially set up; much less so to maintain. I'd love to find some better way > of doing it which doesn't require buying a 10k USD solution or having me > manually move all the information currently entered in this form. > > > > What may be a feasible approach would be to create another Trac > environment specifically for use cases, and then use the InterTrac interface > to correlate tickets to particular use cases. That way you can have your > task-based system and your data-based system working side by side. > > > > Hmm. I may have to start playing around with that some here. > > > > HTH, it gave me some benefits! :D > > > > > > *James Guyton (JGU)* > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Dave Peacock > *Sent:* Monday, November 19, 2007 1:29 PM > *To:* [email protected] > *Subject:* [Trac] use cases > > > > Hi all- > > Just exploring & evaluating Trac now. Looks nice, there are some great > features -- but what i'd really like to do is track use cases. > > Have seen one suggestion of using the tags plugin, this is not quite what > i am after. > > Have seen a couple of examples out there of using the wiki for this, eg > add UseCases and then go edit that UseCases and add UseCaseFirstOne and > UseCaseSecondOne to that etc. Can easily link tickets to use cases and vice > versa this way -- which is important. I haven't explored templates, i would > guess you could set these up so person entering the use case can easily > follow conventions. That's important too -- i'd like the people who are > entering the use cases to follow the structure required for the use case but > not have to pay attention to the wiki structure or have to know too much > about the conventions. > > Formal use cases have well-defined fields, and in my mind entering a new > use case would be similar to entering a new ticket. There are some fields to > enter, and these are kept in a proper database. But is this overkill? It > solves the problem of having the person entering the use case having to know > anything about convention or structure, but maybe it introduces too much > complexity? > > Interested in hearing thoughts from the group. How have you dealt with use > cases? Did you use the wiki as above or some other bit of software (and if > so do you link into trac), or do you just informally send these via emails, > or something else? How is your solution working out for you? > > > thanks in advance > dave peacock > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
