软件验收计划

一、项目描述

  项目描述定义要开发的应用以及期望该应用要实现的目标。还可能定义需求的总体描述，不需要非常详细

二、系统类型

   1、影响生命的系统：对人类的健康或生命有直接关系的系统是影响生命的系统。医疗和航空领域的应用是少数属于这类应用的例子

   2、影响大量金钱的系统：会对大量金钱有直接影响的应用属于这一组应用类型。股票市场应用和在线银行软件是属于这一类型的例子。

   3、需要模拟器测试的系统：有一些软件在真实环境下无法进行测试。模拟将会导致带来一些风险。

   4、其他系统：不能归类到上述几个类型的系统都被认为是“其他”系统。

三、开发使用的生命周期方法学

   1、瀑布模型可以用于生命周期验收，因为每一个开发阶段都很清楚的区别标志。在这种情况下可以使用阶段结束的严重和确认技术。

   2、由于迭代开发模型存在多次迭代过程，需求永远不会冻结，因而增加了验收的开销和风险。在每一次迭代过程中可能会存在一些特殊的验收规定。

   3、螺旋开发模型会在增量上增大验收的风险。如果在每一轮迭代中遵从瀑布模型，可以在某些程度上降低风险。

   4、敏捷开发模型工作在协作模型上。当客户与供应方关系融洽时，这种模型将会十分成功。在每一个阶段或者可交付的层次上都可能会有一个正式的验收。

  用户可能会试图在制定验收标准的过程中避开方法学的缺点。

四、开发进度表

   开发进度表也可以被用于确定验收标准。在生命周期的验收中，当完成不同的开发阶段后，依据这些阶段的验收标准决定是否接受/拒绝本阶段。短的交付日程表要比周期很长的交付项目更有利于验收，因为错误可以很快地被修复并且反馈可以及时应用到下一步的开发活动中。开发进度表有助于客户确定何时期望交付产品，并且给出产品的验收测试结论。

五、系统的用户群

  系统的用户群指的是确定系统是否易于使用的用户类型。如果用户是盲人，验收测试可能就要考虑用户群的这个特征。环境必须要反映出实际的用户环境，测试人员在实施验收测试时必须能够真实地代表用户。

六、主要任务系统必须要满足性能要求

  这意味着业务上的关键需求必须要满足。如果在这些范围内发生失效，将会直接导致该系统被拒绝。这些需求必须在验收钱确保已被满足。

七、系统的主要外部接口，例如其他系统、硬件和人员。

  系统可能会在多个环境下运行，并与许多其他的系统交互，例如数据库、操作系统和浏览器等。另外，系统还可能要建立一些诸如消息系统之类的与其他系统的接口。系统还必须要与用户进行交互。符合这些参数要求的系统会更加成功。验收标准必须要对这些需求作出规定。

八、系统期望的正常使用方式和对系统的依赖

  正常的使用方式会规定系统在正常负载情况下的系统性能，以及在整个使用期间的负载变化情况。如果系统非常关键，对业务运行有无可替代的作用，系统的依赖程度就很高。如果实际负载明显超出正常使用情况，系统就可能会在相应时间上出现故障。相反地，如果实际负载比期望负载低很多，这类系统的开销就不合理。系统设计对于性能和负载来说都是非常重要的。

九、授权/未授权用户会系统可能的错误使用

  软件应用可能会被为授权用户使用，并导致机密信息发生丢失。同样，软件也有可能会被授权用户错误使用。都有可能会导致出现业务损失或违反规章制度方面的需求。在这两种情况下，都必须在需求描述中定义安全需求，并且在验收测试中验收是否满足了该需求。

十、系统开发和使用面临的风险和约束

  任何一个开发/使用活动都面临着风险。同样，任何一个代替人的系统也面临着风险。除这些风险之外，在开发生命周期和系统使用过程中还存在着一些约束。验收测试计划必须记录下一般用户，业务等由于引入该系统而面临的所有可能的风险。开发人员必须了解系统相关的所有限制，例如技术限制、性能限制、内存限制等。

十一、使用系统的业务所遵从的标准和实践

  通常，业务的标准和实践都是在法律需求和操作需求中定义的，这些都包括在系统需求规范的制定过程中。这些需求的重要性有时会发生变化，因而需要根据标准定义这些要素的适用性和可修改能力。由于标准会不时的进行修订，系统也必须能够适应这些改变。