2.需求规格说明书检查表.docx

PAGE PAGE #/11 评审检査表 文档修改情况记录 版本 修改状态 修改日期 修改摘要 修改人 冃录 TOC \o 1-5 \h \z 项H计划检査表 3 \o Current Document 需求规格说明书检査表 4 \o Current Document 概要设计说明书检査表 5 \o Current Document 1. 洋细设计说明书检査表 6 \o Current Document 5. 编码检査表 7 6? 测试用例检査表 10 \o Current Document 7. 产品验收和发布检査表 II 项目计划检查表 项目计划检查表 项目编号 工作产品 检査口期 检査人员 检查结果标記 /合格 X不合格 TBD待完成 NA不适用 检査情况 检査项：项；有效检查项：项；通过项： 项；通过率：— 序号丨主要检査项 1检査结果 1说明 标准化 1 有规定的文档标识 2 引用的文档现行有效 3 文档编写的内容、格式符合相关标准、规定 的要求 4 文档签署完整 完整性 5 文档有独立的版本说明部分 6 文档列出了项冃的验收标准 7 文档列出了项目组成员和项目相关人员、角 色、职责 8 文档选择了项目生命周期模型 9 文档选定了项目里程碑 10 对项目进行了估计（规模、工作量、进度、 关键计算机资源、成本） 11 进行了 WBS工作分解 12 文档作了项目的风险估计及风险管理计划 13 文档分析了项目所需的知识技能及培训计划 14 编写了配置管理计划 15 编写度星计划 16 编写质筮保证计划 17 使用project项目管理T具编写项目进度计划 符合性检査 18 风险管理计划的风险是否排序，对前三个是 否进行了分析，缓解计划是否合理 19 培训计划中的培训内容是否是项目蛆需要 的、可行的 20 配置管理计划中的配置库机构划分是否合 理，是否对开发过程中的工作产品进行J配 置项的设置  21 质量保证计划是否检查了列表,和开发计划 的进度是否一致 22 项目进度计划的T.作任务是否包括了生命周 期的所有工作（如：是否覆盖J所有需求的 设计和开发） 23 项目进度计划的资源和时冋分配是否合理， 里程碑的划分和交付物是否明确 承诺性 24 计划屮列出的相关人员是否都了解白己的角 色和职责，并在承诺记录上签字 需求规格说明书检查表 需求规格说明书检査表 项目编号 工作产品 检查日期 检査人员 /合格 X /合格 X不合格 TBD待完成 NA不适用 检査项：—项；有效检査瑜—呼通过項;_虱钮过率: ［检査结果说明 检査情况 1 有规定的文档标识 1 2 引用的文档现行有效 ? : “ 1 1 3 文档编写的内容、格式符合相关标准、规定 的要求 — _ _ _ 4 文档签署完整 1 1 序号主要检杏项 标准化 设计陈述中的命名、术语和缩写是否上下文 一致 完整性和正确性 6 10 11 12 文档冇独立的版本说明部务 没有丢失任何需求或必要:信息，重点在「用 户任务 是否包括了所有的原始需求（指系统或软件 需求，通常限制在开发或羚证上） 规格说明书中是杏指明了所有已知的用户或 系统需求？所有用户要完成的任务都包含r 吗（只冇用户代表才能决定用户需求的正确 性） 需求表达是否清晰、易理解、无二义性 毎个功能需求都适与地指定了输入、输出项 已经明确陈述出所有的条件与限制 13 数据精度、时间特性和适应性是否以经明确 14 运行需求是否明确（运行平台、接曰需求、 用户界面等），符合初始需求 15 对质量的要求是否明确、合理（正确性、健 壮性、安全性等） 16 是否分析了潜在的需求 17 是否标识并解决了需求中的潜在问题 1 一致性 18 是否存在冲突或重复的需求项 19 20 升发计划、产品和活动与需求是否保持一致 q 是否可以根据软件需求规范中的信息制定出 详细的测试集，并fl.每项需求是否可以测试 21 是否有《需求跟踪矩阵》 i 1 可行性 22 需求定义中的功能是否能通过现有技术实 现？ 23 所有功能是否能够在某些非常规条件下实 现？ 24 是否能够达到特定的性能要求？ 1 概要设计说明书检查表 概要设计说明书检査表 项目编号 「?作产品 maa 检査人员 检査结果标记 /合格 X不合格 TBD待完成 NA不适用 检査情况 检灸项：—项：有效检査项：—项；通过项：—项；通过率：— 序号 |主要检査项 | 1检查结果1说明 标准化 1 有规定的文档标识 2 引用的文档现行有效 3 文档编写的内容、格式符合相关标准、规定 的要求 4 文档签署完整 完整性 5 文档有独立的版本说明部分 6 有文档的文字目录页 2 有总体设计部分