我们的团队是 TFS2010 的新手。从历史上看，我们使用自己的业务需求矩阵（可追溯性矩阵）Excel 电子表格。它具有典型的列，例如：
需求 ID | 项目 | 规则组 | 业务规则 | 类型...等
我们的业务规则列如下所示：
- “该系统应提供一种允许参与者搜索研究的方法。”
- “系统应提供允许参与者搜索项目的方法。”
- “系统应为入站包裹生成移动活动。”
- “要导入条形码清单，系统应在每个样品占位符中包含一个代码，说明样品是由条形码清单创建的。”
由于我们行业在文档、审计等方面的严格要求，我们选择了 MSF for CMMI 而不是 MSF for Agile 作为我们的流程模板选择。
我们就在 TFS 2010 世界中实施“我们的工作方式”的最佳方式进行了多次讨论。我们问题的症结似乎归结为以下几点：
- 看来我们应该遵循“实施”选项卡中“需求”->“任务”之间的“父/子”关系。然而，这意味着我们对每个需求都有一个任务（这似乎是多余的并且过于细化）。
- 我们喜欢将任务视为不那么细化的东西（即“开发出站控制台屏幕”。）
- 我们希望开发人员能够查看分配给他们的任务，并轻松查看与这些任务相关联的需求（功能性和非功能性）。
- 可追溯性是一个高优先级，但是，我们不一定需要它非常精细（细化到实际的代码行）。正如我们所看到的，这样做会使开发变得极其乏味和适得其反。我们希望在这方面取得合理的平衡。
我们的方法真的像它看起来的那样是圆钉子吗？或者，我们只是误解/遗漏了什么？我们觉得我们对各种工作项类型有很好的理解。
为了添加更多上下文，我们的理解是“功能”类型的需求是更精细的需求（例如功能性、非功能性、QoS）的“父级”。我们知道 Scenario 的 Requirement 类型类似于用例。
因此，我们认为 TFS 2010 遵循以下层次结构：
- 要求（功能）
- 要求（功能）
- 任务
显然，对我们来说的问题是，虽然我们在某些方面想要 Requirement/Task 之间的父/子关系……但我们几乎看到需要同时将 Task 作为Requirements 的父级。
我们相信我们可以跳过 Implementation 选项卡（以及它强制执行的父/子关系）......而只需使用 All Links 选项卡。这使我们能够更灵活地通过其他链接类型（例如“相关”或“影响/受影响者”）关联需求和任务……但是，最大的问题是它破坏了内置的 TFS 2010 报告（尤其是关于跟踪需求进度/小时）。
任何见解都值得赞赏。