您需要的是改进您的需求工程流程。在这方面有一些商业工具可以提供帮助（几年前我曾与 Doors合作过），但我不知道我可以推荐任何开源替代方案。

问题是这些工具和流程非常“重量级”，在我看来，实现对代码和向后的需求可追溯性非常昂贵¹并且对于不符合任何标准合规性的软件可能不值得（例如，DO-178B等安全要求）。

笔记

¹需求可追溯性虽然使用一些代码生成工具应该是可行的，但我没有这方面的经验，恐怕这也超出了你的问题范围。

“我们总是忘记处理过去几年实现的所有众多功能”

如果事情经常被遗忘，这不是工具问题 - 这是一个过程问题。您的过程似乎不需要在可访问的地方跟踪这些内容，并且功能列表保持最新。

我们使用 SharePoint 来保存我们的功能/要求。当它维护良好时，我们可以将其用于影响分析。当它不被维护时，我们不能。

我通过在 wiki 中维护书面测试用例来解决这个问题。每个测试用例都是一个声明性语句。（我工作过的地方是逐步详细记录测试用例，但我发现当功能发生变化时维护细节太难了，就像他们经常做的那样。）如果你搜索 SQA 或 Google，你会发现其他书面测试用例的结构。通过一些思考和实验，您可以找到适合您自己组织的。

两三年来，我是我小公司里唯一的测试员。当我们的第二个测试员加入团队时，书面测试用例让她能够比其他方式更轻松地学习产品。

我在记录测试用例方面的成功率较低，以至于很容易将新需求映射到受影响的测试用例。您可以通过使用相关产品组件标记测试用例（或测试用例页面）来获得其中的一部分，但选择适当的标记粒度 - 既不太高级也不太低级 - 更容易说比做。

有很多方法可以跟踪需求。要考虑的非常重要的事情是从思想/需求分析的开始就跟踪需求和变化，否则它可能会成为一件代价高昂的事情。

需求分析辅助工具-

1. Excel 工作表有时可能是跟踪需求和影响分析的最简单方法。
2. 我使用了 HP Quality Center，它确实是一个非常好的 ALM 工具，用于需求跟踪能力和影响分析。
3. 我没有使用过 Doors，但这可能是另一个不错的选择。

过程：

1. 对需求/用例/故事进行分类。
2. 为每个类别起草与依赖关系列表相关的要求。
3. 创建一个以需求和依赖项为基础的矩阵。
4. 影响分析应该考虑所有的依赖关系。
5. 因此，每当围绕特定分类功能的需求发生变化时，必须考虑所有依赖关系，并且必须处理所有相关的需求/故事/用例。

由于您提到每 2 周发生一次更改，因此避免意外中断和遗漏任何依赖功能的另一种方法是遵循持续集成测试驱动开发，当您提交更改时将识别任何中断和依赖问题构建。

即使经过完美的影响分析，您仍然可以看到问题，但控制问题应该是目标。