02工作产品评审指南.docVIP

目录 1. 概述 4 2. 需求评审 4 2.1 完整性 4 2.2 正确性 4 2.3 质量指标 4 2.4 可跟踪性 4 2.5 其他 4 3. 特性需求评审 5 4. 工作细目结构评审 5 5. 系统结构设计评审 5 5.1 系统结构 5 5.2 正确性 5 5.3 设计标准和可跟踪性 5 5.4 逻辑性 5 5.5 界面 6 5.6 清晰度 6 6. 概要设计评审 6 6.1 结构 6 6.2 数据 6 6.3 正确性和完整性 6 6.4 标准和可跟踪性 7 6.5 界面 7 6.6 健壮性 7 7. 详细设计评审 7 7.1 结构 7 7.2 数据 7 7.3 正确性和完整性 7 7.4 标准和可跟踪性 8 7.5 健壮性 8 8. 编码评审 8 8.1 规范性 8 8.2 完整性 8 8.3 合理性 8 8.4 可靠性 8 8.5 可维护性 9 9. 测试计划评审 9 9.1 测试计划 9 9.2 正确性和完整性 9 9.3 标准和可跟踪性 9 9.4 Regression 测试 9 9.5 资源和进度 9 10. 项目计划评审 10 10.1 清晰度 10 10.2 完整性 10 10.3 一致性 10 概述 工作产品是在项目开发和管理过程中产生的各种产物, 其中包括提交给最终客户或用户的文档、报告、编码等, 也包括项目组内部使用的各种文档、报告、工具程序、测试用例等。 本文提供了针对性的工作产品评审指南作为非正式、正式评审的参照。 需求评审 完整性 所有的内部文档引用是正确的和最新的； 所有的需求描述是恰到好处的并提供适度的细节； 需求描述为设计提供了足够的内容和信息； 实现需求的优先级已被定义； 系统对外界面已被确定, 如软件, 硬件和通讯截面等； 系统商业流程已被清晰表达； 需求说明书定义了所有的、已知的客户和系统需要； 可预知的错误出现时, 系统的应有反应已全部定义. 如用户错误输入信用卡号码, 系统应友善的提醒用户信用卡号码出错。 正确性 各个需求之间不矛盾； 各需求描述是清晰的、连贯的和没有歧义的； 各需求可被测试、演示、评审、分析； 各需求是在项目的范围内； 必要的信息不缺项, 没有待定的需求； 所有需求可在现有约束和假定下实现； 所有的错误信息说明是直接的、恰当的和可被理解的。 质量指标 所有的性能指标已被明确和恰当的定义； 系统安全和保密的要求已被明确规定； 其他的隐含的质量指标已被定义并说明可接受的标准； 可跟踪性 每个需求已被单独和正确确认； 每个需求能被跟踪至概要设计相关文档, 如功能设计、数据库设计等。 其他 所有的需求都是需求而非解决方案或设计； 和响应时间相关的需求已被定义和量化； 和国际相关的为题已被确认, 如不同的语言界面等。 所有定义的软件需求用软件来实现是可行和恰当的。 特性需求评审 《特征需求说明书》符合规范要求； 《特征需求说明书》正确地反映了用户的需求，没有错误； 《特征需求说明书》完备地反映了用户的需求，没有遗漏； 《特征需求说明书》前后一致并与相关文档是一致的； 《特征需求说明书》描述清晰，没有歧义。 系统结构设计评审 系统结构 系统结构设计是完整的, 如允许实现全部的需求； 系统已被足够的分解； 系统结构设计为概要设计提供足够的基础； 系统结构具有足够的伸缩性； 系统维护的问题已被确认； 各子程序能被分阶段测试。 正确性 结构设计不含多余结构； 所有的稳定性和性能要求已被考虑； 所有的安全要求已被考虑； 结构设计包含了所有的约束； 结构设计是全面的、正确的和不模糊的； 所有的数据结构已被定义, 没有不必要的数据结构定义。 设计标准和可跟踪性 所有的结构设计标准已被合理采纳； 结构设计可反向追踪至需求说明书。 逻辑性 没有丢失或不正确的逻辑； 所有可能的状态和情况已被考虑。 界面 所有的界面是清楚的和已被定义的； 最小量的数据在界面上交换； 使用最少的系统变量。 清晰度 系统结构, 包括数据交换、控制和界面以被清晰定义； 设计被多角度、多方面但相一致的表达； 系统设计约束和假定、依赖性、权衡利弊均已被记录和归档。 概要设计评审 结构 数据结构已被清晰的分解和定义； 结构已被恰当分解并可作为详细设计的依据； 每一个模块已被清楚描述并可测试； 模块分解符合相应标准和规范。 数据 系统常量和参量已被参数化； 所有的数据已被适当的定义； 数据结构和参数的命名是有意义的并符合命名标准。 正确性和完整性 概要设计是完整的, 如将实现所有的需求； 所有的基础要求已被确认, 如备份, 检查点等； 所有的错误信息是唯一的和有意义的； 所有的稳定性和性能要求已被设计； 国际化要求已被适当的考虑和设计； 文件维护的程序已被确定； 过程处理的优先级已被确定； 分析表明系统会达到要求的处理