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.
-Chris
On Thu, Aug 28, 2008 at 11:03 AM, <[EMAIL PROTECTED]> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
