On Aug 28, 9:36 am, "Christopher Taylor" <[EMAIL PROTECTED]> wrote:
> Here's another idea:
>
> define a ticket type called requirements. Use master tickets to
> associate Requirement <= Architectural Component <= Design Component
> <= Unit Test Case <= Integration Test Case ... etc you get the idea
>
> Then create a plugin to create the document from the tickets. You'll
> get things like traceability etc from doing it this way.
>
> -Chris
>
> On Thu, Aug 28, 2008 at 6:45 AM, Ted Gifford <[EMAIL PROTECTED]> wrote:
>
> > Noah Kantrowitz wrote:
> >> jevans wrote:
>
> >>> Now I'm curious about moving our requirements and specifications into
> >>> Trac as well. Basically what RequisitePro gives you is the ability to
> >>> tag and track items in a document. Our typical usage is to write a
> >>> document, review it, and then tag it. Tagging is done quite easily by
> >>> highlighting the text, entering attributes (field values) to use, and
> >>> having it automatically make a database item of each paragraph (how it
> >>> determines where one spec ends and the next begins is configurable).
> >>> Now you've got a document that can be read as a document, plus
> >>> trackable items in a database.
>
> >>> ...
> >> Sure, sounds possible. Probably not super trivial to make, but not too
> >> hard either. Some other things I would look at are making workflow
> >> plugins (ITicketActionController) and the TracTags plugin. Mix all that
> >> together with some custom UI glue and it should do what you want.
>
> >> For manipulating the wiki UI you can use ITemplateStreamFilter and the
> >> genshi Transformer system (see how tags adds its UI for an example).
>
> >> --Noah
>
> > I'm interested in this, too. Here's some brainstorming. To associate the
> > requirement attributes with a given text, you could create a macro to
> > interpret something like this
>
> > {{{
> > #!Requirement
> > #!type: functional | nonfunctional | security | etc.
> > #!heading: Requirement Title
> > #!summary: A brief description of the requirement.
> > The paragraph(s) describing the requirement, containing __WikiFormatting__
> > or [Macros]
> > }}}
>
> > or if you prefer xml, that would be possible, too (you could write an
> > IWikiSyntaxProvider to hide/transform the xml tags).
>
> > <req type="functional" foo="bar">
> > <heading>Requirement Title</heading>
> > ...
> > </req>
>
> > Of course that would be hackish and less then Trac-like, but depending
> > on your process, etc...
>
> > If you start your process with plain text, the first time the wiki page
> > is scanned for requirements by your IWikiPageManipulator, it could use
> > some configurable pattern matching to transform the text into the format
> > above. Then (or later) it could create tickets and store the association
> > via "#!ticket: 25". It would tag the ticket with the wiki page name.
>
> > Would it be wise to disable editing of the ticket summary and
> > description (must use requirements wiki page)?
> > Should it automatically delete tickets if a requirement is removed?
>
> > Ted
I am fully of the belief that the best solution for requirements
tracking in Trac, is not to actually track the requirements in Trac :)
why not put the requirements in a separate database, and let trac pull
them dynamically/create a macro to link [[req:1001]] and or expand the
requirement, per a css to text in the wiki (I mention both, because,
you might just want to reference a requirement, in say a ticket, but
actually puke up the whole requirement in a wiki page or something
the 'pull' of the requirement would be a query of some sort. that
way, you could, for example, create a page to capture all requirements
where field x=someval, sorted by field y. for example: select * where
module="GUI" sort by screen then number (number being an arbitrary
value like 1.1, 1.2, 1.3, but not the unique ID of the requirement in
the database.
maybe you even make it accessible vie xml-rpc?
Just a thought.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
