[Trac] Re: beyond defects

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 <tedfordgif@...> 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
>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users@...
To unsubscribe from this group, send email to trac-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---