随着项目的发展，保持最新的可追溯性

Question

在各种项目中，我需要确保在分析阶段我开发的用例模型涵盖了项目的要求。为此，我能够在需求语句（唯一标识）和用例（也是唯一标识）之间具有一定程度的可跟踪性。在某些情况下，实现可追溯性意味着我考虑（后来证明）一些额外的努力是一项很好的投资。

现在，我面临的最大问题是在事情开始发生变化（由于变更请求或用例更改）后保持这种可追溯性。

有关可追溯性维护的最佳做法的任何想法？

（它可以适用于项目中的其他项目 - 例如用例和测试用例，或者要求和验收测试用例）

稍后修改 工具可能会有所帮助，但它们无法检测可追溯性中的间隙或错误。导航......可能，但不保证在应用更改后可追溯性是最新的或正确的。

Answer 1

我认为可追溯性是要求管理最棘手的事情之一，其次是首先确保要求是正确的。根据我的经验，最好的可追溯性工具是人类。

我没有任何灵丹妙药;对于过去对我有所帮助的一些提示。

• 将文档保存在每个人都可以轻松访问的中心区域。我不在乎它是Sharepoint，wiki还是网络驱动器（尽管如果可能的话我喜欢提供版本控制的东西）。将它保存在一个地方并推销它，这样每个人都知道去那里寻找答案而不是使用旧拷贝或打断开发人员。
• 如果您有管理工件或功能分组的中心联系人，那么这会有很大帮助。理解它们的人和问题将会知道要去哪里，要更新什么以及是否存在需要继续进行的依赖性。
• 工件的保管人需要承诺并保持最新状态。在我在网站上设置一些需求文档一年后，我仍然保持最新状态。我知道大多数开发人员都不愿意这样做，但在那之后的一年，我仍然从回顾那些看到功能需求随时间变化的方式中受益。
• 不是必需的，但有助于快速识别一段时间内的变化：如果有文档处理器的版本跟踪，请使用它。如果没有，我至少会包含文档的更改日志，或者仅使用对版本号的引用来标记新文本。
• 我曾尝试将依赖项引用放入我的工件中，例如对其他文档或工件的引用，但发现它们已经过时或难以跟踪，因此通常不会更新。纪律可以克服这一点，但我们大多数人都有太多事情要做，是吗？所以我认为在文档/工件之间的交叉引用中构建我想要一个工具或者一些尚未发布的免费需求管理工具来完成这项工作：）

Answer 2

三年前我们使用Rational工具来编写需求。 在这些工具中，许多功能都涉及可追溯性。

我们发现这些工具的可用性并不完美。 虽然它们确实提供了我们所需的基本功能， 我们失去了很多时间绕过他们的限制。

---

我假设您没有询问代码的可追溯性， 所以我从答案中排除了这一点。

---

当您为语句和用例提及唯一ID时， 您可能已经使用工具来管理它们。

本质上是一个简单的关系模型（可能在数据库中） 可以涵盖您唯一标识的作品之间的关系。

我会寻找一个简单的工具来做到这一点。 如果只有一个人可以修改它，它可以只是一个Excel表格！

---

请注意，链接两种文档类型可能还不够 您提到了5种类型：语句，用例，测试用例，要求和验收测试用例 我们经常需要传递性（在关系世界中，到JOIN表），以包含几个步骤。

Answer 3

需要维护多种可追溯性：子系统要求的系统要求，设计要求，验证要求（最重要的一个），代码要求，问题要求等。

Word，excel和一个好的问题跟踪系统有很长的路要走。但是当你被要求显示可追溯性时，它们会很痛苦。手动维护可追溯性是容易出错和劳动密集型的。 IBM Doors系统是迄今为止我使用过的最好的工具。但它们很贵。我们最近发现了一个运行良好的系统Ultimate Trace。

Answer 4

您希望在需求声明和每个用例中添加一个版本＃ - 将最新的版本＃传递给所有人并存储在一些易于访问的区域（物理和/或计算机/网络）。您需要添加一个更改文档，其中包括先前的需求声明和/或用例的内容，更改时间，由谁和谁批准。

因此，在查看需求规范和用例时，您/所有人都拥有最新的视图，如果对更改有疑问，您可以参考更改文档（不要过多地使用需求或使用案例规范）历史信息，但保持历史信息作为参考以易于访问，有意义的形式）

Answer 5

我想说最好的方法是使用bug跟踪器。每个需求都被跟踪为一个bug，开发修改与它相关联，并且可以使用bugnotes保存更改。

许多bugtrackers允许您将多个错误关联在一起（例如，作为重复项），因此这可以用于保持离散需求的组合，并且仍然可以单独跟踪。

如果您将所有其他工件存储在SCM中（即设计文档等），那么您也可以通过将它们与需求相关联来跟踪这些工件。

有一些工具可以帮助解决所有这些问题，我发现这些“完整生命周期”工具实际上无法使用，因为它们试图在一个应用程序中做太多，或者作为“集成”在一起的相关应用程序，并且非常昂贵。