原文链接 CSDN igreenhill
问题描述：我们公司快要成立测试部了，之前我们一直是研发部下的测试小组，在成立之前，我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求，我们几个都没有相关的经验，所以我在此求助大家，邀大家来讨论下：如何进行需求评审？怎样的需求评审机制才是有效的？
精彩回答：
关于需求评审，首先我觉得应该解决的是可用的评审可用资源问题，只有把这个问题解决了，其评审结果才可以采信，否则不过形式尔耳。
关于需求评审的一些必备资源，我这里选列了相关角色，如下列：
* 业务专家或是熟悉该业务的人员（通常也叫业务方代表）
* 文档审查人员
* 架构师
* 需求分析师
* 需求评审组织人员及记录人员
当然，除了人员意外，必要的时间、场地和上层决策者的支持也是不可或缺的。
这些资源一旦准备停当，接下来就是如何安排评审事宜的问题了。我这里简单列下以往曾做过的一轮需求评审的过程：
* 准备阶段（P）
o 争取上层决策者的支持与谅解
o 筹备相关的资源，包括人力、时间计划，评审场地
o 在正式评审之前，将相关的需求记录（文档或其他形式）发布给每个参与评审的人员手中，并确保其有足够的时间可以通阅需求并做好评审前的相关质疑与确认记录
o 在正式评审之前，会议组织者应先收集相关评审人员的各项需求评审建议和意见，对存在争议和疑惑的需求说明必须做好讨论的安排
o 发布经确认后的评审计划或时间表
* 实施阶段（D）
o 由评审组织者召集各评审人员集中评议，可以以正式的会议等形式组织，此处以会议为形式做说明
o 与会人就某具体的问题进行讨论，讨论的优先级如下所列
* 最重要的业务内容，一般是按流程、功能、细节来排定
* 争议或疑问较多的地方
* 部分有争议的地方
* 对于没有提出疑义的地方，可以快速流过
o 最后，要注意一定要回顾已提出问题和有结论的地方
o 由会议记录人员整理会议的纲要，记录各与会人员的相关意见，并在会后递交纪要
* 检查再实施阶段（C）
o 对评审得出结论的问题进行再次确认和修正补充
o 确定下次评审的时间
o 按照第一阶段的流程再次进行组织，并确认结果
o 对大多数组织，两次评审可以解决大部分的问题，对于悬而未决的问题，如影响范围有限，则可以延后讨论解决
* 总结阶段（A）
o 就以上内容做最后的确认，需求定稿，各方签字确认。
o 今后的变更转入需求变更流程，其后产生的评审为小范围内评审。
4#给出了一项检查清单，作为文档审查人员审查需求的参考检查表使用，大家可以在进行需求评审时参考使用。
建议一：分层次评审
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
* 目标性需求：定义了整个系统需要达到的目标；
* 功能性需求：定义了整个系统必须完成的任务；
* 操作性需求：定义了完成每个任务的具体的人机交互；
目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。
建议二：正式评审与非正式评审结合
正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这2种方式。
建议三：分阶段评审
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。
建议四：精心挑选评审员
需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。
建议五：对评审员进行培训
在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训2种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。
建议六：充分利用需求评审检查单
需求检查单是很好的评审工具，需求检查单可以分成2类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。
建议七：建立标准的评审流程
对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。
建议八：做好评审后的跟踪工作
在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
建议九：充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。
一、 注意对需求规格说明的正确性进行评审
需求规格说明的正确性通常可以从如下方面得以体现：
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 需求文档正式进入了配置库。
相关文章
