在创建需求的时候，有一个"不需要评审"的复选框，如果选中该复选框的话，需求的创建成功后状态是激活的。
但大部分情况下面，需求还是需要评审的。
- 即使产品完全由一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。
- 开发、测试在实际开发、测试工作中，根据具体的工作会发现一些需要优化的需求，他们提交的新需求需要评审。
- 技术支持在和用户客户对接时，会从用户客户那获取一些新需求，他们提交的新需求也是需要评审的。
- 凡是对需求标题、描述、验证标准和附件的修改，都应该走变更流程。变更之后的需求状态为已变更，也是需要进行评审的。
本文档我们将介绍需求的评审流程和方式。
一、需求评审的规则、流程、结果
需求的评审规则、流程、结果，我们可以在后台–自定义–需求里查看和设置。
评审规则：
评审结果：
评审的流程：
默认是开启评审流程的，不管是开启评审还是关闭评审流程时，可以设置强制评审。
强制评审中的成员，提交的需求，都必须走评审流程。
二、需求的评审人
创建和编辑产品时，我们新增了产品评审人的字段。
设置了产品评审人，那么在该产品下创建需求、变更需求时，需要评审时，默认的评审人就是设置的产品评审人。
评审人可以设置1人也可以设置多人。
设置好了评审人后，创建需求和批量创建需求时，由谁评审的下拉列表就只显示设置的评审人。
变更需求时，由谁评审也默认列出设置的评审人。
三、需求的超级评审人
禅道16.0版本开始新增了超级评审人功能。
超级评审人不受任何评审规则的限制，超级评审人有一票否决权。
超级评审人和评审人一样可以设置多人。
在后台–自定义–评审规则–超级评审人里，可以设置我们的超级评审人。
即便该需求之前由多人评审，且其中某一个评审人已评审拒绝，但是当超级评审人去评审该需求时，
不受之前的评审规则限制，最后都以超级评审人的评审结果为本轮需求评审的最终结果。
需求的历史记录也会记录超级评审人评审的时间、评审意见以及结果。
四、需求的多人评审
需求在创建和变更时，由谁评审可以选择多人。之前只能由一人评审，现在可以实现多人评审一个需求。
多人评审需求时，设置了评审规则。需求是否评审通过根据评审规则和实际评审人的评审结果进行计算，最终得出需求的评审结果。
4.1 设置评审规则
评审规则可以到后台–自定义–需求–评审规则里进行选择。
我们提供两种规则：评审结果全部通过时该需求为评审通过（全部通过通过）；评审结果半数以上通过时该需求为评审通过（半数以上通过通过）。
4.2 创建需求时的多人评审
单个创建和批量创建需求时，由谁评审可以选择多人评审。
单个创建需求时：
成功创建多人评审的需求后，需求的状态为草稿。
待提交评审后，需求的状态改为评审中。
当所有评审人都评审完成后，根据评审规则计算结果后，根据结果来判断是否需要更改需求的状态：
首先根据后台设置的”全数通过“和”半数通过“原则校验是否满足需求是否通过，通过后，需求状态改为激活。
未通过的需求根据票数判断，若选择”拒绝“的票数多，则需求被拒绝， 需求状态改为已关闭；若选择”有待明确“的票数多，则需求退回草稿状态，待用户修改后再提交评审。
4.3 变更需求时的多人评审
变更需求时，也可以选择多人进行评审。
变更后的需求可以暂存，状态变为变更中。
待提交评审后，需求的状态改为评审中。
当所有评审人都评审完成后，根据评审规则计算结果后，根据结果来判断是否需要更改需求的状态：
- 首先根据后台设置的”全数通过“和”半数通过“原则校验是否满足需求是否通过，通过后，需求状态改为激活。
- 未通过的需求根据票数判断，若选择”撤销变更“的票数多，则需求被拒绝， 需求内容会回退至上一版本，需求状态重新改为激活；若选择”有待明确“的票数多，则需求退回变更中状态，待用户修改后再提交评审。
五、需求的撤销评审
需求发起评审后，如果发现还有需求标题、描述、验收标准和附件还需求修改。
为了避免进行多轮次的评审。
我们提供了撤销评审功能，首先需要去后台–人员–权限的权限分组里分配撤销评审的权限。
在产品–需求列表中发起评审的需求的操作栏里显示撤销按钮。
点击撤销评审按钮后，需要重新发起评审，才可以继续进入评审流程。
需求的历史记录中会记录撤销评审和重新变更发起评审的历史信息。
方便进行操作的追溯和查看。
/web/data/upload/zentao/202411/f_7a9413bfb917d51913f225014d69afc1.jpg)
需求的历史记录中会记录撤销评审和重新变更发起评审的历史信息。
方便进行操作的追溯和查看。
