它总是说要求应该是可追溯的，但是当我们谈论敏捷开发时，这是非常困难的。 我的问题是如何在敏捷，特别是测试第一开发或测试驱动开发中管理需求可跟踪性（或需求变更管理）？
答案 0 :(得分：3)
在TDD或BDD（行为驱动开发）中，您的要求会在测试中捕获。
您可以根据实际要求（更多TDD模型）映射测试，或者实际使用测试作为产品的要求（更多BDD模型）。
有关使用BDD和测试作为需求的功能的一个很好的示例，请从Ruby / Rails世界中检出RSpec和Cucumber。
在FDA监管的环境中工作，负责质量工程，我可以告诉您，TDD / BDD非常适合FDA审核员正在反对的模型。
BDD模型允许您追踪：
答案 1 :(得分：2)
当需求发生变化时，测试会发生变化。请记住，测试是活文档和需求规范。因此，变化是无缝的。
例如：需求更改会导致测试期望更改，从而导致代码更改。
答案 2 :(得分：1)
可能是我遗漏了一些东西，但TFD或TDD处于单元测试级别。在我看来，您所指的是由Traceability matrix和/或acceptance tests管理的。
答案 3 :(得分：0)
敏捷可追溯性一开始就非常棘手，目前有很多工具可以通过记录用户故事或从用户故事或测试中的TDD生成需求来提供可追溯性。
当我们考虑任何敏捷方法时，不必强调文档（请阅读Agile Manifesto。因此，我不确定敏捷如何具有可追溯性并且还简化其核心原则。
答案 4 :(得分：0)
最近在线找到了一个可跟踪的需求管理工具。 [http://code.google.com/p/ultimate-trace/ Ultimate Trace]试一试。它为我们节省了大量维护可追溯性的工作。
答案 5 :(得分：0)
重新阅读宣言。它更重视四个陈述中的右半部分，但请注意，“左边有价值”。这意味着文件本身并不是邪恶或被禁止的，它们应该谨慎地看待，不应该否定工作的真正目的。话虽这么说，电子可追溯性工具已经存在多年，一些更优雅和一些绝对的野兽。从测试用例追溯到定义它们的故事很重要，特别是当系统进入R＆amp; M时。否则，随着系统的发展，您需要追讨系统的文档，以追逐系统的组件。可跟踪性可以通过命名约定，配置/代码基线工具的某些功能，测试套件工具或RTM来处理。旧的，旧的学校方法是一个电子表格（请切开我的手腕），但我们已经走了很长一段路。