如何管理 Visual Studio Team Services (TFS) 的需求（规范）？答案

【问题标题】：How to manage requirements (specifications) on Visual Studio Team Services (TFS)?如何管理 Visual Studio Team Services (TFS) 的需求（规范）？
【发布时间】：2016-03-04 10:26:19
【问题描述】：

我正在使用本地 TFS 并计划迁移到 Visual Studio Team Services。但我还有一个问题——如何在 VSTS 或 TFS 中正确管理（存储、编辑、跟踪）软件项目的需求（规范）？

什么是最好的解决方案？你用什么？

现在我们使用 OneNote.com 并将 OneNote 页面的链接添加到 TFS 中的 PBI。但这不是很方便。

【问题讨论】：

这个话题太宽泛了，在这里无法完整回答。

标签： tfs requirements azure-devops

【解决方案1】：

需求管理是一个非常广泛的主题，但是在查看 Team Services 和 TFS 的功能时，您会发现它在 Scrum 和敏捷模板中支持非常轻量级的需求管理。如果您需要进行正式的需求跟踪，那么 PBI 和用户故事并不是捕获它们的理想方式。主要原因是，虽然这些项目在开发时是正确的，但随着其他 PBI 和故事引入互补/矛盾的行为，它们会变得陈旧/过时/不正确。

CMMI 模板更适合正式规范，使用需求工作项类型并进行正式变更跟踪。它仍然打算以敏捷的方式使用，但由于它希望您跟踪和指定的所有额外内容，它往往会将真正的敏捷团队赶走。

在产品本身中，您可以使用 Markdown 支持并将需求存储在额外的源代码控制存储库或具有完全更改控制的 Git 存储库中。您可以将附件添加到工作项目（包括 Powerpoint 故事板），但任何相当于厚文档的内容都不是产品的一部分。

您当然可以链接到 o365、OneNote.com 或 Google Docs 来跟踪您的规范，或使用 3rd 方产品，例如 ModernRequirements。

请记住，在敏捷中，我们尽量将规范保持在最低要求，并且它主要用于确定要做什么（计划和跟踪工作）。如果您需要捕获正式的规范，则需要另一个地方来存储它们。

【讨论】：

【解决方案2】：

TFS 和 VSTS 包括工作项管理。我们使用用户故事来定义工作，并使用看板来跟踪工作进度。

【讨论】：

工作项跟踪不是正式需求跟踪的方式。它非常适合计划和简单的统计跟踪，但它不是真正的需求工具。使用 CMMI 模板时可能会接近，但这会带来很多其他开销。
我同意@cheif7。它需要更好的 UI 来捕获表单布局、字段、验证标准。我想使用 Visual Studio Team Services 来管理它，所以除非我可以自定义工作项的文本框，否则我需要附加这样的表单。不光滑！
现在在 VSTS 上启用了全流程定制。