Trac 的需求管理插件？
是否有 Trac 的需求管理插件？我检查了 Trac-Hacks 上的列表，但没有看到任何
我想象的一些功能，例如 IBM 的 DOORS 系统。基本功能包括需求的修订和变更控制、需求基线等。
更新：我想我可以使用 Trac 的 wiki 部分来记录需求，但这不允许对需求进行任何类型的更改集需求 - 例如，单个需求已更改，但开发人员正在根据需求尚未更新的基线进行工作。它还不允许链接需求，这样当父需求发生更改时，必须在接受更改之前检查所有从属需求（以便保持从属需求同步）。
Are there any requirements management plugins out there for Trac? I checked the list on Trac-Hacks and didn't see anything
I'm picturing some functionality like IBM's DOORS system. Basic features include revisioning and change control of requirements, requirements baselining etc.
Update: I suppose I could just use the wiki portion of Trac to document requirements, but this doesn't allow anykind of change sets for the requirements - for example where a single requirement has changed but developers are working against a baseline where the requirement hasn't been updated yet. It also won't allow linking requirements such that when a parent requirement changes, all dependent requirements must be reviewed before the change is accepted (in order to keep dependent requirements in sync).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
@retracile：感谢这个“如何做”。我刚刚发现 rmtoo 进行基于文本的需求管理...顺便说一句，回顾一下它，它还VCS 集成功能与 Trac 一样，是用 Python 编写的。
@retracile: thanks for this "how to". I just discovered rmtoo which does text based requirements management... and btw, looking back to it, it has also VCS integration features and, as Trac, is written in Python.
当您开始谈论修改需求时，我认为您确实需要退后一步，将您的需求视为源代码树的一部分。找到 SCM 可以处理的需求的文件格式（基于文本等），然后将它们签入。将它们视为代码的早期部分......当需要弄清楚需求是什么时v2.0，创建 v2.0 分支并开发该分支的需求，然后在同一分支上进行代码开发。
如果使用基于分支的开发，请在分支上创建需求，在同一分支上创建代码，然后合并分支。这使需求和实施保持同步。
When you start talking about revisioning of your requirements, I think you really need to step back and look at your requirements as part of your source tree. Find a file format for the requirements that an SCM can handle (text-based, etc), and just check them in. Treat them as the early part of your code... when it's time to figure out what the requirements will be for v2.0, create your v2.0 branch and develop the requirements on that branch, and follow it with your code development on that same branch.
If you use branch-based development, create the requirements on the branch, create the code on the same branch, and then merge the branch. That keeps requirements and implementation in sync.