软件评审规范-文档资料

2021/4/21
9
7.2需求评审
7.2.2 如何做好需求评审
（1）分层次评审 （2）正式评审与非正式评审结合 （3）分阶段评审 （4）精心挑选评审员 （5）对评审员进行培训 （6）充分利用需求评审检查单 （7）建立标准的评审流程 （8）做好评审后的跟踪工作 （9）充分准备评审
2021/4/21
10
2021/4/21
7
失败的需求评审:案例
某软件公司在用户处开完物资管理系统 的需求评审会后，与会人员在离开会议 室时纷纷摇头，认为本次会议没有多少 实际效果，完全是在走过场。
某软件公司在公司内部举行产品的需求 评审会时，需求报告的执笔人与产品策 划的主要策划人员的想法差别很大，致 使需求评审会没有必要继续进行下去。
对于主持评审的管理者也需要进行培训，使 参与评审的人员能够围绕评审的目标来进行， 能控制评审节奏，提高评审效率
2021/4/21
16
充分利用需求评审检查单
需求检查单：需求形式检查单和需求内容检查单。
需求形式检查：由QA人员负责，主要是针对需求文 挡的格式是否符合质量标准
需求内容检查：是由评审员负责，主要是检查需求 内容是否达到了系统目标、是否有遗漏、是否有错 误等等
第7章 软件评审
7.1软件评审概述
7.1.1评审目的 评审的目的是检验软件开发、软件评测
各阶段的工作是否齐全、规范，各阶段产品 是否达到了规定的技术要求和质量要求，以 决定是否可以转入下一阶段的工作。
2021/4/21
1
7.1软件评审概述
7.1.2评审阶段的划分 （1）系统分析与设计； （2）软件需求分析； （3）软件概要设计； （4）软件详细设计； （5）编码和单元测试； （6）软件部件测试； （7）软件配置项测试； （8）软件系统测试； （9）系统验收。
2021/4/21
13
精心挑选评审员
需求评审可能涉及的人员： 需方：高层管理人员、中层管理人员、具体
操作人员、IT主管、采购主管 供方：市场人员、需求分析人员、设计人员、
测试人员、质量保证人员、实施人员、项目 经理以及第三方的领域专家等等
2021/4/21
14
精心挑选评审员
这些人员所处的立场不同，对同一个问题的看法是 不相同的，不同的观点可能形成互补的关系
需求评审是所有的评审活动中最难的一个，也是最容 易被忽视的一个评审。深入的问题。
以下是一些失败的需求评审案例
2021/4/21
4
失败的需求评审:案例
某领域专家A先生就某企业的成本管理系统做 用户需求报告的评审工作
在评审会开始时间不长，就被在场的某企业的 一位副总B先生打断，认为A先生提出的方案不 适合本企业，A先生提出的管理改进方案在企 业中无法实施
的需求变更申请，进入需求变更的管理流程，并确 保变更的执行。在变更完成后，要进行复审。
切忌评审完毕后，没有对问题进行跟踪，而无法保 证评审结果的落实，使前期的评审努力付之东流
非正式评审：不需要将人员集合在一起，通 过电子邮件、网络聊天等多种形式
有时，非正式的评审比正式的评审效率更高， 更容易发现问题
2021/4/21
12
分阶段评审
在需求形成的过程中进行分阶段的评审，而 不是在需求最终形成后再进行评审
将原本需要进行的大规模评审拆分成各个小 规模的评审
降低了需求返工的风险，提高了评审的质量
检查单可以帮助评审员系统全面地发现需求中的问 题
检查单随着工程经验的积累逐渐丰富和优化
2021/4/21
17
建立标准的评审流程
需求评审会需要建立正规的需求评审流程， 按照流程中定义的活动进行规范的评审过程
2021/4/21
18
做好评审后的跟踪工作
根据评审人员提出的问题进行评价： 确定哪些问题必须纠正（给出理由与证据）：书面
该副总提完意见后，与会的用户方人员纷纷跟 随B先生的提出了他们的反对意见，致使评审 会无法再进行下去，最终该报告被用户否决。
2021/4/21
5
失败的需求评审:案例
某软件公司内部举行产品的需求评审会，主要 是公司内部的相关领域的专家参加
在评审会开始后不久，某领域专家就对需求报 告中的某个具体问题提出了自己的不同意见
2021/4/21
8
问题总结
以上的现象可以在很多项目中都可以看到。概 括起来，在需求评审中经常存在以下问题： 需求报告很长，短时间内评审者根本不能把需 求报告读懂，想清楚 没有作好前期准备工作，需求评审的效率很低 需求评审的节奏无法控制 找不到合格的评审员，与会的评审员无法提出 深入的问题
要保证使不同类型的人员的都要参与进来，否则很 可能会漏掉了很重要的需求
不同类型的人员中要选择那些真正和系统相关的， 对系统有足够了解的人员参与进来，否则使评审的 效率降低
2021/4/21
15
对评审员进行培训
很多情况下，评审员是领域专家而不是进行 评审活动的专家，没有掌握进行评审的方法、 技巧、过程等，需要培训
与会人员纷纷就该问题发表自己的意见 大家争执不下，结果，致使会议出现了混乱状
况，主持人无法控制局面，会议大大超出了计 划评审时间。
2021/4/21
6
失败的需求评审:案例
某软件公司为某公司A做业务流程管理系 统的需求评审会
当项目组人员在会议上宣读多达上百页 的需求报告时，用户明确提出听不懂， 致使会议不得不改日进行。
2021/4/21
2
7.1软件评审概述
7.1.3评审的组织与管理
1．内部评审 内部评审是由承办方组织的评审。
2．外部评审 外部评审是由交办方组织的评审，特
殊情况下，交办方可委托其他单位代理组 织外部评审。
2021/4/21
3
7.2需求评审
7.2.1 需求评审概述
软件需求是软件开发的最重要的一个步骤，需求的质 量很大程度上决定了项目质量或产品质量。
分层次评审
用户的需求层次： 目标性需求：定义了整个系统需要达到的目
标 （高层管理人员关注） 功能性需求：定义了整个系统必须完成的任
务 （中层管理人员关注 ） 操作性需求：定义了完成每个任务的具体的
人机交互 （具体操作人员关注）
2021/4/21
11
பைடு நூலகம்
正式评审与非正式评审结合
正式评审：开评审会，组织多个专家，将需 求涉及到的人员集合在一起，并定义好参与 评审人员的角色和职责