1、 需求遵守方法论

　　需求分析规程越规范、正式，测试过程越简单。需求过程通过一个预定义的方式来收集、分析事实、做出判定并记录需求，并将用于设计过程中。

　　测试内容：

　　1） 是否标识出适当的组织政策、标准和规程；

　　2） 是否根据需求方法记下需求；

　　3） 系统操作期间是否会有新的标准、政策和规程生效；

　　4） 需求阶段的人员是否与规程一致；

　　5） 所有的标准、政策和规程进入系统是否会有效。等……

　　2、 定义的功能说明

　　用户的满意情况只能在达到系统目标之后才能确定。而达到这些目标也只能在目标是可度量的时候才能进行度量。定性的目标（如：可靠的稳定性、性能良好等）不是可度量的目标，而定量的目标（如：在0.002秒进行过电压保护功能）是可度量的目标。

　　测试内容：

　　1） 收集的应用程序所需的数据是否达到了所需的可靠性水平；

　　2） 是否在指定时间段内收集了数据；

　　3） 是否以书面的形式定义了用户的需求并确认；

　　4） 需求的说明是否可度量；

　　5） 项目的解决方案是否解决了需求；

　　6） 是否将可度量的目标应用于系统分为手动和自动的；

　　3、 确定可用性规范

　　使用系统所必需的工作量和技术水平都应该在需求阶段确定。经验表明，不会经常使用到那些难以使用的应用程序或功能，而经常会用到易于使用的功能系统。除非把易于使用的规范包含在技术规范中，否则默认情况下，该规范将由系统分析人员工编辑人员创建。

　　测试内容：

　　1） 是否标识出用户的技能水平；

　　2） 在设计用户功能时是否采纳了行业心理学家的建议；

　　3） 是否在需求阶段与用户工作人员进行交谈以确定他们所关心的问题；

　　4） 是否标识出用户责任是否提交给用户来评论。

　　4、 确定的维护规范

　　与发生最有可能更改区域一样，还应该具体确定预计的维护程度。随后，规范将确定维护的方法（比如：用户引入的参数整定）以及时间跨度，在该时间跨度内需要安装某种维护修改；比如：电子商务系统中，价格的修改必须对在信息服务进行修改后的24小时内是可操作的。

　　测试内容：

　　1） 是否定义了项目预期的寿命；

　　2） 是否已经定义预期的修改频率；

　　3） 是否定义了保持系统更新功能的重要性；

　　4） 是否决定有谁来执行项目的维护；

　　5） 是否标识出预计的最大修改范围；

　　6） 是否标识出在开发过程中引入修改的方法；

　　7） 为了维护而正确记录现场的实际情况是否包含了相应的条款。

　　5、 确定可移植性的需求

　　在不同类型的硬件上运行系统的能力、随后把系统移植到另一种硬件上的能力，或是把系统软件从一个版本移到另一个版本中的能力都应该详细陈述出来，作为需求的一部分。应该把应用程序开发成一种可移植的程序，这种需要将显著成为影响到需求的实现。

　　测试内容：

　　1） 在项目周期内是否发生硬件的重大变更；

　　2） 在项目周期内是否发生软件的重大变更；

　　3） 应用系统是否会在多个地点运行；

　　4） 如果是在线应用程序，那么是否会使用不同的终端；

　　5） 所建议的解决方案是否依赖于特定的硬件/软件；

　　6） 应用程序是否会应用于其它国家；

　　7） 是否把可移植性记录到文档中。

　　6、 定义系统接口

　　应该定义将作为来自其他计算机系统输入的信息以及传递到其他计算机系统的输出。这种定义不仅包括传递信息的种类，还包括了接口的时间安排以及作为接口结果发生的预计的处理。其他可能需要处理的接口因素包括隐私、安全以及信息的保留。

　　测试内容：

　　1） 是否标识出从其它应用系统接收的数据；

　　2） 是否标识出将用于其它系统的数据；

　　3） 是否定义了接口数据的可靠性；

　　4） 是否定义了数据传送和接收时间；

　　5） 是否定义了接口的方法；

　　6） 是否把接口记录到文档；

　　7） 是否考虑接口系统对未来的需求。

　　7、 创建性能标准

　　应创建系统预计的效率、经济性和有效性。在创建了上述目标之后，用户不满意程序几乎可以保证和可操作系统一起发生。需求阶段的最终产品应该是源自应用程序的成本/收益的计算。根据应用程序系统的开发的成本计算信息，设计出相关性能标准规程，在该规程基础上进行开发。

　　测试内容：

　　1） 是否有其它组织的不确定性能软件和硬件；

　　2） 是否定义了性能/成本的关系；

　　3） 应用程序的性能是否引起由于项目的实际成本发生重大变化；