想象一下，我将每个需求作为一个功能放在我的bugtracker上。这是一个好主意吗？有更好的工具吗？
答案 0 :(得分：5)
这就是我和很多人所做的。将规范作为错误，然后在它们是完整功能时解决错误。
它是评估解决错误与添加新功能的相对优先级的好方法。在某种程度上，一个空项目有很多错误，因为它没有任何！
答案 1 :(得分：5)
我想说这绝对是一个好主意，因为您可以在以后轻松追溯需求和想法的涵盖范围。您还可以轻松跟踪进度，时间估算，花费的时间等。
答案 2 :(得分：2)
错误跟踪就是关闭条目。产品/需求管理就是让它们保持活力。
BTW - 一些bug跟踪系统支持需求管理，但这不一样。答案 3 :(得分：2)
我们这样做 - 我们将Work Breakdown Structure (WBS)中开发的Marketing Requirements Document(MRD)转移到错误跟踪器中。然后，我们可以跟踪/监控各个工作项的进度。缺点是你可能在两个地方有需求定义，但对于像我们这样的小团队来说，这不是一个问题。
我们曾尝试过一次仅跟踪错误跟踪器，但是当我们需要将其交给外部用户和非技术用户时，我们发现很难重新构建完整的文档。
答案 4 :(得分：2)
这取决于您的需求跟踪要求可能有多复杂。完整的需求跟踪系统将支持许多级别的子需求，并可能与其他项目管理工具集成。如果项目很简单，因此您的需求不那么复杂，那么您可以轻松地使用错误跟踪器。
答案 5 :(得分：1)
总的来说，我认为使用像这样的跟踪系统来管理项目非常有效。
重要的是，您希望在数据库中放置可操作的项目 - 如果该要求不直接转换为您希望实现的代码/高级设计，则列出要求将无济于事。因此，对于一项要求，我可能会输入一个问题，将需求分解为功能，生成新记录以实现功能。
答案 6 :(得分：0)
Bug Tracker是针对缺陷的，包括文档。跟踪需求文档中的缺陷对于跟踪软件中的缺陷同样重要。越早找到缺陷就越便宜。
对于初始功能要求，我只会生成一个单独的跟踪器，如购物清单。当它们包含在列表中时，请检查该项目。
我为初期肥皂盒道歉，但很多人忘了文件也有缺陷，而不仅仅是软件。