IPD_PSSD_T_0078 软件需求规格说明书检查表(面向对象技术)V2.1.xlsVIP

检查表 封面 软件需求规格说明书检查表(面向对象技术) 项目名称： 项目编号： 项目负责人: 文档修订记录 序号 版本号 变化状态 变更（+/-）说明 作者 日期 *变化状态：C――创建，A——增加，M——修改，D——删除，只有比较大的改动才需要版本记录 说明: 1. 每个检查项在执行情况列中有“是”，“否”，“免”三个选项，对于选择免的检查项要求在说明栏中解释免于检查的原因。 检查项 执行情况 说明 是否所有的分配需求都已在SRS中体现？ 在SRS中定义需求时，是否避免使用那些会引起歧义的术语，诸如也许、可能等，每条需求都清晰无歧义？ 是否在SRS中清楚地描述了软件要做什么及不做什么？ 是否在SRS中描述了软件使用的目标环境，指明并简短描述了目标环境中其它相关软件产品/子系统/模块？ 是否每一个具体需求都对应有唯一的编号？ 每一个需求是否切实可行、可测试、前后一致、彼此不冲突？ 每个具体用例是否至少涉及一个角色？ 用例的前置条件和后置条件是否说明了状态而不是事件？ 用例之间是否相互独立？ 如果两个用例总是以同样的顺序被激活，可能需要合并为一个用例。 用例之间是否避免存在非常相似的行为或事件流？ 如果存在 - 而且您还希望它们的行为在将来也相似 - 您应该将它们合并为一个用例。这便于在将来引入变更。 是否明确定义了用例之间的包含关系？（如事件流的一部分被构建为另一个用例的模型，应该让新用例使用旧的事件流； 或 事件流的某一部分成为另一个用例的组成部分，应该提取该分支流并让上述的用例使用它。） 是否避免将一个用例的事件流插入另一个用例的事件流中？ 如果是，利用与另一个用例的扩展关系来建立此模型。 用例的名称是否具有唯一性、直观性和自解释性，这样以后就不至于将它们混淆？ 是否明确说明用例的事件流开始及结束的方式和时间？ 用例的基本事件流和备选事件流是否可以到达相应的成功后置条件或失败后置条件？ 是否避免有过于复杂的用例？ 如果要使用例模型易于理解，您最好将复杂用例进行分解。 是否清楚地说明了用例与角色之间的交互信息？ 是否已经对系统环境中的所有角色都进行了说明和建模？ 系统中是否避免有多个主角担任相似的角色？ 如果有，可能需要将他们合并到一个主角中。 是否避免在一个用例中两个主角都能担任同一角色？ 如果有，可能需要利用主角泛化关系来为他们的共享行为建立模型。 特定的主角是否避免以几种（完全不同的）方式或目的使用系统？如果是这样，您也许应该有多个主角。 是否已经标识出用例模型的所有用例？这些用例共同说明所有的必要行为。 用例模型是否没有多余的行为？所有用例应可以被追溯到一个功能需求。 通过用例模型是否可以很容易地理解系统的行为？ 包之间的交叉关系是否被尽量减少或去除？这便于避免各种可能冲突的发生。 包的划分是否便于理解、合乎情理？ 是否在用例的特殊需求中明确了该用例的性能需求？ 是否在SRS中描述了软件所有的性能需求？ 是否所有的性能需求都可测量或能通过测试来进行验证？ 是否在SRS中说明了对系统可能的所有约束？ 质量属性是否以可测量或可验证的术语进行描述？ 是否在SRS中描述了系统中与其它子系统、模块或硬件设备的相关接口？ 是否对每个接口的描述足够清楚，实现时不需进一步的解释？ 是否产品总体设计方案书所对应的分配需求都在RTM中体现? 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 11.00 12.00 13.00 14.00 15.00 16.00 17.00 18.00 19.00 20.00 21.00 22.00 23.00 13.00 14.00 15.00 16.00 17.00 18.00 19.00 20.00 21.00 22.00 23.00