On Sep 3, 4:48 pm, "Christopher Taylor" <[EMAIL PROTECTED]> wrote: > yes, essentially I'm suggesting that the OP attack the problem from > the opposite direction. Don't generate the requirements from a > document, generate a document from the requirements. Basically what > I'm advocating is to think of tickets in the most general fashion > possible, work items that need to be accomplioshed. When you > generalize the concept of the ticket, you can start to use different > types of tickets for all sorts of purposes they might not have been > originally intended. Of course, this is GREATLT simplified by the > ?recently implemented? option to display certain fields only when a > ticket is of a certain type. > > For the use case, I was thinking something like: > 1) create the requirements as tickets > 2) plugin generates a wiki page based on requirements tickets, perhaps > grouped by component (you get the idea) > 3) requirements wiki page could be exported via the excel export > plugin or others > > an additional plugin could easily be written to integrate the graphviz > plugin to draw relationships of the requirements tickets, etc. If you > implement the time tracking plugin the new plugin could time code the > ticket nodes to indicate their schedule risk or some other factor. >
ahh, you top posted. this thread was long anyway, so I just cut the previous responses to save on gmailbox space :D you have hit the issue on the head, finally. I was looking at this route, and recently the 2 agile plugins that have popped up (agilo looks really nice btw) and came to the same problem. The general idea for me, is a requirement "document" is just a container object (say a master ticket, or a field in a db row linking to a table) that holds requirement objects(say, child tickets, a row in a table, etc). This relationship also applies to design documents/design requirements, use cases/accpetance criteria, test doc/test cases..etc. so, Trac ticket system, or some other relational tool would work just fine, viewing in Trac. Well, that's dandy, however, some of us ultimately need an ACTUAL set of documents, so how to get them. The "other" tools out there are just databases with specialized front ends, and reports/ queries. come up with that, come to think of it, I wouldn't mind trying to work this out with some folks. That said, I would really like to leverage the stuff that is already out there. my $.02 would be, -in addtional on "creating" the requirements document/wiki pages, it should be able to ultimately generate the traceability to other requirements AND their respective documents: i.e. reqdocA:103- >testDoc5:122,123,345 going #103->#122, #123, #345 is easy, but you loose the context for the corp QA types (in other words, and traceability matrix) -would be nice if it could be configured to automagically(tm) generate a "document" and check into a specific location in source control (maybe checkout/checkin if there's a "revision"; coupled with a "scan for changes to 'requirementX'" this would seem to require you to save a "requirement document" once it's been generated (fully optional of course) -support custom workflow actions (say reviews) when exporting to the wiki page/document (revision history, revision N, reviewed by x, y and z: revision comments x - "blah", y- accept as is, z accept with the following conditions, "seciton x, spell section correctly", "no-blah" or automagically create a new ticket to have it reviewed, whatever I assume this could be captures in the ticket history, and just collated when generating the requirements "document",etc. ultimately (shoot for the moon), you would get linking of reqs to code for free. right, you would like a high level req to a design requirement and a test requirement, the design requirement to a verification test (unit test) and possibly to a ticket to do the work (task ticket), and the check in comment of source to ref the design requirement or task ticket. :D that's a lot of tickets, and put this in some sort of tracibility matrix on roids. although, most of those are long term nice to haves, the linking to requirement doc with ticket number combo for me is a must have optional tool. rambling over, for now. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
