51Testing软件测试论坛

标题: 怎么进行需求评审？？（08-11-10）（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2008-11-10 10:37
标题: 怎么进行需求评审？？（08-11-10）（获奖名单已公布）
引言：我们公司快要成立测试部了，之前我们一直是研发部下的测试小组，在成立之前，我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求，我们几个都没有相关的经验，所以我在此求助大家，邀大家来讨论下：

如何进行需求评审？怎样的需求评审机制才是有效的？


感谢会员dqar提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！


获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
阿七
当当购物卡50元
5#
二等奖
archonwang
300论坛积分
2#
三等奖
Lanbiers
100论坛积分
15#
作者: archonwang    时间: 2008-11-10 11:12
标题: 但愿以下内容对大家有帮助！
呵呵。不错的问题。大家一起来总结啦。

=========================================================================
[2008-11-10]：
关于需求评审，首先我觉得应该解决的是可用的评审可用资源问题，只有把这个问题解决了，其评审结果才可以采信，否则不过形式尔耳。
关于需求评审的一些必备资源，我这里选列了相关角色，如下列：

当然，除了人员意外，必要的时间、场地和上层决策者的支持也是不可或缺的。

这些资源一旦准备停当，接下来就是如何安排评审事宜的问题了。我这里简单列下以往曾做过的一轮需求评审的过程：


4# 给出了一项检查清单，作为文档审查人员审查需求的参考检查表使用，大家可以在进行需求评审时参考使用。

=========================================================================
[2008-11-14]：关于如何做好需求评审的一些文章推荐，希望可以对理清如何做好需求评审有个大概的概念
关于需求评审的几项建议[摘自网友chouy：软件需求评审之道]
原文地址：http://www.cnblogs.com/chenyu0720/archive/2008/06/27/1230934.html

建议一：分层次评审
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。


建议二：正式评审与非正式评审结合
正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这2种方式。


建议三：分阶段评审
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。


建议四：精心挑选评审员
需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。


建议五：对评审员进行培训
在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训2种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。


建议六：充分利用需求评审检查单
需求检查单是很好的评审工具，需求检查单可以分成2类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。


建议七：建立标准的评审流程
对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。

建议八：做好评审后的跟踪工作
在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。


建议九：充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。


=========================================================================
软件需求设计评审之八项注意[摘自IT168网友  铁在烧：软件需求设计评审之八项注意]
原文地址：http://tech.it168.com/a2008/0729/198/000000198990.shtml

一、 注意对需求规格说明的正确性进行评审
需求规格说明的正确性通常可以从如下方面得以体现：
1 是否有需求与其他需求相互冲突或者重复？
2 是否清晰、简洁、无二义地表达了每个需求?
“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致 。
3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证?
4 是否每个需求都在项目的范围内?
5 是否每个需求都没有内容和语法上的错误?
6 在现有的资源内, 是否能实现所有的需求?
7 每一条特定的错误信息，是否都是唯一的和具有含义的?

二、 注意对需求规格说明的实践性进行评审
所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。

三、 注意对需求规格说明的完整性进行评审
我们经常由下面的问题清单来评审需求说明书是否”完整” 。
1 编写的所有需求，其详细程度是否一致和合适?
2 需求是否能为设计提供足够的基础?
3 所有对其他需求的内部引用是否正确?
4 是否包含了每个需求的实现优先级?
5 是否定义了功能说明的内在算法?
6 是否包含了所有已知的客户需求或系统需求?
7 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?
8 是否对所有预期的错误条件所产生的系统行为都编制了文档?
需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

四、 注意对需求方案的可行性和成本预算进行评审

五、 注意对需求的质量属性进行评审
我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。

六、 注意对需求的可实施性进行评审
是否对每个需求都设置了惟一性并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求（比如系统需求或用例）?
需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。
需求的可实施性除了可跟踪性还包括可测试性。事实上, 分析人员和测试人员在编写代码以前把需求模型,分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求。软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧义和错误。

七、 注意对需求包含的用例文档进行评审
用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例的主干过程。而我们是否撰写有效的用例则要从以下方面着手评审。
1 用例的目标或价值度量是否明确?
2 用例是否是独立的分散任务?
3 是否明确说明可用用例会给哪些参与者带来用处?
4 编写用例的详细程度是否恰当?是否有不必要的设计和实现细节?
5 所有预期的分支过程是否都编写了文档说明?
6 所有预估的异常过程是否都编写了文档说明?
7 是否存在一些普通的动作序列可以分解成独立的用例?
8 每个路径的步骤是否都清晰明了,无歧义而且完整?
9 用例中的每个参与者和步骤是否都与所执行的任务有关?
10 用例中定义的每个可选路径是否都可行和可验证?
11用例的前置条件和后置条件是否合理?
分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界限。

八、 注意需求评审会的过程和结束标准
需求评审会的结果是对需求规格书完成了评审过程,那我们又如何判断审查的结束标准呢?请看如下几条建议:
1 审查期间评审员们提出的所有问题都已经解决。
2 相关文档中的所有更改都已经正确完成。
3 修订过的文档进行了拼写检查。
4 所有标识为TBD(待确定)的问题已经全部解决, 或者已经对每个TBD的问题的解决过程、计划解决的目标日期和责任解决人等编制了文档。
5 需求文档正式进入了配置库。

[ 本帖最后由 archonwang 于 2008-11-14 09:47 编辑 ]
作者: 郁闷的我    时间: 2008-11-10 16:36
坐等前辈们答题．
作者: bugrobot    时间: 2008-11-10 19:39
标题: 供参考
编号
项目
实际案例或说明
1
与需求相关的数据定义
 数据流向，可以有数据流图
2
功能需求是否覆盖了所有的异常情况的处理
对涉及到流程类的操作进行头脑风暴，画出流程图，找出所有的异常情况
3
是否标识了将来可能变化的需求
可扩展性的考虑或是可维护性。测试中需要注意和跟踪的地方。
4
是否说明了系统输入的来源
输入的数据是什么样的
5
是否说明了系统输入输出的类型
输入输出等价类的划分
6
是否说明了系统输入输出的值域，单位，格式
7
是否说明了系统输入，输出的精度
有效位数
8
是否说明了如何进行系统输入合法性的验证
输入合法性的验证。
9
时间因素
时间精度，跨度，使用的时间控件的情况。
10
需求项的编号，需求唯一，并可标识
需求管理和跟踪
11
与需求相关的维护性
系统上线后是怎么被维护的？维护的工作量是怎样的，由谁来维护，维护的频度是多大的。
12
需求定义系统的外部接口与内部接口
划定测试范围，模块集成测试的依据。从不同的入口准备数据。
13
需求之间是否有冲突和矛盾
14
是否对每个需求给出设计理由，理由是否充分。
比如，按id倒序排序，为什么要按id，为什么要倒序排序，按别的是不是更好？
15
是否冗余
同一个需求被定义多次
16
系统应用的环境，如浏览器，应用语言，分辨率等等。
17
需求形式化语言的运用
对于数学公式的描述，或是复杂流程，尽量用形式化语言进行描述。
18
需求是否可以验证
需求的可测试性，是否需要开发打上logo。
19
对于异常数据产生的结果是否有描述
垃圾数据的处理
20
所有页面控件的默认状态是否明确的标明
21
是否有关于权限控制的说明
22
对于提示信息的文案说明是否有详细的描述
23
Demo列表，demo是否加入了版本控制
24
是否对界面需求有所描述
25
需求中是否包含模糊性词语
举例，如：依需要，顺利完成，正确完成，可以，可能，等等
26
需求描述中应有优先级别和重要程度的描述
27

软件需求文档和用户需求文档是否有对应的跟踪关系

全选和反选详细说明，反选是取反还是全部不选
28
是否有真实数据作为需求的输入
29
业务的业务操作流程是什么，页面使用频度是否可定义。
30
需求是否定义了哪些是应用现有的框架，哪些是全新实现的部分。
31
需求文档中使用的图表是否正确，是否更新。
作者: 阿七    时间: 2008-11-11 09:11
标题: 怎么进行需求评审
1 需求评审的重要性
软件的缺陷并不是在编程的时候才出现的,需求和设计阶段都会产生问题,如果缺陷发现的越迟,修正这个错误就要返回到以前的状态,反攻的时间就花费的很多了,如果错误还不能够被及时发现,那就可能带来更大的危害,缺陷发现的越找,修正的越早,所用的成本就月低,越迟,成本就越高.所以我们对需求评审要认真对待了.概括下有几点
a 对软件需求进行正确性的检查,能发现需求定义中的错误,从而节约成本,使后续过程的变更减少,降低风险.
b 保证软件需求的可测试性,即确认客户的需求是明确的,可遇见的.可以用测试用例反应出来
c 通过产品需求,可以使产品,开发,测试等部门相互沟通,达成一致
d 通过产品需求的评审,更好的理解产品的功能性和非功能性需求,为制订测试计划,测试范围,工作量等提供参考.
2 需求评审的注意点
a 明确自己的角色和责任,熟悉评审的内容
b 针对问题表达自己的观点,对事不对人.分清主要问题和次要问题,先把主要问题说出来.
c 提高自己的沟通能力,
d 最主要的一点就是要善于提问,自己问自己问题.是否这个需求不明确,是否需求画蛇添足,站在最终用户角度想问题,而并不是绝对的站在需求提供方的角度.
3 评审的形式
a 交叉评审 b 轮查c 走查d 小组评审e 审查   (这些大家应该都经历过吧,O(∩_∩)O 不多说了)
4 评审的标准
组织和完整性
* 所有需求的编写在细节上是否都一致或者合适？
* 是否包括了每个需求的实现优先级？
* 软件需求规格说明中是否包括了所有客户代表或系统的需求？
* 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。
* 是否记录了所有可能的错误条件所产生的系统行为？
正确性
* 是否有需求与其它需求相冲突或重复？
* 是否简明、简洁、无二义性地表达每个需求的？
* 是否每个需求都能通过测试、演示、审查得以验证或分析？
* 是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性
* 是否合理地确定了性能目标？
* 是否合理地确定了安全与保密方面的考虑？
* 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？
可跟踪性
* 是否每个需求都具有唯一性并且可以正确地识别它？
* 是否可以根据高层需求（如系统需求或使用实例）跟踪到软件功能需求？
特殊的问题
* 是否所有的需求都是名副其实的需求而不是设计或实现方案？
* 是否确定了对时间要求很高的功能并且定义了它们的时间标准？
5. 进入和退出审查的标准
当软件需求文档满足特定的前提条件时，你就可以进行需求审查了。这些标准还可以使审查小组避免把时间浪费在审查之前就应该解决的问题上。调解者在决定进行审查之前，可以把进入审查的标准作为一种清单，并以此作为判断的标准。
* 文档符合标准模板,并且已经做过拼写检查和语法检查。
* 在文档中打印了行序号以方便在审查中对特定位置的查阅。
* 所有未解决的问题都被标记为（待确定）。
* 包括了文档中使用到的术语词汇表。
相似地，在调解者宣布审查结束之前，你应该定义所满足的退出审查的标准。
* 已经明确阐述了审查员提出的所有问题。
* 已经正确修改了文档。
* 修订过的文档已经进行了拼写检查和语法检查。
* 所有（待确定）的问题已经全部解决，或者已经记录下每个待确定问题的解决过程，目标日期和提出问题的人。
* 文档已经登记入项目的配置管理系统。
6 总结
基本上能做到以上说的几点,需求就应该很明确了.接下来的流程也会走的很顺了!

7 阿七(嘿嘿.落款专用!!!)

[ 本帖最后由 阿七 于 2008-11-11 10:16 编辑 ]
作者: bingling_11    时间: 2008-11-11 09:49
标题: 回复 1# 的帖子
首先，需求文档必须明确，我想既然你们部门想要走需求评审这个流程，那肯定有详细的用户需求了，这点我就不多说了。下面我给您一个需求评审的步骤，仅供参考：
第一、召集与项目相关的人员参加需求评审会议，包括测试工程师、需求工程师、开发工程师、项目经理、必要时公司高层领导也可参加此会议。
第二、审评会议中由项目经理介绍该项目的用户需求，然后按照各个模块一一进行讨论，讨论需求是否合理，以及实现方式是否可行等等内容，都可以在需求评审会议上进行讨论，直至达到共识，若在项目进行中需求出现变更，中途可再次召开需求变更的评审会议，以此类推。
第三，需求审评后，应由需求工程师对需求进行修正，并且形成评审记录，cc给相关人员及公司领导。
以上是我的实际工作中应用的需求评审流程，希望对您有所帮助！
作者: 疯都疯了    时间: 2008-11-11 11:41
需求评审可以分为正式评审与非正式评审，在需求规格说明书完成后，需求组必须自己对需求做评审。如果需求组递交的需求规格说明书在指导后面的工作的时候出现很明显的错误，我想拿高工资的需求分析人员是无法向老板交差的。为了需求分析人员的名誉，他们自己会对自己提交的内容进行审核，直到他们认为自己的工作成果足够好，才会将需求规格说明书提交给正式评审组。

    正式评审组的成员一般由公司内经验最丰富，技术最牛的人（技术总监）来担任，当然参加评审的人中间还应该有项目经理、QA人员、测试人员、架构师，他们仔细阅读需求规格说明书，并针对自己将要开展的工作内容进行检查，并提出问题

    正式评审是最后一关，如果正式评审通过了，将进入系统设计阶段，如果在系统设计阶段再跨里程碑来修改需求的话，所花费的代价将大大增加。因此正式评审将是一个“鸡蛋里挑骨头”的过程，只有所有的人都认为需求已经没有什么可挑剔评审才能通过。
作者: tengmy    时间: 2008-11-11 15:04
其实说句实话，理论说的再好，对于没有测试经验/评审经验的人来说，照本宣科也不是一件简单的事情。
毕竟需求评审是做好一个项目的第一步。
如果需求评审有问题，会给以后的测试工作的安排和进行带来很多的问题
作者: free_xiaoyu    时间: 2008-11-11 16:44
请问对于项目需求评审,是否需要加入用户一起进行评审.
作者: archonwang    时间: 2008-11-11 17:06
标题: 回复 9# 的帖子
需要，应由客户方派出客户代表进行业务方面的确认。
作者: sumohan    时间: 2008-11-11 17:43
标题: 回复 7# 的帖子
需求组一般把软件需求规格说明书同行评审通知发出，做为测试人员可对照需求规格说明书，对以下检查点可以做为重点检查：（１）需求项是否拆分到最小粒度，即对应到原子级的Use case?　（２）是否所有的功能性需求都能映射到Use case?（３）软件需求规格说明书中是否包括了所有的Actor?　（３）所有对其它需求项的内部交叉引用是否正确？（４）所有需求的编写在细节上是否都一致或者合适？（５）是否包括了每个需求的实现优先级？（６）是否在需求的描述中遗漏了必要的信息？（７）是否每一具体的Use case 涉及至少一个 Actor？（８）是否每个Use case 独立于其他Use case ？（如果两个用例总是以同样的顺序被激活，尽可能将他们并成一个．）（９）是否有Use case 事件流的描述是另外一个Use case 事件的一部分？（如果是，抽出这个子事件流）（１０）是否合理地确定了性能目标？（１１）是否可以根据高层需求（如业务需求、业务场景或数据需求）跟踪到软件功能需求？等
　　一般召开评审会都会请到同行中的公司内经验最丰富，技术最牛的人来担任评审，以及项目经理、ＳＱＡ、ＱＡ、架构师、开发人员等甚至公司领导来参加，再对每个模块进行陈述时，参与开会的人员都可以对项目的功能、实现方式、需求进行讨论，讨论过程中没有达到统一的意见可以进行二次讨论，产生新的需求变更，一致的可以把意见记录下来做为评审意见，由组织者整理经与会者签字进行需求修改。
作者: 佐伊    时间: 2008-11-12 13:45
分层次评审
  
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
　　
目标性需求：定义了整个系统需要达到的目标；
　　
功能性需求：定义了整个系统必须完成的任务；
　　
操作性需求：定义了完成每个任务的具体的人机交互；
　　
作者: 迎面一板砖    时间: 2008-11-12 13:57
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。

　获取用户需求
了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。

对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。

需求分析人员对收集到的用户需求做进一步的分析和整理。



万年潜水艇上浮中！~~~
作者: lanbiers    时间: 2008-11-13 15:57
需求分析师是项目中直接与客户接触的人，需求做的好不好决定项目成败，因此对于需求规格说明书的正确性必须进行彻底的验证，将错误在开工前就消灭。
作者: lanbiers    时间: 2008-11-13 16:03
根据项目管理的经验，进行需求评审不仅是必要的，而且是必须的。应该让不同角色的人员从不同的角度对需求进行验证，验证需求的可行性、完整性、一致性、正确性等 那么怎样才能做好需求评审呢?

评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，在评审文档中存在大量的低级错误或者没有在评审前进行沟通，从而导致评审的效率很低，质量很差。

为了保证评审的质量和效率，首先要保证使不同角色的人员都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

为了避免评审小组被冗长的软件需求规格说明所吓倒，在审查整个需求文档之前，可以在整个需求开发期间采用增量式评审和多种评审方式相结合的方法。找出风险高的地方，并进行仔细审查，而风险较小的部分则可以采用非正式评审。。

需求在通过正式的评审和批准之后。应该确定需求基线，进一步的需求变更将在此基线的基础上，依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。
作者: lanbiers    时间: 2008-11-13 16:03
我随便说说的哈~ 说错的大家见谅~
作者: lanbiers    时间: 2008-11-13 16:04
就实际工作上来说需求评审需要针对开发设计进行
作者: lanbiers    时间: 2008-11-13 16:05
开发设计应能够应对足够的不可预期的需求变更
作者: lanbiers    时间: 2008-11-13 16:06
所以需求评审的基础之一就要求开发设计需要有足够灵活的框架来应对变更
作者: lanbiers    时间: 2008-11-13 16:06
当然咯，前提之一还是需要满足既定的需求
作者: lanbiers    时间: 2008-11-13 16:07
其实我觉得应该少一点摘录，多一点实际的体会咔咔~
作者: jiangly    时间: 2008-11-13 16:36
"怎样的需求评审机制才是有效的？"
个人觉得这个问题的侧重点在“评审”上面了，如何评审才是有效的？不管是“需求的评审”还是“概要设计/详细设计的评审等等。需要深究的应该是“如何评审”。。。
作者: fanyin    时间: 2008-11-14 09:56
通常需求分为用户的原始需求（需求包）和设计需求（需求规格说明书）。

  需求的评审除了各位朋友讲到的如何组织评审，选取哪些评审专家，提前几天发出被评审对象，如何再评审会上提前对收集到的意见进行汇总答复外，还要在会上进一步讨论一些有疑义的问题，以便澄清给出答复，并行成评审纪要。这些应该在公司的《评审流程》中进行规定。

  除了上述这些比较笼统的做法之外，确保评审质量还有一个关键就是面对这个评审对象我们应该评审什么？关键点都有哪些？这就涉及到《需求评审的checklist》的建立，它是一个需求评审的作业指导书，当然在这个指导书中，作为测试成员，必须要关注需求的可测试性，可用性，易用性和可维护性等需求。

《需求评审的checklist》示例：

[attach]46852[/attach]
作者: travelinrain    时间: 2008-11-14 09:56
目的：我觉得需求评审的目的是为了检查需求的合理性和可实现性。
参与人员：需求评审的参与人员主要包括：
  --需求提出方：产品经理或者第三方
  --系统架构师：架构师可以更好的把握系统架构，检查需求的可实现性
  --开发工程师：开发工程师最了解需求实现难度和是否能实现
  --测试工程师：从测试的角度评价需求合理性
  --客户服务人员：客户和最终用户距离最近，对一般用户了解较多，因此客服人员可以更好的站在用户角度考虑问题
需求评审的准备和进行：需求评审之前，需求提出方最好提前把需求文档发给需要参会的相关人员， 让大家有时间考虑的更深入和更全面
   召开需求评审的会议时，对于一致通过的需求，可以过速的通过，对于各方有疑问和提出疑义的问题，需要一起讨论，给出大致的方案。
   需求评审完成后，需要会议记录人员发送纪要给各方，并发需求的问题和解决方案写清楚。 会议上没有解决的问题，如果是小问题，可以通过邮件方式讨论，如果需要，可以再次召开需求评审会议。
作者: 郁闷的我    时间: 2008-11-14 10:45
标题: 我转了个
需求测试总结
1. 软件工程中的几个概念
　　1) 软件开发模型：螺旋模型（waterfall model + prototype model= spiral model）
　　2) 螺旋模型：需求定义、风险分析、工程实现、评审、迭代结果必需尽快收敛到客户允许或者可以接受的目标范围。
　　3) 以形式化开发方法为基础的变换模型：
　　(1) 软件定义：确定软件的工程需求，分为：可行性研究（决定“做还是不做”：经济、技术、社会环境和人）和需求分析（决定“做什么，不做什么” ：需求的获取、分析、规格说明、变更、验证、管理 ）两个阶段。
　　(2) 通过测试用例来测试需求软件开发：按照需求规格说明的要求，从抽象到具体，逐步生成软件的过程（概要设计、详细设计、实现、集成测试、验收测试）。

2. 需求测试方法包括：
　　1) 通过评审来测试需求：同行评审，组内评审;
　　2) 通过测试用例来测试需求;
　　3) 需求建模.
　　注：我们这里的评审参与者：用户或用户代表，项目管理者，系统工程师和相关的开发人员、QA等。

3. 需求分析测试的误区：
　　1) 客户说不清楚需求;
　　2) 需求自身经常变动;
　　3) 分析人员或客户理解有误。

4. 需求规格说明的特点
　　1) 完整性：不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用 T B D (“待确定”)作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的 T B D项。
　　2) 一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。
　　3) 可修改性：在必要时或为维护每一需求变更历史记录时，应该修订 S R S。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在 S R S中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
　　4) 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（ f i n e - g r a i n e d）的方式编写并单独标明，而不是大段大段的叙述。

4. 需求说明的特性（检查点）
1) 完整性：不遗漏必要和必需的信息;
2) 正确性：每一项需求都必须准确地陈述其要开发的功能;
3) 一致性：与原始需求一致、内部前后一致。与其它软件需求或高层（系统、业务）需求不矛盾（US & WireFrame & Other datum）;
4) 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求（需先进行可行性分析）;
5) 明确性：不使用含糊的词语。对所有需求说明的读者都只能有一个明确统一的解释;
6) 健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些一场进行了容错处理(错误输入后的处理提示);
7) 必要性：不能回溯到出处的需求项可能是多余的;
8) 可测性：每项需求都必需使可验证的;
9) 可修改性：良好的组织结构使需求易于修改。每项需求只应在S R S 中出现一次;
10) 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链;
11) 优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。

[ 本帖最后由 郁闷的我 于 2008-11-14 10:46 编辑 ]
作者: 猫猫的拖鞋    时间: 2008-11-14 16:33
需求评审注重的是理解客户的需要，要站在客户的角度去想问题，最好是大家都了解客户需要怎样的软件，结合公司的开发水平进行有效的调整。

个人见解。。
作者: dqar    时间: 2008-11-14 17:21
标题: 谢谢大家的回答
谢谢大家的回答，收益匪浅
作者: shimmy    时间: 2008-11-14 17:51
写得很好哟！简约明白！
作者: dqar    时间: 2008-11-14 23:07
标题: 回复 8# 的帖子
同意
作者: dqar    时间: 2008-11-17 10:11
标题: 回复 2# 的帖子
谢谢2#的精彩回答
作者: dqar    时间: 2008-11-17 10:22
标题: 回复 5# 的帖子
谢谢阿七简单的总结
作者: dqar    时间: 2008-11-17 10:29
标题: 回复 16# 的帖子
说的很好，不过和2#的部分内容重复了
作者: dqar    时间: 2008-11-17 17:33
谢谢大家的精彩回答，我会好好总结一下的
作者: chengxq    时间: 2008-11-18 09:33
关于需求评审，如何开，这个无论学院派，还是我们的实践者，大家都知道如何进行，如何定义自己的评审流程，但是关键的问题是，很多公司不按照上面的流程走，而且提出了很多不这样走的主观和客观原因，如，项目进度紧，人员能力有限，以前评审都流于形式没有评审出实质的内容，管理者的不支持，以及评审完成之后，相应的数据都没有很好的收集，我想如何有效的召开评审会议，在我们制定好的流程基础上更关键的让项目组严格的执行，以及我们要发现评审的时候，有些过程不足，我们要不断的改进，这才是有效性的根本问题，让项目组真正的接受评审，在评审前严格的作准备工作，输入一定要明确，准确。严格的执行评审，评审的时候关注的问题点，这些作为相应的利益者都应该很清楚，对结果进行有效的分析和判断，千万不能流于形式，同时要加强培训，要将评审的作用，过程深入项目组，深入人心！这才是根本。对一些流程的定义，可能由于每个公司的特点可能不太一样，如一个开发产品的公司和外包的公司肯定是有不同的，即时大家都是外包的，每个公司也很难相同，所以公司的QA部门制定流程的时候，要多考虑公司的实际，如果一个刚起步的公司，上来就给他们按照楼上各位所说的那么全面，那么执行的难度可想而知，我们关注的，我们制定的流程有多少是真正的做了，而不是我制定了多少！
作者: meimeibj    时间: 2009-11-16 00:23
mark
作者: soarsky629    时间: 2010-9-3 14:16
哎，……看看……
作者: Jon    时间: 2010-9-27 17:14
25楼转过来的内容已非常丰富了，如果按照这些去需求评审，肯定能达到很不错的效果。
作者: bingxu30    时间: 2011-5-3 11:06
MAKE
作者: chaoren1236    时间: 2012-5-23 16:03
新人才顶



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2