if you have the same trac, 0.11 gives you copy tickets. you also might use trac tags (see on trac-hacks.org) for marking use-cases and providing a list, or also subpages, like http://trac.edgewall.org/wiki/0.11.
you also might use a report for the tickets and then copy-paste it into a real office document and check it into your version control to make a tag/baseline. rupert. On Nov 20, 5:52 pm, "Dave Peacock" <[EMAIL PROTECTED]> wrote: > 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- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
