客户向我们反映在和你们的工程师谈论需求时，他们总是满口答应没问题。可是，当他们做好以后，拿过来一看，根本就不是这么回事。而开发人员也在诉苦：用户什么都不懂，而且他们的需求老是变动，时间又这么紧，你让我们怎么办?

　　我觉得如果开发人员在做需求分析时，如果注意以下几点，也许可以避免被动的局面.

　　1、掌握相关的行业知识

　　在和客户沟通之前，最好了解一下相关的行业知识。

　　有一个项目管理人员说：行业知识可有可无，作为需求人员，最重要的是和客户沟通。最好把客户讲的东西都记下来。然后，由项目组决定后，再把意见反馈给用户。这种沟通方式，既不能有效的发现问题，也容易延误项目时间。

　　案例：

　　小A某名牌大学毕业，公司为了锻炼他，特意安排他和一个比较重要的客户进行一次沟通。小A和客户电话联系，商定了见面的时间和地点。西装革履的小A提前十分钟来到了见面的地点。一番客套之后，小A和客户就开始进入话题。客户开始谈他的需求，从项目背景到项目目的，从业务流程到相关部门和人员。客户兴致勃勃地说着，小A手忙脚乱的记着。客户停下来，问小A你觉得我的观点有什么需要补充吗?小A老实地回答说，我对业务还不是很熟悉。客户一下兴致全无，对小A说，等你对业务熟悉了，再来找我把。

　　2、重在沟通

　　沟通的方式可以是访谈和调研、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。我的意见是最好是与客户面对面的沟通。金庸武侠小说中的高手过招，都是面带微笑，不露声色，比拼的是内力。面对面的沟通，就是比拼内力。所以，一定要把准备工作都做好了。

　　沟通其实也是在相互妥协。对用户合理的要求，要尽量满足。用户的一些不合理的要求，要想办法避免。要委婉地提醒用户，如果这样做，可能要增加项目时间，或者对运行环境有更高的要求。

　　沟通一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。

　　3、深究细节

　　不要等到项目做好后，才让客户发现问题。

　　客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的.这时，在客户看来当然需要更改.但这种更改却被我们看成了需求的更改。既然是需求的更改，那么就需要增加项目成本(资源) 或延长项目时间。我看过一篇文章，说要要想项目成功，就得和用户建立亲密的伙伴关系.可是，这种以需求的更改为理由让用户从口袋里掏钱，亲兄弟也不干阿.

　　所以，需求分析不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。

　　需求是最重要的工作，也是最麻烦的。 客户是不懂需求的，他们的脑海里面没有这个概念， 他们只希望你做出能用的系统 ，用着顺手就好

　　我认为做需求有几个地方是比较关键的

　　1.人际交往能力 。这是最根本的 不用多说

　　2.了解需求后及时做出demo让客户确认，确认后要签字。这一点非常重要，很多时候我们了解了需求就闷头开发，等开发完毕后，却不是客户想要的东西，造成巨大浪费;签字是为了让客户认真对待这个demo

　　3.能用就好，不要过多追求。程序员往往追求完美，想一下子把工作做到位;而最有效率的方法是尽快看到结果 然后再慢慢完善。在项目初期需求会经常改变，这样的目的也是避免把过多时间耗在无用的需求上。