怎么进行需求评审？？（08-11-10）（获奖名单已公布）
引言：我们公司快要成立测试部了，之前我们一直是研发部下的测试小组，在成立之前，我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求，我们几个都没有相关的经验，所以我在此求助大家，邀大家来讨论下：如何进行需求评审？怎样的需求评审机制才是有效的？
感谢会员dqar提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接
一等奖阿七当当购物卡50元5#
二等奖archonwang
300论坛积分2#
三等奖Lanbiers100论坛积分 15#
但愿以下内容对大家有帮助！
呵呵。不错的问题。大家一起来总结啦。=========================================================================
：
关于需求评审，首先我觉得应该解决的是可用的评审可用资源问题，只有把这个问题解决了，其评审结果才可以采信，否则不过形式尔耳。
关于需求评审的一些必备资源，我这里选列了相关角色，如下列：
[*]业务专家或是熟悉该业务的人员（通常也叫业务方代表）[*]文档审查人员[*]架构师[*]需求分析师[*]需求评审组织人员及记录人员当然，除了人员意外，必要的时间、场地和上层决策者的支持也是不可或缺的。
这些资源一旦准备停当，接下来就是如何安排评审事宜的问题了。我这里简单列下以往曾做过的一轮需求评审的过程：
[*]准备阶段（P）[*]争取上层决策者的支持与谅解[*]筹备相关的资源，包括人力、时间计划，评审场地[*]在正式评审之前，将相关的需求记录（文档或其他形式）发布给每个参与评审的人员手中，并确保其有足够的时间可以通阅需求并做好评审前的相关质疑与确认记录[*]在正式评审之前，会议组织者应先收集相关评审人员的各项需求评审建议和意见，对存在争议和疑惑的需求说明必须做好讨论的安排[*]发布经确认后的评审计划或时间表
[*]实施阶段（D）[*]由评审组织者召集各评审人员集中评议，可以以正式的会议等形式组织，此处以会议为形式做说明[*]与会人就某具体的问题进行讨论，讨论的优先级如下所列[*]最重要的业务内容，一般是按流程、功能、细节来排定[*]争议或疑问较多的地方[*]部分有争议的地方[*]对于没有提出疑义的地方，可以快速流过[*]最后，要注意一定要回顾已提出问题和有结论的地方[*]由会议记录人员整理会议的纲要，记录各与会人员的相关意见，并在会后递交纪要[*]检查再实施阶段（C）[*]对评审得出结论的问题进行再次确认和修正补充[*]确定下次评审的时间[*]按照第一阶段的流程再次进行组织，并确认结果[*]对大多数组织，两次评审可以解决大部分的问题，对于悬而未决的问题，如影响范围有限，则可以延后讨论解决[*]总结阶段（A）[*]就以上内容做最后的确认，需求定稿，各方签字确认。[*]今后的变更转入需求变更流程，其后产生的评审为小范围内评审。
4# 给出了一项检查清单，作为文档审查人员审查需求的参考检查表使用，大家可以在进行需求评审时参考使用。
=========================================================================
：关于如何做好需求评审的一些文章推荐，希望可以对理清如何做好需求评审有个大概的概念
关于需求评审的几项建议[摘自网友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 编辑 ] 坐等前辈们答题．
供参考
编号项目
实际案例或说明
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
需求文档中使用的图表是否正确，是否更新。
怎么进行需求评审
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 编辑 ]
回复 1# 的帖子
首先，需求文档必须明确，我想既然你们部门想要走需求评审这个流程，那肯定有详细的用户需求了，这点我就不多说了。下面我给您一个需求评审的步骤，仅供参考：第一、召集与项目相关的人员参加需求评审会议，包括测试工程师、需求工程师、开发工程师、项目经理、必要时公司高层领导也可参加此会议。
第二、审评会议中由项目经理介绍该项目的用户需求，然后按照各个模块一一进行讨论，讨论需求是否合理，以及实现方式是否可行等等内容，都可以在需求评审会议上进行讨论，直至达到共识，若在项目进行中需求出现变更，中途可再次召开需求变更的评审会议，以此类推。
第三，需求审评后，应由需求工程师对需求进行修正，并且形成评审记录，cc给相关人员及公司领导。
以上是我的实际工作中应用的需求评审流程，希望对您有所帮助！ 需求评审可以分为正式评审与非正式评审，在需求规格说明书完成后，需求组必须自己对需求做评审。如果需求组递交的需求规格说明书在指导后面的工作的时候出现很明显的错误，我想拿高工资的需求分析人员是无法向老板交差的。为了需求分析人员的名誉，他们自己会对自己提交的内容进行审核，直到他们认为自己的工作成果足够好，才会将需求规格说明书提交给正式评审组。
正式评审组的成员一般由公司内经验最丰富，技术最牛的人（技术总监）来担任，当然参加评审的人中间还应该有项目经理、QA人员、测试人员、架构师，他们仔细阅读需求规格说明书，并针对自己将要开展的工作内容进行检查，并提出问题
正式评审是最后一关，如果正式评审通过了，将进入系统设计阶段，如果在系统设计阶段再跨里程碑来修改需求的话，所花费的代价将大大增加。因此正式评审将是一个“鸡蛋里挑骨头”的过程，只有所有的人都认为需求已经没有什么可挑剔评审才能通过。 其实说句实话，理论说的再好，对于没有测试经验/评审经验的人来说，照本宣科也不是一件简单的事情。
毕竟需求评审是做好一个项目的第一步。
如果需求评审有问题，会给以后的测试工作的安排和进行带来很多的问题 请问对于项目需求评审,是否需要加入用户一起进行评审.
回复 9# 的帖子
需要，应由客户方派出客户代表进行业务方面的确认。回复 7# 的帖子
需求组一般把软件需求规格说明书同行评审通知发出，做为测试人员可对照需求规格说明书，对以下检查点可以做为重点检查：（１）需求项是否拆分到最小粒度，即对应到原子级的Use case? （２）是否所有的功能性需求都能映射到Use case?（３）软件需求规格说明书中是否包括了所有的Actor? （３）所有对其它需求项的内部交叉引用是否正确？（４）所有需求的编写在细节上是否都一致或者合适？（５）是否包括了每个需求的实现优先级？（６）是否在需求的描述中遗漏了必要的信息？（７）是否每一具体的Use case 涉及至少一个 Actor？（８）是否每个Use case 独立于其他Use case ？（如果两个用例总是以同样的顺序被激活，尽可能将他们并成一个．）（９）是否有Use case 事件流的描述是另外一个Use case 事件的一部分？（如果是，抽出这个子事件流）（１０）是否合理地确定了性能目标？（１１）是否可以根据高层需求（如业务需求、业务场景或数据需求）跟踪到软件功能需求？等一般召开评审会都会请到同行中的公司内经验最丰富，技术最牛的人来担任评审，以及项目经理、ＳＱＡ、ＱＡ、架构师、开发人员等甚至公司领导来参加，再对每个模块进行陈述时，参与开会的人员都可以对项目的功能、实现方式、需求进行讨论，讨论过程中没有达到统一的意见可以进行二次讨论，产生新的需求变更，一致的可以把意见记录下来做为评审意见，由组织者整理经与会者签字进行需求修改。 分层次评审
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
目标性需求：定义了整个系统需要达到的目标；
功能性需求：定义了整个系统必须完成的任务；
操作性需求：定义了完成每个任务的具体的人机交互；
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求
了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
需求分析人员对收集到的用户需求做进一步的分析和整理。
万年潜水艇上浮中！~~~ 需求分析师是项目中直接与客户接触的人，需求做的好不好决定项目成败，因此对于需求规格说明书的正确性必须进行彻底的验证，将错误在开工前就消灭。 根据项目管理的经验，进行需求评审不仅是必要的，而且是必须的。应该让不同角色的人员从不同的角度对需求进行验证，验证需求的可行性、完整性、一致性、正确性等 那么怎样才能做好需求评审呢?
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，在评审文档中存在大量的低级错误或者没有在评审前进行沟通，从而导致评审的效率很低，质量很差。
为了保证评审的质量和效率，首先要保证使不同角色的人员都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。
为了避免评审小组被冗长的软件需求规格说明所吓倒，在审查整个需求文档之前，可以在整个需求开发期间采用增量式评审和多种评审方式相结合的方法。找出风险高的地方，并进行仔细审查，而风险较小的部分则可以采用非正式评审。。
需求在通过正式的评审和批准之后。应该确定需求基线，进一步的需求变更将在此基线的基础上，依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。 :lol 我随便说说的哈~ 说错的大家见谅~ 就实际工作上来说需求评审需要针对开发设计进行 开发设计应能够应对足够的不可预期的需求变更 所以需求评审的基础之一就要求开发设计需要有足够灵活的框架来应对变更 当然咯，前提之一还是需要满足既定的需求
页:
[1]
2
