Hello, in my opinion Uses Cases, Feature Requirements, Test Cases, Tickets, Tasks and so on fits perfectly into the same environment. The only problem is, that every item should have its own workflow and set of custom fields. For example the Uses Case document consists of an history enabled WIKI entry and a set of fields, like author milestone and so on. Issues/Bugs/Whatever are like now. Every group of related items would have a common prefix, like UC or FRS abd you could link to every item with the prefix. Feature Requirements then can link to Uses Cases and tickets back to Feature Requirements, and so on. This would be great.
The current problem with trac, in my opinion, that the base element is a ticket, and that this ticket is bend to the other "types". Trac should support many different types (or tables or however you like to call it) from the ground up, so that you can build every possible workflow out of it. (I havn't chekced with 0.11, but in 0.10 you need to hide fields for various types) If you then can also branch items and tie items to your source control, so that items branch with your source code, ... only my "fast" 2 cents Dirk James Guyton schrieb: > > 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 -~----------~----~----~----~------~----~------~--~---
