Plugin for writing requirements and specifications of a software

Yup, this would indeed be a very useful feature..

I support this also.

Me too ... it would be great

I vote for this

I think a good model for this, might be a combination of tools. a macro to export requirements from other tool, specific to requirements management (example Telelogic DOORS), then a tool to import then, update them dynamically etc., and jam them into the wiki as linkable objects. I.e., export requirements to xml from tool X, check into /requirements of project subversion repository. new magic post commit hook script that updates Trac that a requirements document was "modified" or created in this example. extract requirements, formats them into a wiki-page, or set of pages. cross-links requirements where referenced by other requirements, etc. I used xml in my example, since I am thinking the next step is to allow meta data decoration of the data (section headings for the wiki format, tracibility information across different levels, or even across documents (system req to software req, to software design, to component req, etc.) Maybe I am thinking to big, but why not shoot for the moon?

This should also hook into the TestCaseManagementPlugin since in most workflows they are connected.

yes could be great! Polarion tracker does it, here's a demo

Follow up to this.

The way that Agilo implements linked tickets, with calculated fields could be a very good extensible way to implement something like this. Combine with master tickets (or not) and TypedTicketWorkflow?, and you have something. a "System requirement" ticket type, or a "FunctionalRequirement?" ticket type.

The one thing that would be really nice, would be the ability to export the actual requirements into requirements documents. some kind of tool that runs against the database for all tickets of type (configurable of course) and exports to "wiki", plain-text, pdf.

some thought as to an additional custom field would be needed to group "requirements" tickets. I.e. type=Requirement Component=GUI Module=Menus...

yes, the export cases would make something from trac really fly!

I', up for this....anyone else?

+1 I also appreciate such a plug-in very much.

Replying to anonymous:

TypedTicketWorkflow?,

Is this statement still valid? I got the impression from the admin section that typed tickets are part of the 0.11 core product.

Therefore one can already filter via custom queries the functional requirements.

Another point is to get the hirarchy of each ticket. With the current MasterTickets? macro I have to name the top requirements instead of giving a blank parameter to geld the full tree. So the Wiki Part is already, very rough, solved.

Replying to anonymous:

TypedTicketWorkflow??,

Is this statement still valid? I got the impression from the admin section that typed >tickets are part of the 0.11 core product.

The portion of the plugin I was referring to would be to prevent, say, a "requirement" ticket from having the same state transitions as a normal ticket.

A requirement, could go, for example from Requested->Acceptance Test Created->Impelemented->Tested->closed:Complete (just making this up) Or maybe also Closed:Abandoned, Closed:moved to new Milestone. etc. or whatever you could want I suppose, so "configuring" the workflow of requirements generation. as apposed to assigned->accepted->closed:fixed

V model would be somthing like:
type: FuncReq
New->Reviewed->Accpetance Test(s) created->User Stories created->System Requirement(s) Created->Acceptance test Passed->Complete
type:SysReq
New->Reviewed->Validation Plan Section Complete->FMEA Analysis stage I complete->Design section created->Integrated->Validation Plan Passed->Complete
type DesReq:
new->Reviewed->Unit Test(s) created->implemented->CodeReviewed?->Unit test(s) passed->merged->tracabilty created->added to release binder->complete

or whatever, the model could/should be configurable I suppose, the only real piece missing is to generate docs/wiki pages out of all the *Req documents, and traceability, etc., which I see becoming a tool that runs directly on the DB.

Just some thoughts on utilizing existing "systems" already there anyway.

Thank you for your explanation. I missed the fact that type depended work flow has not been taken into the core product.

Full acknowledge to your further statements. Reporting is the only missing feature.

Another +1 for this fucntionality :)

+1 for this functionality!

This type of requirements management in TRAC is exactly what I am looking for. I'm a long time DOORS user so I'm familiar with the needed functionality of a requirements management tool. I just installed TRAC and am getting used to it. If anyone has figured out how to do some minimal traceability, I'd love to hear how. Thanks

I vote form this, too (Andreas Stucki, a.stucki....solcept...ch)

I know that commenting with "vote too" is not a good idea, but voting plugin is not installed, so I "vote too".

Replying to sorin:

I know that commenting with "vote too" is not a good idea, but voting plugin is not installed, so I "vote too".

Great idea though ... t.e.o has the VotePlugin installed, so we should have it installed here too. #8717.