软件需求评审会规范

更新时间:2023-06-06 22:53:01 阅读量: 实用文档 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

XXXXXX网络技术(北京)有限公

软件需求评审会规范

(软件需求评审会规范)

规定软件需求评审会规范

XXXXXX网络技术(北京)有限公司

版本

日期

说明 本文件的初稿 最终版本 第一次修改

编写者

审核者

备注

软件需求分析评审会记录编制规定

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)

1)是否每一个需求只有一种解释

2)功能性需求是否可以按模块方式描 3)是否有术语定义一览表 R-1 4)是否使用了形式化或半形式化的语言5)语言是否有歧义性

6)需求定义是否足够清楚和明确,使其

1)各个需求之间是否一致?是否有冲突

2)所规定的模型、算法和数值方法是否 R-2 3)是否使用了标准的术语和定义形式 4)需求是否与其软硬件操作环境兼容 5)是否说明了软件对其系统和环境的影

6)是否说明了环境对软件的影响

主持人:

会议时间:

R-3

R-4

R-5

R-6

R-7

7)所采用的技术是否与用户的要求一致

1)需求定义是否使系统设计、实现、操

2)所规定的模型、数值方法和算法是否

3)是否能够达到关于质量的要求

1)是否可以从上阶段的文档中找到需求

2)需求定义是否明确地表明前阶段中提

3)需求定义是否便于向后继开发阶段查

1)是否需求只描述了做什么,没有描述

2)需求描述是否是适当程度的抽象/详细

1)所有定义、实现方法是否清楚地表达

23)在功能实现过程、方法和技术要求的

1)需求定义是否满足标准的要求; 2)算法和规则是否由科技文献或其它文

3)是否定义了对在错误、风险分析中所

4)是否参照了有关的标准

5)是否对每个需求都给出了理由?理由

6)对设计和限制是否都有论证

只有软件工程过程组(SEPG)有权限改变核对项.

键入 "N" 如果标准/方法没有被执行(由于严重错误而否决工作产品,错误改正后必须再次复审), "Y"如果确认标准/方法被执行(工作产品可以不经修改而被接受), "E"如果可以暂时接受工作产品(发现必须改正的微小错误,但是不再需要进一步复审). 项目经理 (打印):

签名:

日期:

此外还要对原始需求描述中的相关内容,如需求类型、优先级、易变性等作出修正。评审之后《原始需求库》,通过正式的变更控制流程对它进行变更控制。

本文来源:https://www.bwwdw.com/article/ufj1.html

Top