需求评审是需求开发阶段的最后工作，需求评审一旦通过，将进入ERP系统设计阶段，如果在ERP系统设计甚至后续阶段再跨里程碑来修改需求，所花费的代价将大大增加，因此，需求评审讲一个“鸡蛋里挑骨头”的过程，只有所有人都认为需求已经没事有什么可以挑剔的了，评审才能通过。
在如何做好需求评审工作方面，业内人士总结了一些经验，简单列举如下：
（1）分层次评审，用户的需求是分层次的，对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。
（2）正式评审于非正式评审相结合，正式评审与非正式评审各有利弊，但往往非正式比正式评审效率更高，更容易发现问题，因此，在评审时，应该更灵活的利用这两种方式。
（3）分阶段评审，应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后在进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。
（4）精心挑选评审人员，需求评选可能涉及的人员包括建设单位的中高层管理人员和操作永远，IT主管和采购主管，承建单位的市场人员，系统分析师，系统架构设计师，软件工程师，测试人员，质量保证人员，实施人员和项目经理，以及第三方的领域专家等，为了保证评审的质量和效率，需要精心挑选评审人员，首先，要保证是不同类型的人员都参与进来，否则，很可能会漏掉重要的需求，其次，在不同类型的人员中要选择那些真正和系统相关的，对ERP系统有足够了解的人员参与进来。
（5）对评审人员进行培训，在很多情况下，评审人员是领域专家而不是进行评审活动的专家，他们没有掌握评审的方法，技巧和过程等，因此，需要对它们进行培训，以便于评审人员能够紧紧的围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率。
（6）充分利用需求评审检查单，需求评审检查单可以帮助评审人员系统而全面的发现需求中的问题，需求评审检查可以分为两大类，分别是需求形式的检查单和需求内容的检查单，需求内容的检查单可有由质量保证人员负责，主要检查SRS的格式是否符合质量标准，需求内容的检查是由评审人员负责的，主要检查需求内容是否达到了系统目标，是否有遗漏，是否有错误等，这事需求评审的重点。
（7）建立标准的评审流程，需求评审需要建立正规的流程，按照流程中定义的活动进行规范的评审过程，例如，在评审流程定义中可能规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤和评审通过的条件等。
（8）做好评审后的跟踪工作，在需求评审后，需要根据评审人员提出的问题进行评价，以确定那些问题是必须纠正的，那些可以不纠正，并给出充分的客观的理由和证据，当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审，切记评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期努力付之东流。
（9）充分准备评审，评审的质量好坏很大程度上取决有评审会议前的准备活动，通常出现的问题是，SRS在评审会议前并没有提前下发给评审人员，没有留出更多，更充分的时间让评审人员阅读需求文档，更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量，低级的错误，或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差，对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实没想准备工作。
软件资讯
免费服务热线：
客服海兵