测试需求流程管理是否适宜，有多重要？团队成员将以怎样的方式，收集并管理需求才能促进测试？

适当地管理需求对开发和测试都非常重要，但也不并像某些资源，主要是工具宣称的那样的重要。与许多流行语一样，需求管理的使用人员也不同，也即意味着不同的事情——通常不用了解已有的差异。有些人使用“需求管理”这一术语指代整个需求流程；依我拙见，这并不准确。

我发现，把确定为捕捉、分类、跟踪和控制需求变化的机械行政行为更为确切。需求流程涉及到更困难，更重要的识别和评估需求内容的步骤。

为免你认为我独自一人在做这些区别，要知道大多数需求管理自动化工具只具有前者的功能。即使那些确实适用于需求定义的工具，通常也要通过构建需求用例，并确认是否缺少不同的结构元素。注意，原始能力成熟度模型拥有二级关键流程域，称作“需求管理”，而它的继承者，能力成熟度模型集成，增加了更高的三级“需求开发”关键流程域。

也许最常见的需求管的执行区域工具是一个跟踪矩阵。跟踪矩阵显示了需求从哪里来，以及它使用的所有地方，如各种设计组件和测试。这会身体力行地去捕捉每一个交叉引用。所有的自动化工具帮助维护交叉引用，但工具不能帮助确定一定要捕捉什么样的交叉引用。这些工具可以从枯燥的工作中节省出IT，能过促进当前的跟踪矩阵版本，当交叉引用数据在工具中手动更新时，如当测试通过或失败时。

工具厂商尤其容易夸大跟踪矩阵的值。从需求开始向前跟踪，可以揭露一些根本没有做测试的人员；从测试或组织开始向后跟踪，可以揭露那些似乎与需求不相关的人。从实用性上讲，工具只追踪高级需求，与测试相关的每个需求足以产生一个检查标志，标示它已经进行测试。这绝不代表那些测试是彻底的、充分的。

更精准的需求和测试的关键主要在于定义，其次才是管理。当然，了解事情改变的时间很关键。这是需求管理的另一面，同样限制改变也是。但控制改变的更好方法是，最初就使需求内容更精准。

需求提供了一个值，当实现产品、系统或软件的设计来满足它时。有效和测试展示了已经设计和实现的产品在实际中满足了这一需求。然而，许多测试仅仅展示产品如设计的那样实现，而其本身并没有价值。

优先化需求并定义他们，达到明确可测试点，从而提升了正确的产品将会正确建立的机率。它还提供了更多的测试点来确认产品构建正确。跟踪更详尽的需求测试将会增加测试覆盖率的信心，但它仍然不会告诉你测试的充分性如何。这些细节中的一些跟踪，因为粒度越大，而致使识别和捕捉交叉引用耗时也越长。