Opened 18 years ago
Last modified 5 years ago
#1226 new enhancement
Plugin for writing requirements and specifications of a software
Reported by: | 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 18 years ago by
Component: | TracHacks → Request-a-Hack |
---|---|
Owner: | changed from Alec Thomas to anybody |
comment:2 Changed 18 years ago by
comment:6 Changed 17 years ago by
Priority: | normal → high |
---|
comment:7 Changed 17 years ago by
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
This should also hook into the TestCaseManagementPlugin since in most workflows they are connected.
comment:9 Changed 16 years ago by
Cc: | Filipe Correia added; anonymous removed |
---|
comment:11 follow-up: 13 Changed 16 years ago by
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:13 Changed 16 years ago by
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 16 years ago by
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 16 years ago by
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:18 Changed 15 years ago by
Cc: | Ryan J Ollos added |
---|
comment:19 Changed 15 years ago by
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
Cc: | F. Duarte added |
---|
comment:22 follow-up: 23 Changed 14 years ago by
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 Changed 14 years ago by
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:25 Changed 11 years ago by
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
I added a description how to do requirements management using already existing plugins to Edgewalls Trac. Have a look at
comment:28 Changed 5 years ago by
Cc: | Ryan J Ollos removed |
---|
Yup, this would indeed be a very useful feature..