Hello Chris, I really would like to see this, too. Sincerely I'm not a python expert and can't provide any help. Perhaps I could sponsor a developer with some money. I already tried to find a half time student to extend our trac installation, but python doesn't seem to be the most wanted language in high schools.
Anyway, when I thought about this, I also came up with a custom ticket type (or something new that is based on the current ticket system), specialized to the task of tracking requirements. Alternatively I had the idea of building a set of hierarchical Wiki pages, that are created from a template and some macros to provide details about all requirements in a module on the "title" page. But in both cases I found the problem, that the "history" of each page can be viewed, but not in the sense of a label. Requirements change, and I very often need to to know the state of all my requirements in a specific version of the software. And you will also never achieve, at least in a dynamic system, that your requirements are documented to the last detail at the time when you release your software. So you need to link specific versions of your requirements to specific revisions of your source code. And you need to change older version of the requirements (aka branch). And then we have the old question again, why not store the information in the subversion database directly, so the requirements will travel with the source. But anyway, I would love to see such an improvement for trac. And I think most of the functionality is already there. My requirements ;-) would be: * Ability to freeze the state of all requirements at the time of the release for this specific context * Every requirement should have a customizeable set of "sections", e.g. a "testplan" or "manufacturing instructions" * Ability to automatically generate a complete testplan for all requirements at the time of the release * Tabular overview with short description for all requirements * manual assignment of a requirement number to fit old existent numberings * Talking about testplans: Each test could be a specialized form on itself, that is linked to the requirement. * Ability to link ticket, requirements and testplans Best regards Dirk Chris Shenton schrieb: > I support some folks who I've gotten into using Trac for feature > requests, issue tracking, etc. We have historically gathered > requirement in spreadsheets or similar, collecting features, > importance (mandatory, preferred, optional), relevant SW component, > target version, etc. It seems to me that I could use Trac to more > effectively collect, document, and track progress on Requirements. > > I was planning on a new ticket Type of "requirement", and a priority > of "mandatory", "preferred", "optional", then a component for each of > our SW subsystems. Reuse the Milestone for target versions. Assign > to developers as normal. > > Text fields in tickets would allow us to describe the high-level goal > in the ticket subject, and we could provide rationale, use cases, and > progress notes as normal. Seems like it would be a good fit. > > Are any of you using it for Requirements? Any words of wisdom? Things > that work really well? things that didn't work for you? > > Thanks. > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
