首先，需求分析人员应该接受一定的正规培训，以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧，以及收集整理资料的能力等。在参与具体项目时，分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识，以更好地理解用户的需求。

　　其次，开发单位应该对那些不想花时间在需求分析上的用户明确指出：如果用户不能充分地支持并参与，项目很可能会失败；开发单位还可以通过学习一些前车之鉴的真实案例警告用户：低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训，使他们真正理解需求分析的重要性和忽略需求带来的风险，并对计算机系统有一个大体的了解，这样用户才能够主动地参与需求分析。

　　同时，正因为不可能一次完全了解用户的需求，而且在系统开发过程中还需要不断地请用户参与，因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此，需求分析人员需要对用户解释一些做法的必要性和合理性，以得到用户大的支持与合作。

　　（2）从业务需求入手。用户认识到了需求分析的重要性，但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手，任何企业对自己的经营运作目标应该是比较清楚的，这样的经营背景让用户不仅有话说，也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离，只有当系统真正置身于它的社会和组织环境中，它的需求才能清晰地反映出来。

　　（3）充分利用需求来源。有了以上需求背景，比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件；观察系统的潜在用户当前的日常工作以获取有价值的信息；系统的使用者可能有很多，可以将他们分类以简化需求；后一定要与真正的决定者达成协议：对于有冲突的需求如何权衡，对于直接用户的众多需求如何取舍等。

　　同时，用户往往对计算机期望过高，认为计算机可以解决当前存在的所有问题，因此会提出很多的功能需求，并且希望在很短的时间内看到成效。但是，由于技术、人力等资源的限制，并不一定能够在设定的时间期限内满足用户所有的期望，这时应该尽早确定出交付的产品应具备的重要功能，即设定需求的优先级。

　　在这个阶段，可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发，而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉，容易沟通；而且不会在需求分析的一开始陷入过于细节化的设计，也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。

　　（4）提供选择方案。由于用户对软件系统缺乏经验，或者由于用户的运作机制还未完善，或者由于其他种种原因，用户可能仍然不能对一些需求做出明确的说明，收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点，供用户选择或者启发用户确定需求。

　　如果需求分析做得好，文档清晰且又有客户签字，那么后期客户提出的变更超出了合同范围，需要另外收费。这个时候，开发方一定要据理力争，此时这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。

　　2、分级管理客户需求

　　软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全的正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到了客户的投入收益，所以有的时候项目经理反倒应该为客户着想。

　　对于项目中的需求变更，可以实行分级管理，以达到对需求变更的控制。

　　一级需求变更是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。这个级别的需求是必须满足的，否则意味着否定自已的项目成员和成员的所有努力，所以定为“Urgent”。

　　二级需求变更是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续，所以是“Necessary”。一般新模块关键性的基础组件，属于这个级别。