个人觉得这个问题的侧重点在“评审”上面了，如何评审才是有效的？不管是“需求的评审”还是“概要设计/详细设计的评审等等。需要深究的应该是“如何评审”。。。 通常需求分为用户的原始需求（需求包）和设计需求（需求规格说明书）。
需求的评审除了各位朋友讲到的如何组织评审，选取哪些评审专家，提前几天发出被评审对象，如何再评审会上提前对收集到的意见进行汇总答复外，还要在会上进一步讨论一些有疑义的问题，以便澄清给出答复，并行成评审纪要。这些应该在公司的《评审流程》中进行规定。
除了上述这些比较笼统的做法之外，确保评审质量还有一个关键就是面对这个评审对象我们应该评审什么？关键点都有哪些？这就涉及到《需求评审的checklist》的建立，它是一个需求评审的作业指导书，当然在这个指导书中，作为测试成员，必须要关注需求的可测试性，可用性，易用性和可维护性等需求。
《需求评审的checklist》示例：
目的：我觉得需求评审的目的是为了检查需求的合理性和可实现性。
参与人员：需求评审的参与人员主要包括：
--需求提出方：产品经理或者第三方
--系统架构师：架构师可以更好的把握系统架构，检查需求的可实现性
--开发工程师：开发工程师最了解需求实现难度和是否能实现
--测试工程师：从测试的角度评价需求合理性
--客户服务人员：客户和最终用户距离最近，对一般用户了解较多，因此客服人员可以更好的站在用户角度考虑问题
需求评审的准备和进行：需求评审之前，需求提出方最好提前把需求文档发给需要参会的相关人员， 让大家有时间考虑的更深入和更全面
召开需求评审的会议时，对于一致通过的需求，可以过速的通过，对于各方有疑问和提出疑义的问题，需要一起讨论，给出大致的方案。
需求评审完成后，需要会议记录人员发送纪要给各方，并发需求的问题和解决方案写清楚。 会议上没有解决的问题，如果是小问题，可以通过邮件方式讨论，如果需要，可以再次召开需求评审会议。
我转了个
需求测试总结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 编辑 ] :) 需求评审注重的是理解客户的需要，要站在客户的角度去想问题，最好是大家都了解客户需要怎样的软件，结合公司的开发水平进行有效的调整。
:loveliness: :loveliness: :loveliness: 个人见解。。
谢谢大家的回答
谢谢大家的回答，收益匪浅 写得很好哟！简约明白！回复 8# 的帖子
同意:)回复 2# 的帖子
谢谢2#的精彩回答回复 5# 的帖子
谢谢阿七简单的总结回复 16# 的帖子
说的很好，不过和2#的部分内容重复了 谢谢大家的精彩回答，我会好好总结一下的 关于需求评审，如何开，这个无论学院派，还是我们的实践者，大家都知道如何进行，如何定义自己的评审流程，但是关键的问题是，很多公司不按照上面的流程走，而且提出了很多不这样走的主观和客观原因，如，项目进度紧，人员能力有限，以前评审都流于形式没有评审出实质的内容，管理者的不支持，以及评审完成之后，相应的数据都没有很好的收集，我想如何有效的召开评审会议，在我们制定好的流程基础上更关键的让项目组严格的执行，以及我们要发现评审的时候，有些过程不足，我们要不断的改进，这才是有效性的根本问题，让项目组真正的接受评审，在评审前严格的作准备工作，输入一定要明确，准确。严格的执行评审，评审的时候关注的问题点，这些作为相应的利益者都应该很清楚，对结果进行有效的分析和判断，千万不能流于形式，同时要加强培训，要将评审的作用，过程深入项目组，深入人心！这才是根本。对一些流程的定义，可能由于每个公司的特点可能不太一样，如一个开发产品的公司和外包的公司肯定是有不同的，即时大家都是外包的，每个公司也很难相同，所以公司的QA部门制定流程的时候，要多考虑公司的实际，如果一个刚起步的公司，上来就给他们按照楼上各位所说的那么全面，那么执行的难度可想而知，我们关注的，我们制定的流程有多少是真正的做了，而不是我制定了多少！ mark 哎，……看看…… 25楼转过来的内容已非常丰富了，如果按照这些去需求评审，肯定能达到很不错的效果。 MAKE 新人才顶
页:
1
[2]
