Here's an idea ... it's free so you get what you pay for ;) define additional ticket types: requirement, use case
requirement is pretty self explanitory ... for use case, you can attach your favorite use case modeling tool's file and (i think) you can reference attachments to a ticket in the form of a trac-link .... if so, that should get you 80% of the way there .... if your requirements can be held in the original ticket field which can be modified as needed by a user with ticket admin privs.. all follow on comments are just that ... comments as for the use cases, it's a hack even if it would work ... but hey... this advice is free and so is trac ;) but yeah ... it would be cool if trac could render a major FOSS use case modeling tools file as a jpeg ... much like the dia/graphviz plugin ... sounds like a great idea for a plugin ;) -Chris On Nov 20, 2007 1:17 PM, <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
