小项目怎么做需求分析?

在做项目时，经常会碰到这样的事情.
客户向我们反映在和你们的工程师谈论需求时，他们总是满口答应没问题。可是，当他们做好以后，拿过来一看，根本就不是这么回事。而开发人员也在诉苦：用户什么都不懂，而且他们的需求老是变动，时间又这么紧,你让我们怎么办？
我觉得如果开发人员在做需求分析时,如果注意以下几点,也许可以避免被动的局面.

1、掌握相关的行业知识
  在和客户沟通之前，最好了解一下相关的行业知识。
  有一个项目管理人员说：行业知识可有可无，作为需求人员，最重要的是和客户沟通。最好把客户讲的东西都记下来。然后，由项目组决定后，再把意见反馈给用户。这种沟通方式，既不能有效的发现问题，也容易延误项目时间。
   案例：
   小A某名牌大学毕业，公司为了锻炼他，特意安排他和一个比较重要的客户进行一次沟通。小A和客户电话联系，商定了见面的时间和地点。西装革履的小A提前十分钟来到了见面的地点。一番客套之后，小A和客户就开始进入话题。客户开始谈他的需求，从项目背景到项目目的，从业务流程到相关部门和人员。客户兴致勃勃地说着，小A手忙脚乱的记着。客户停下来，问小A你觉得我的观点有什么需要补充吗？小A老实地回答说，我对业务还不是很熟悉。客户一下兴致全无，对小A说，等你对业务熟悉了，再来找我把。

2、重在沟通
  沟通的方式可以是访谈和调研、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。我的意见是最好是与客户面对面的沟通。金庸武侠小说中的高手过招，都是面带微笑，不露声色，比拼的是内力。面对面的沟通，就是比拼内力。所以，一定要把准备工作都做好了。
  沟通其实也是在相互妥协。对用户合理的要求，要尽量满足。用户的一些不合理的要求，要想办法避免。要委婉地提醒用户，如果这样做，可能要增加项目时间，或者对运行环境有更高的要求。
  沟通一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。

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

这个。。。
不局限于小项目吧，
大一点的项目做需求也得要遵循这些东东啊

学习项目开发管理中。。。

需求是最重要的工作，也是最麻烦的。 客户是不懂需求的，他们的脑海里面没有这个概念， 他们只希望你做出能用的系统 ，用着顺手就好
我认为做需求有几个地方是比较关键的
1.人际交往能力 。这是最根本的 不用多说
2.了解需求后及时做出demo让客户确认，确认后要签字。这一点非常重要，很多时候我们了解了需求就闷头开发，等开发完毕后，却不是客户想要的东西，造成巨大浪费；签字是为了让客户认真对待这个demo
3.能用就好，不要过多追求。程序员往往追求完美，想一下子把工作做到位；而最有效率的方法是尽快看到结果 然后再慢慢完善。在项目初期需求会经常改变，这样的目的也是避免把过多时间耗在无用的需求上。

签字可能就越过了需求分析的权限了。
一般来说，只要把会议纪要，demo等相关成果物给客户，领导过目，只要他们没意见，基本就可以了开工了。

麻雀虽小，五脏俱全。

小的和大的都一样，只是小的在一些相对比较弱的地方，可以花更少的时间，原则上全部都要做。

调研的过程很像记者的采访过程，先要有准备，调研过程讲究策略和方法，调研结束后要注意整理和信息挖掘

如果需求难以确定的项目，与客户确认的周期越短越好

基于原型快速开发法则，没空做个页面画个草图跟用户交流也是好的。