软件要求审查会重要吗？
我经常问自己，软件完成需求调查后，会进行需求分析，再进行概要设计、详细设计、系统开发和测试，然后交付给客户使用。 但是，交给客户时，完全偏离了客户的需求期望。 为什么会这样呢？ 我记得以前我们玩过隔板的留言游戏。 第一个人把正确的语言传达给下一个人，……，成为最后一个人的时候，语言无法变成原来的语言，带来了很多笑声。
而软件的需求就像一句话，在需求逐步发展的时候，你的需求会不断地确认和确认，这样软件最初的需求预期最终会和你想要的结果一致。 需求是软件开发最重要的输入，需求风险也往往是软件开发过程中最大的风险。 降低需求风险的重要手段之一是需求评审，而需求评审是所有评审活动中最难、最容易被忽视的评审。
首先，我们来看看如果没有需求审查，或者需求审查不成功，会产生什么结果。
案例一
某领域的专家A先生对某企业的成本管理系统进行了用户需求报告的审查工作。 评审会开始不久，被在场的企业副总经理B先生打断，认为A先生提出的方案不适合本公司，A先生提出的管理改进方案不能在企业实施。 这位副厂长发表意见后，参加会议的用户方面人员纷纷提出B先生的反对意见，使得评审会无法再进行下去，最终这份报告被用户否决了。
案例二
某软件公司内部举行了产品需求审查会，主要由公司内部的领域专家参加。 评审会开始不久，一位领域的专家就需求报告中的某个具体问题提出了自己的看法。 于是，参加者纷纷就这个问题发表了自己的意见，大家都在争执。 结果，会议陷入混乱，主持人无法控制局面，会议大大超过了按计划的审查时间。
案例三
某软件公司为某公司a举办业务流程管理系统需求审查会，项目组人员在会议上宣读上百页需求报告时，用户提出听不清楚，会议不得不日后举行。
案例四
某软件公司在用户处召开物资管理系统需求审查会后，走出会议室时，对会议效果不大，完全是走过场，摇了摇头。
案例五
某软件公司在公司内部召开产品需求审查会时，由于需求报告的撰写者和产品策划的主要策划人的想法大相径庭，没有必要继续召开需求审查会。
以上现象可以在很多项目中看到。 概括起来，需求审查中常见的问题有：
需求报告长，短时间内审核者无法阅读和澄清需求报告；
没有事先准备，需求审查效率低
无法控制需求审查的速度；
由于找不到合格的评委，参加的评委无法提出深刻的问题
……
http://www.Sina.com/http://www.Sina.com /
我知道用户的需求可以分层。 一般分为以下几个层次。
目标要求：定义整个系统要实现的目标
功能要求：定义整个系统要完成的任务。
可操作性要求：定义了完成各项任务的具体人机交互；
性需求由企业高层管理者关注，功能性需求由企业fndjm关注，可操作性需求由企业具体操作者关注。 针对不同层次的需求，其描述形式不同，参与评审的人也不同。 让具体的工作者评论目标需求，可能容易出现“捡芝麻丢了西瓜”的现象，但如果让高层管理者也评论这些工作需求，必然会造成资源浪费和情况3。
那么究竟如何做好需求评审呢？
正式评审是以召开评审会的形式，组织多位专家，召集需求相关人员，定义参与评审人员的职责和职责，对需求进行正式的会议评审。 非正式审查没有这种严格的组织形式，一般不需要召集人进行审查，而是通过电子邮件、文件汇款、甚至网络聊天等多种形式来审查需求。 两种形式各有利弊，但非正式审查往往比正式审查更有效率，更容易发现问题。 因此，在评审时，应该更加灵活地利用这两种方式。建议一：分层次评审
在需求形成的过程中应该进行阶段性的评审，而不是等到需求最终形成之后再进行评审。 分阶段评审可以将本来必须进行的大规模评审分割为各个小规模评审，降低需求返工的风险，提高评审的质量。 例如，可以在形成目标需求之后进行评审，在形成系统的初始概要需求之后进行评审，将概要需求细分为几个部分，对每一部分进行单独的评审，最终评审整体需求。
建议二：正式评审与非正式评审结合
需求评审可能涉及的人员包括：需方的高层管理人员、fndjm、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。建议五：对评审员进行培训
在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训2种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。
建议六：充分利用需求评审检查单
需求检查单是很好的评审工具，需求检查单可以分成2类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。
建议七：建立标准的评审流程
对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。
建议八：做好评审后的跟踪工作
在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
建议九：充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。
总之，记住一句话：需求评审太重要了，在实践中细心体会、实施上述的9个建议，相信您定会受益非浅。
参考：http://tech.it168.com/d/2008-04-07/200804042123838.shtml