测试需求的确定将为我们制定测试进度时间表、分配资源以及确定某个阶段测试工作是否完成提供一个可供衡量的标准。当然，还有更重要的一点，已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖率的依据。
需求的整理：
(1)确定测试工作的范围；
(2)整理测试需求；
(3)“测试需求”和“测试设计”。
我们可以从文档对软件特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户的实际业务是如何进行的？多个业务之间是否存在相互关系？在业务进行时是否受到一些条件的影响？等等。通过对这些业务的分析，我们可以获得最初的一部分测试需求。你可以将测试需求定位在较高的层次上，也可以把你所能想到的所有需要测试的内容都写下来，而并不一定是仅仅局限于对一个特性或一个由基本流同某些备选流组成的场景的分析。这里强调的是基于业务的分析，换句话说，就是考虑在用户处理实际业务时将会做些什么。所有的测试都应追溯到用户需求。因为软件的目的是使用户完成预定的任务，满足其需求，而软件测试揭示软件的缺陷和错误，一旦修正这些错误就能更好地满足用户需求。
测试需求的主要来源是软件需求文档和软件设计文档，所以我们在整理测试需求之前，就不能不考虑软件需求文档和软件设计文档中描述的内容本身是否存在缺陷。而对需求和设计本身的检查，也就不可避免了。
具体工作中的输入文档：
(1)软件需求文档；
(2)开发设计文档，包括逻辑、数据的来向和去向；
(3)功能分解：依上述两条绘制的业务地图、菜单树等。
