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 -~----------~----~----~----~------~----~------~--~---
