需求评审
1．需求阶段评审的角色和职责
一句话，根据具体情况选择相关人员，充当相关角色，履行相关职责，大家也别吐槽我，现实就是这样，别去记忆这些死规则了
2．好的需求应具备的特点
完整性：每一项需求都必须将所有要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确的陈述其要开发的功能。
一致性：指与其它软件需求或高层需求不相矛盾
可行性：每一项需求都必须是已系统和环境的权能和限制范围可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求简明的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：可理解为每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。
可修改性：每项需求只应在SRS中出现一次。这样更改时容易保持一致性。另外，使用目录列表、索引和相互参照列表方法使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f i n e - g r a i n e d )的方式编写并单独标明，而不是大段大段的叙述。
分配优先级：应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度
以上特点也是需求评审的要点，评审前可以根据实际情况指定需求评审检查表来帮助评审。
可以根据以上特点对需求进行评审
3．软件需求评审输出
还是一句话，根据具体情况适当的做好评审记录，形式不限，输出文档名称也不限，随便你取，^^内容才是重点
4．组织需求评审原则
还是一句话，组织自己定吧，适合就好，效率优先 ^^，别吐槽，没骗你的，不信你百度去，可以百度出不同答案
5.需求评审形式
总 体来说可以分为正式评审与非正式评审。正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职 责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天 等多种形式对需求进行评审。2种形式各有利弊，在评审时，灵活地利用这2种方式。
仔细来说，可以分为如下：
(1)相互评审、交叉评审( Pear-to-pear Review )，甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查，相互评审是最不正式的一种评审形式，但应用方便、有效，被普遍使用
(2)轮查( Pass-round )，又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收集他们的反馈意见。是一种一种非正式的同行评审。
(3)走查(Walkthrough )，产品的作者将产品在现场向一组同事介绍，描述产品要有怎样的功能、结构，从头到尾走一遍，以收集大家的意见。希望参与评审的其他同事可以发现产品中的错误，并能进行现场讨论这种形式介于正式和非正式之间，其应用普遍。是一种一种非正式的同行评审
(4)小组评审(Group Review)，通过正式的小组会议完成评审工作，是有计划的和结构化的评审形式。评审定义了评审会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进行了独立研究。
(5)审查(Inspection )。审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、准备和组织会议、跟踪和分析审查结果等。
6.需求评审的策略
(1)分层次评审
一般，可以分成如下的层次：
*目标性需求指整个系统需要达到的业务目标，是最高层次的、基本的需求，是企业的高层管理人员所关注的。如果让具体的操作人员去评审目标性需求，容易导致“捡了芝麻，丢了西瓜”的现象。
*功能性需求指整个系统需要实现的功能和任务，是目标之下的第二层需求，是企业的中层管理人员所关注的。
*操作性需求指完成每个任务具体的人机交互〔UI)需求，是企业的具体操作人员所关注的。
(2)分阶段评审
应该在需求形成的过程中进行分阶段的多次评审，而不是在需求最终形成后才进行仅有的一次评审分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，这样就降低了需求分析返工的风险，提高了评审的质量。
这点对于敏捷开发模式特别有效。需求按版本为单位划分，根据版本进行需求评审（确定做啥，是不是那样做），通过后开发针对该版本需求进行开发，测试根据需求进行用例编写和维护，然后按这种模式进行迭代。
7.注意事项
精心挑选评审人员->定制规范化评审流程->准备好评审材料->做好结果跟踪工作等
关于需求评审
1、 传统的软件开发模式中，太过依赖文档，有各种各样的文档，需求说明书，比如市场需求说明书，业务需求说明书， 软件概要说明书，软件详细设计文档等等，这些文档在追求速度的时代却似乎效用不大，很多时候反而成了负担。怎么解决这个问题？
去掉无用的功能定义文档、需求文档可行方法：
想法快速制作成静态的原型->>根据“市场效果反馈”修改原型设计->>用真实数据建立一个动态原型->去除累赘
这样，以实际的界面或原型来说明你要构建一个真正的产品，是很好的方法。
从这个点出发，我们可以把重心从“需求文档评审”转移到“原型(Demo)评审”,以原型评审为中心，辅以必要的文档说明，作为原型的补充。
2、 三方协作
也就是说，每项功能需求的讨论都要开发人员，测试人员，产品人员的参与，有参与才有认同，开发前必须达成一致
3、各种评审会上，一定要有个能做决定的人，因为评审的时候各方不可避免地会对需求有不同理解，从而出现争论，公说公有理，婆说婆有理，谁也说服不了谁，会议相关人都要参与
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
