《如何做好需求评审？.doc》由会员分享，可在线阅读，更多相关《如何做好需求评审？.doc（6页珍藏版）》请在金锄头文库上搜索。
1、如何做好需求评审？如何做好需求评审？需求评审的重要性大家都知道，我简单列出几点：1.软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半! 所以，需求的质量很大程度上决定了项目质量或产品质量。2.需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段带来的风险，就要把需求评审做好。3.需求评审做不好的后果：需求变更需求不明确需求不可测需求不可实现导致后续工作难于开展或经常出现变更。4、产品经理：不识庐山真面目，只缘身在此山中，需求是自己写的，容易受到固定思维的限制，所以，需要一双没有看过这个需求的眼睛来检查一下，有什么问题。先大概说一下需求的不同类型：需求的不同层次：目标性需求：定
2、义了整个系统需要达到的目标;-高层关注功能性需求：定义了整个系统必须完成的任务;-中层关注操作性需求：定义了完成每个任务的具体的人机交互;-执行人员关注在做需求评审的时候，应该根据不同的需求层次，进行不同的评审。因为经常参加需求评审会议，所以对需求评审中常见的问题有所了解，现在举一些例子：1、某产品经理在主持需求评审会，评审开始时间不长，就被一位主管打断，明确指出此方案与企业业务发展方向不符，不能实施。紧接着其他与会人员纷纷发言表示同意，结果评审会无法继续进行，需求最终被否决。问题所在：缺乏初步沟通，目标性需求尚未明确，功能性需求和操作性需求无从谈起。2、某次需求评审会，主要是公司内部相关领域
3、的专家参加，在评审会开始后不久，某专家就对需求中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。问题所在：前期沟通和准备不够，缺乏应对不同意见的准备，难以化解争执。主持者不能有效把握会议目标，会议讨论过于关注细节，导致评审失控。3、某产品经理主持需求评审会，在讲解需求说明书时，与会人员似懂非懂，没有提出任何有价值的问题，致使会议没有得到预期效果，不得不改日重新进行。问题所在：前期准备和沟通不够，评审变成了培训。没有选择合适的评审人员，无法获得有价值的信息。4、某需求评审会，
4、与会人员各抒己见，气氛热烈，产品经理忙于收集意见，结果散会时发现对需求有价值的并不多，并且遗漏了许多要评审的问题，评审效果不佳。与会人员在离开会议室后，私下也认为评审没有多少实际效果，完全是在走过场。问题所在：评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。产品经理没有把握好会议主题，评审变成了头脑风暴。需求评审常见问题汇总目标性需求没有沟通好，后面的需求变成空中楼阁。缺乏评审的可操作依据，遗漏评审内容。没有作好前期准备工作，导致评审时间长，效率低。没有选择合适的评审人员，无法获得有价值的反馈。参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。针对以上问题，提出一些建议
5、：建议一、做好评审前的沟通和准备需求编写人员应将评审所需的资料准备齐全，数据、图表、其他相关资料等，并仔细检查以保证文档质量。需求文档在评审会议前应提前下发给参与评审会议的人员，并留出时间让参与评审的人员阅读需求文档。参加评审的人，应该是带着问题而来，而不是来参加培训的。建议二、先沟通好目标，再进行细节的落实。应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审保证了需求在形成的过程中不偏离方向，不出现大的错误，降低了需求返工的风险，提高了最终评审的质量建议三、正式评审与非正式评审相结合正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，
6、并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。非正式的评审通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。 两种形式各有利弊，因此在评审时，根据项目复杂程度，紧急程度不同，应该灵活地利用这两种方式。建议四、精心挑选评审员为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。(测试经常被遗忘哦!)在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，选择有经验的，而不是有时间的人。(teamleader选择参加，主要执行人员必须参加!针对评审目标选择参与者，避免高、中、低层一起评审。)建议五、充分利用需求检查单使评审有可操作依据，提高评审有效性，避免遗漏。便于收集评审数据，记录评审结果建议六、做好评审后的跟踪工作切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流发送项目状态通知，让相关人员周知需求评审已完成。说明需求经评审后改动的部分，如实现优先级、加入和裁减了哪些。
