大多数从事软件开发的人士都有这样的体会，需求分析是一个软件成功与否的关键。在当今软件工程领域出现的许多问题，都源于需求的不清晰。
正因为如此，我们现在面临的客户，我们的项目经理自身，以及我们的管理层已经开始严控需求。我们不仅定制了需求提交的流程，还定制了需求说明的格式。但在实际操作过程中，通常是大家先做了一份用户需求，然后花费大量时间写软件需求，以满足认证和立项的需要。但到头来软件需求根本没人看，开发过程全凭项目经理和团队的理解进行。大家都只是应付，“软件成功与否的关键”成了摆设，我们很多时候没理解需求就匆忙入手，导致“需求变更乃万恶之源”。
在这里我不是讲怎么进行需求调研，也不是讲怎么去写需求文档，而是从我们的实际出发，阐述一下召开技术部内部的需求评审会。
1.概述
技术部内部需求评审会是在需求基本确定的情况，从技术实施的角度来评审项目需求，找出不确定的、不清晰、有歧义的需求。其目的是帮助项目组真正理解项目需求，理解项目目标，辅助项目设计，从而制定合理的项目计划。
参加人员成员包括公司项目管理团队，项目开发团队，产品线专家，技术专家，将采用头脑风暴法来评审需求，提出对需求的见解。
技术部内部需求评审会是在需求基本确定的情况下召开的，针对“客户原始需求记录”、“需求说明书”进行分析评审。
2、需求评审过程
2.1 客户原始需求介绍
需求评审会的第一步就是针对客户原始需求的介绍，由市场人员或者售前工程师讲解用户的原始需求，可能就是几句话，如“需要对脚本自动制作”等。通过客户原始需求的了解，参加会议的人员就可以了解项目的初步目标是什么。
2.2 需求说明介绍
在对项目的基本目标了解以后，我们可以让需求调研人员介绍详细的需求，讲解需求说明书。讲解接口需求、界面需求、实施需求、功能需求、硬件需求等。与会人员在听得过程中，记录自己不清楚的地方，或是需求描述模糊的地方。
2.3 头脑风暴
对于需求说明书，展开头脑风暴式的探讨。谁都可以提问，提出自己认为有问题或者不解的地方。如果需求调研人员无法解释清楚，如果一个描述可能导致几种理解，就说明在这个点上是个风险点，需要再跟客户确认。
同时，我们可以根据需求说明来探讨设计方案，探讨对于某个功能怎么设计合理；探讨某个模块是不是在别的项目组实施过，可以复用；探讨项目中的技术难点；探讨项目中的风险点；探讨实施计划的初步模型；探讨项目组的组建；......
3 评审结果
需求评审会评审的结果不是对需求调研的成功打分，主要是找到需求说明书中的风险点，帮助项目经理去把握需求，指导和辅助需求设计。
同时实现各个项目中间的经验共享，模块最大化重用，减少实施的风险和代价。