Modify

Opened 17 years ago

Last modified 4 years ago

#1226 new enhancement

Plugin for writing requirements and specifications of a software

Reported by: Daniel Werner <dan@…> Owned by: anybody
Priority: high Component: Request-a-Hack
Severity: normal Keywords: requirements, specifications, plugin
Cc: Filipe Correia, F. Duarte, Sorin Sbarnea, cincth@… 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 (28)

comment:1 Changed 17 years ago by Alec Thomas

Component: TracHacksRequest-a-Hack
Owner: changed from Alec Thomas to anybody

comment:2 Changed 17 years ago by anonymous

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

comment:3 Changed 17 years ago by anonymous

I support this also.

comment:4 Changed 16 years ago by Leandro Conde

Me too ... it would be great

comment:5 Changed 16 years ago by anonymous

I vote for this

comment:6 Changed 16 years ago by anonymous

Priority: normalhigh

comment:7 Changed 16 years ago by Jay

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 16 years ago by anonymous

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

comment:9 Changed 16 years ago by anonymous

Cc: Filipe Correia added; anonymous removed

comment:10 Changed 16 years ago by anonymous

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

comment:11 Changed 15 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 15 years ago by soenke.brecht@…

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

comment:13 in reply to:  11 Changed 15 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 15 years ago by Jay

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 15 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 15 years ago by flavour@…

Trac Release: 0.100.11

Another +1 for this fucntionality :)

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

+1 for this functionality!

comment:18 Changed 15 years ago by Ryan J Ollos

Cc: Ryan J Ollos added

comment:19 Changed 15 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 15 years ago by F. Duarte

Cc: F. Duarte added

comment:21 Changed 14 years ago by anonymous

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

comment:22 Changed 13 years ago by Sorin Sbarnea

Cc: Sorin Sbarnea 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 13 years ago by Ryan J Ollos

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 years ago by arci

it sounds great! +1!

comment:25 Changed 11 years ago by anonymous

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

comment:26 Changed 9 years ago by Cinc-th

I added a description how to do requirements management using already existing plugins to Edgewalls Trac. Have a look at

trac:CookBook/Configuration/RequirementsManagement

comment:27 Changed 9 years ago by Cinc-th

Cc: cincth@… added

Forgot to CC me...

comment:28 Changed 4 years ago by Ryan J Ollos

Cc: Ryan J Ollos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain anybody.

Add Comment


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

 
Note: See TracTickets for help on using tickets.