为了验证软件系统满足客户需求，测试员必须清楚地知道并理解需求。但是，通常测试员往往是在不了解需求的情况下进行测试的。

        在缺乏需求的了解的情况下，测试员往往需要猜测软件系统应该做什么。测试员的测试经验和业务经验能增加猜中的机会，但是猜测意味着遗漏。

        测试员对功能需求的了解越少，测试过程中对用户界面的关注会越多。这也是很多测试员仅仅只能发现界面交互类型的bug的原因，虽然界面可用性非常重要，但是可用性必须跟功能需求关联才有意义。

        对于一份组织结构良好的需求文档，测试员能更快、更好地找到需求项。但是我们往往过多地关注需求文档是否组织得良好，而忽略了需求文档的质量以及需求内容本身。

        一直以来，某些软件工具厂商都在灌输需求管理的概念：有效的系统开发依赖于需求管理的应用。当然，测试员和程序员都会受益于这些需求管理的工具，使得他们能更好地知道有哪些需求。但是需求管理工具在需求内容的正确性方面能做的事情相当少。测试员在需求阶段应该扮演需求评审员的角色，对需求进行评审。但是需求管理工具在需求评审方面能做的事情相当少，顶多是提供个输入评审注释的功能。一些新的需求管理工具提供文本分析功能，定位需求不清晰和前后矛盾的问题，但是还是过于格式化了。需求很可能是清晰的一致的，但是却是错误的。

        在很多项目的需求分析和评审阶段，测试员不会参与进来。但是这样的做法往往忽略了很多东西，例如：不熟悉系统相关业务的测试员可以通过需求分析和评审获取更多有关的领域知识；需求的可测试性没有得到很好的评估，可测试性是清晰性的一种形式。

        最近，重心好像在转移，更多人的关注点转到了定义需求的内容上。测试员确保对需求非常熟悉和理解的唯一途径就是去定义需求。由此带来了一些争论，诸如：这样做是否存在多余的工作；测试员是否有合适的需求分析技巧；以前这个阶段的测试力量是用在测试，现在用在需求分析对测试带来的影响。

        一些工具也在帮助需求的内容定义，我想这些工具一定会比“面向格式”的需求管理工具获得更多的注意力。

        但是最重要的需求管理工具应该是人与人之间的沟通和交流。