● 应用软件是在新的开发或维护环境中被测试？

　　● 谁着手与这个项目，以及全体的开发方法将遵从谁的。

　　● 这个系统必须什么时候投入使用？

　　● 什么是系统故障所含有的风险？（费用，信心，商机，等等）

　　● 什么是系统注重的主要功能？

　　这一系列潜在的问题是无止境的，因此要保持调查以便将问题小化。一旦了解了主要功能，那么辅助功能将会开始显示，你将应该制作文档并且进行下一步。

　　简要说明一下，如果是一个客户端/服务器应用软件，必须采取特别的考虑以便让项目组中的所有其他潜在参与者的参与进来－尤其是网络小组，他们将负责系统的通讯方面。

　　第二步：排列工作量（写规范）

　　规范可以简单列出每一条系统需求的大纲形式来写。如果团队有一个标准的格式来写规范的话，应该使用这一格式。获得需求的方法如下：

　　1）与应用软件的交付测试人员进行交谈，尽管迫使这个人履行诺言可能是困难的。

　　2）运行程序并尽可能的检查编码。

　　3）会见客户。（尽量小心，告诉客户你不知道他们试图完成什么可能不一个很好的策略）

　　4）回顾编程的注释和相关的东西，尽可能找到更多的文档。

　　从内容中得到提示，细读帮助屏幕，寻找叙述信息。如果是一个维护项目，设法确定系统中什么东西已经被更改或增加了什么，这样使你初的大部分测试停留在某些方面。你仍然可能得不到所有的需求，但这可以明确可以开始了。

　　当你会见客户或与编程人员交谈时，他们趋向于叙述通过列举所有的输入，通过必需的可知处理步骤产生预期的输出，而得到这个系统意图是什么。一种更有效的会见技巧是要他们通过列举系统的所有期望输出而开始的。确定输出提供了一个系统实现目标的理性认识，并且开始了鉴定系统测试计划和验收测试计划内容的过程 。这些输出包括：

　　● 报告
　　● 屏幕/显示
　　● 消息/界面
　　● 文件
　　● 声音（音频信息）

　　下一步讨论系统的输入接着便是产生输出的必需处理步骤。记住当提供了理想的系统需求，没有说明书我们要逆向确定需求是什么？如果当测试计划得到评估，每个需求将得到确认。

输出            输入             方法
 


图一：会见方法

　　一旦创建了整个系统的图示，则到了逐步展开评估的时候了。管理必须见多识广以保证能做出好的决定。

　　排列工作量的产物将是一个文档，文档充分详细的列出了每条系统需求，这些细节能让其他小组回顾工作以及项目评提供了帮助。需求的定义将要完成是不大可能的，但是然而，现在它们是建立了功能说明和设计文档的基础，这让将来的任何升级变得便利。

　　接下来的样本文档包含了风险评估以及测试应用软件的相关费用。虽然在某些方面可能没有完成，它提供了一个机会给其他人在复阅时填写缺少的要素。