在各种项目中，我需要确保我在分析阶段开发的用例模型涵盖了项目的需求。为此，我能够在需求语句（唯一标识）和用例（也唯一标识）之间进行一定程度的可追溯性。在某些情况下，启用可追溯性意味着我认为（后来证明）一些额外的努力是一项很好的投资。
现在，我面临的最大问题是在事情开始发生变化时（作为更改请求的结果，或作为用例更改的结果），在以后保持这种可追溯性。
任何关于可追溯性维护的最佳实践的想法？
（它可以应用于项目中的其他项目——例如用例和测试用例，或需求和验收测试用例）
稍后的编辑 工具可能会有所帮助，但它们无法检测可追溯性中的差距或错误。导航......也许，但不保证可追溯性在应用更改后是最新的或正确的。
我认为可追溯性是需求中最难管理的事情之一，其次是首先确保需求是正确的。以我的经验，最好的追溯工具是人。
我没有灵丹妙药；只是一些过去对我有帮助的提示。
三年前，我们使用了一个 Rational 工具来编写需求。在这些工具中，许多功能都与可追溯性有关。
我们发现这些工具的可用性并不完美。尽管它们确实提供了我们需要的基本功能，但我们浪费了很多时间来解决它们的局限性。
我假设您没有询问代码的可追溯性，因此我将其排除在我的回答之外。
当您提到语句和用例的唯一 ID 时，您可能已经使用工具来管理它们。
本质上，一个简单的关系模型（可能在数据库中）可以涵盖您唯一标识的部分之间的关系。
我会寻找一个简单的工具来做到这一点。如果只有一个人可以修改它，它可能只是一张 Excel 表格！
请注意，链接两种文档类型可能还不够。
您提到了 5 种类型：语句、用例、测试用例、需求和验收测试用例。
我们一直需要传递性（在关系世界中，到 JOIN 表），以获得包含几个步骤的视图。
有多种可追溯性需要维护：系统需求到子系统需求、设计需求、验证需求（最重要的一项）、代码需求、问题需求等。
Word、excel 和一个好的问题跟踪系统有很长的路要走。但是当您需要显示可追溯性时，它们可能会很痛苦。手动维护可追溯性容易出错且劳动强度大。IBM Doors 系统是我迄今为止使用过的最好的工具。但它们很贵。我们最近发现了一个运行良好的系统Ultimate Trace。
您想在需求声明和每个用例中添加一个版本号 - 与所有人交流并存储在某个易于访问的区域（物理和/或计算机/网络）中的最新版本。您将需要添加一个更改文档，其中包括先前的需求声明和/或用例是什么，何时更改，由谁和谁批准。
因此，在查看需求规范和用例时，您/所有人都有最新的观点，如果对变更有疑问，您可以参考变更文档（不要用历史信息使需求或用例规范负担过重，但以易于访问、有意义的形式保留历史信息作为参考）
我想说最好的方法是使用错误跟踪器。每个需求都被跟踪为一个错误，开发修改与之相关联，并且可以使用错误注释保存更改。
许多错误跟踪器允许您将多个错误关联在一起（例如作为重复项），因此这可用于将离散需求组合在一起并且仍然分开以单独跟踪。
如果您将所有其他工件存储在 SCM 中（即设计文档等），那么您也可以通过将它们与需求相关联来跟踪它们。
有一些工具可以帮助解决所有这些问题，但我发现这些“完整生命周期”工具真的无法使用，因为它们试图在一个应用程序中做太多事情，或者作为“集成”在一起的相关应用程序，而且非常昂贵。