软件需求评审会规范

XXXXXX网络技术(北京)有限公司软件需求评审会规范（软件需求评审会规范）规定软件需求评审会规范XXXXXX网络技术(北京)有限公司版本日期说明编写者审核者备注AB本文件的初稿C最终版本D第一次修改软件需求分析评审会记录编制规定1.目的：对“软件需求规格说明”进行分析评审。2.适用范围：适用于软件开发项目组和客户对用户需求分析的评审。3.规程：3.1该评审会是软件开发项目组及客户共同进行的对软件需求分析工作总结和评价。主要针对“软件需求规格说明”。3.2软件需求分析评审会至少要涉及以下主要内容：3.2.1内容评审：“软件需求规格说明”的内容是否完备、格式是否符合要求、采集的数据是否全面、建立的系统模型的准确性、建立的概念模型能否准确地表达系统模型等。3.2.2可行性评审：用户提出的需求是否足以支持系统目标的实现、系统开发的限制条件对系统目标的影响。3.3评审时应参考“软件需求调查记录”。3.4项目组长总结并填写“软件需求分析评审会记录”。4.相关文件5.相关记录5.1软件需求调查记录5.2软件需求规格说明5.3软件需求分析评审会记录附录A软件需求分析评审会记录文档登记号：项目名：主持人：会议时间：参加人：列席人：对原始需求进行评审，如果不通过要求重新整理原始需求，如果通过，则进入相应的原始需求数据库，作为下一步开发设计和计划的基础。对原始需求的评审参照以下评审列表：阶段原始需求评审项目组项目编号项目名标准执行时间复审文档发布编号复审文档时间核对表标准参考核对项标准(Y/N/E)改进意见R-1理解性：（1）是否每一个需求只有一种解释（2）功能性需求是否可以按模块方式描述？是否明确地标识出了其功能（3）是否有术语定义一览表（4）是否使用了形式化或半形式化的语言（5）语言是否有歧义性（6）需求定义是否足够清楚和明确，使其能够作为开发设计规范和功能性测试的基础R-2一致性：（1）各个需求之间是否一致？是否有冲突和矛盾？（2）所规定的模型、算法和数值方法是否相容（3）是否使用了标准的术语和定义形式（4）需求是否与其软硬件操作环境兼容（5）是否说明了软件对其系统和环境的影响（6）是否说明了环境对软件的影响（7）所采用的技术是否与用户的要求一致R-3可实现性：（1）需求定义是否使系统设计、实现、操作和维护可行（2）所规定的模型、数值方法和算法是否对待解决问题适合？是否能够在相应的限制条件下实现（3）是否能够达到关于质量的要求R-4可追溯性：（1）是否可以从上阶段的文档中找到需求定义中的相应内容（2）需求定义是否明确地表明前阶段中提出的有关需求和设计限制都已被覆盖（3）需求定义是否便于向后继开发阶段查找信息R-5设计无关性：（1）是否需求只描述了做什么，没有描述怎么做（2）需求描述是否是适当程度的抽象/详细R-6清晰性：（1）所有定义、实现方法是否清楚地表达了用户的原要求；（2）是否有不能理解或造成误解的描述；（3）在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要求。R-7正确性：（1）需求定义是否满足标准的要求；（2）算法和规则是否由科技文献或其它文献做基础；（3）是否定义了对在错误、风险分析中所标识出的各种故障模式和错误类型所需的反应（4）是否参照了有关的标准（5）是否对每个需求都给出了理由？理由是否充分（6）对设计和限制是否都有论证只有软件工程过程组（SEPG）有权限改变核对项.键入N如果标准/方法没有被执行(由于严重错误而否决工作产品,错误改正后必须再次复审),Y如果确认标准/方法被执行(工作产品可以不经修改而被接受),E如果可以暂时接受工作产品(发现必须改正的微小错误，但是不再需要进一步复审).项目经理(打印):签名:日期:此外还要对原始需求描述中的相关内容，如需求类型、优先级、易变性等作出修正。评审之后《原始需求库》，通过正式的变更控制流程对它进行变更控制。