Modify

Opened 7 years ago

Last modified 10 months ago

#1226 new enhancement

Plugin for writing requirements and specifications of a software

Reported by: Daniel Werner <dwarf007 ... moesbar ... net> Owned by: anybody
Priority: high Component: Request-a-Hack
Severity: normal Keywords: requirements, specifications, plugin
Cc: fcorreia@…, rjollos, fduarte, sorin Trac Release: 0.11

Description

It would be unsefull to have a plugin allowing to write requirements and specifications of a software (in the way the ticketing system of trac is working).

The requirements could than later (during the project management) be linked to software problem reports or to the source code etc..

Attachments (0)

Change History (25)

comment:1 Changed 7 years ago by athomas

  • Component changed from TracHacks to Request-a-Hack
  • Owner changed from athomas to anybody

comment:2 Changed 7 years ago by anonymous

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

comment:3 Changed 7 years ago by anonymous

I support this also.

comment:4 Changed 6 years ago by leeus

Me too ... it would be great

comment:5 Changed 6 years ago by anonymous

I vote for this

comment:6 Changed 6 years ago by anonymous

  • Priority changed from normal to high

comment:7 Changed 6 years ago by yoheeb@…

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?

comment:8 Changed 6 years ago by anonymous

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

comment:9 Changed 6 years ago by anonymous

  • Cc fcorreia@… added

comment:10 Changed 6 years ago by anonymous

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

comment:11 follow-up: Changed 6 years ago by anonymous

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?

comment:12 Changed 6 years ago by Soenke.Brecht@…

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

comment:13 in reply to: ↑ 11 Changed 6 years ago by anonymous

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.

comment:14 Changed 6 years ago by yoheeb@…

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.

comment:15 Changed 6 years ago by Soenke.Brecht@…

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.

comment:16 Changed 5 years ago by flavour@…

  • Trac Release changed from 0.10 to 0.11

Another +1 for this fucntionality :)

comment:17 Changed 5 years ago by jeffrey.lyon@…

+1 for this functionality!

comment:18 Changed 5 years ago by rjollos

  • Cc rjollos added

comment:19 Changed 5 years ago by dallison@…

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

comment:20 Changed 5 years ago by fduarte

  • Cc fduarte added

comment:21 Changed 4 years ago by anonymous

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

comment:22 follow-up: Changed 3 years ago by sorin

  • Cc sorin added

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

comment:23 in reply to: ↑ 22 Changed 3 years ago by rjollos

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.

comment:24 Changed 11 months ago by arci

it sounds great! +1!

comment:25 Changed 10 months ago by anonymous

Actually, if the workflow was by Component, instead of Type, it would be of great benefit to me.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.