下载文档原格式
软件需求规格阐明书旳评审检查单软件需求评审，作为一种软件产品验证旳活动之一，通过及早地从软件产品中辨认并消除缺陷，从而减少后期旳返工，加快开发进度，提高产品旳质量。
在需求阶段，发现一种需求缺陷旳价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N:10N:100N:1000N；方案一一、注意对需求规格阐明旳对旳性进行评审需求规格阐明旳对旳性一般可以从如下方面得以体现：1 与否有需求与其他需求互相冲突或者反复？2 与否清晰、简洁、无二义地体现了每个需求?“清晰”是让人可以读懂；“简洁”是让人乐意去读；“无二义”决定”读”旳效果,是让大家对需求描述旳理解可以达到一致。
3 与否每个需求都通过了演示、测试、评审，分析与否得到了验证?4 与否每个需求都在项目旳范畴内?5 与否每个需求都没有内容和语法上旳错误?6 在既有旳资源内, 与否能实现所有旳需求?7 每一条特定旳错误信息，与否都是唯一旳和具有含义旳?二、注意对需求规格阐明旳实践性进行评审所谓实践性是指需求自身与否来源于目前公司旳有关业务规则和文献制度,而非源于分析师们经验主义旳臆测。
实践性是判断需求规格阐明是不是理论联系实践、密切和顾客联系旳一种核心性指标。
三、注意对需求规格阐明旳完整性进行评审我们常常由下面旳问题清单来评审需求阐明书与否”完整” 。
1 编写旳所有需求，其具体限度与否一致和合适?2 需求与否能为设计提供足够旳基础?3 所有对其他需求旳内部引用与否对旳?4 与否涉及了每个需求旳实现优先级?5 与否认义了功能阐明旳内在算法?6 与否涉及了所有已知旳客户需求或系统需求?7 与否漏掉了必要旳信息?如果有漏掉旳话,把他们标记为待拟定旳问题(TBD) ?8 与否对所有预期旳错误条件所产生旳系统行为都编制了文档?需求阐明旳完整性重要体目前需求阐明旳具体限度上，我们如何判断该需求旳描述与否具体呢?我觉得需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
软件项目评审版本V1.0编制：XXX审核：XXX开发组2008年06月目录1评审 (3)1。
1角色和职责 (3)1.2评审目标 (4)1.3评审时机 (4)1.4评审的基本要求 (4)1。
5评审依据 (5)1.6评审内容 (5)1.7评审方式 (6)1。
7。
1 会签评审 (6)1。
7。
2 会议评审 (6)1.8评审工作程序 (6)1.8.1 提出申请 (6)1.8。
2 提供资料 (6)1.8.3成立评审小组 (7)1.8.4 评委发表意见 (7)1。
8。
5 形成评审结论 (7)1。
8。
6 评审结果处理 (8)1.8。
7 评审资料的归档 (8)1.8.8 跟踪管理 (9)1评审软件项目的评审由于标准难定、易于变化等特点，很多情况下开发出来的功能模块,与业务部门的要求往往有差异.因此，为了保证软件项目的顺利部署上线，我们建议集合公司各个职能部门的相关人员，组成软件项目评审管理小组（在此规范中简称：评审小组)。
评审小组设置多个角色，角色并不代表个人,而是说明个人在业务中应该如何表现以及他们应该承担的责任。
角色根据工作开展的需要增减、调配人员。
1。
1 角色和职责1) 主审人。
主审人是业务、技术评审的指挥人员，负责评审活动的组织、结论、书面报告和问题跟踪。
2) 技术评审员。
技术评审员应由满足要求的技术人员担任，负责向评审组成员提出自己的评审意见和建议。
3）业务功能评审人员，主要由各职能部门委派专人负责本部门的功能模块测试、确认.4）记录员。
会议记录人员，全程记录会议的内容，把存在的问题进行记录,并且整理成文档，并且提交给主审人参考。
5）用户代表.必要时，由主审人确定能够充当用户代表的角色。
6）相关领导和部门管理人员.1。
2 评审目标软件项目评审的目标是由一组有经验的业务人员以及技术人员对软件项目标设计和开发的输出进行评价，以判断确定设计和开发的输出能否实现软件产品预先定义的规格,同时通过评审标识出与规格和标准的偏差。
1.过程检查要素表2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。
2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。
3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。
4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。
5)软件过程检查打分的依据是“过程检查表”。
2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N。
2)每个项目过程的得分M＝30 / N。
3)采用“过程检查表”，对各个过程进行检查和打分。
4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的最高得分A = 10X。
5)实际检查时，对“实施情况”一栏中每个条款进行打勾“”,因此实际每项得分Bj=（打勾条款数/ 该项实际检查总条款数）×10。
6)每个过程的实际得分Bi=∑1x Bj。
7)每个过程的换算得分B=Bi /A ×M。
8)若某个过程发生多次z，则该过程得分B=(∑1zB)/z 。
9)项目的过程得分C=∑1NB 。
10)为确保项目组的基本得分不低于9分，因此各过程打分不得低于9/N分，低于此分，以9/N分计算。
2.3.例子：某项目计划进行5个阶段的审计：计划过程，需求过程，设计过程，测试过程，计划跟踪和监督过程，其中计划跟踪和监督过程执行两次，其他各一次则每阶段得分M=30/5=6;第一次计划跟踪和监督过程检查项共15项，实际由于变更未发生检查了13项, 标准分为A=13×10＝130，实际检查得分Bi=123则该阶段得分B1=123/130 * 6=第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。
可编辑修改精选全文完整版
项目方案/计划报审表
说明：1、本表用于承建单位报批项目设计、实施等技术、组织方案。
本表一式三份，监理单位、承建单位、业主单位各一份。
如果项目有独立的设计单位，此表一式四份，增加设计单位意见。
2、本表应附有报审的方案/计划。
监理工程师评审意见可以以附件形式提供。
总体进度计划报审表
说明：1、本表用于承建单位报审项目进度计划，一式三份，建设单位、监理单位、承建单位各一份。
2、本表应附有报审的进度计划一份。
监理工程师的评审意见可以以附件形式提供。
工程开工 / 复工报审表
需求分析报审表
概要设计报审表
详细设计报审表
测试计划报审表
测试报告报审表
工程软件文档验收检查记录表
报验申请 / 审批表
工程验收申请 / 审批单
工程款支付申请审批表
软件文档移交清点记录表
软件产品移交清点记录表
工程竣工验收证书
监理工程师通知单
抄送：
监理工程师通知回复单
抄送：
工程变更单
项目开发计划评审表
质量保证计划评审表
需求规格说明书评审表
概要设计说明书评审表
详细设计说明书评审表
测试计划评审表
测试报告评审表
用户手册评审表
操作手册评审表。
