用户需求是在变的，然后就是用户自己也无法对自己的业务有一个清晰的认识，开发人员然则不如用户了，所以说需求分析部分一般情况下不可能在项目进行的初期完成，即使完成，以后还有较大的修改，这是一种对业务模型的共同模糊所造成的，当然也有用户自己对自己业务有一个清晰认识和说明的，不过我还没遇到，这种情况对开发人员的要求非常大，所以有种情况是可行的，就是开发人员可以以很快的开发速度来完成他对由用户对业务模型认识的不断清晰而带来的重新改变己经完成的某些设计部分，如果开发人员不能完成对这种情况的快速反应，就会出现头痛等一系列问题，如果你可以以足够快的时间和速度来响应用户的这种要求，那么你们的合作会是快乐的，否则则会充满了意想不到的痛苦。
以上完全个人意见
同意lironghai 的说法，如果时时刻刻把客户当成上帝，那不但项目完了，你们公司也完了！！一个我认为比较好的变通办法是：如果用户需求变更比较大，那么可以把这部分工作放到二期去做，当然这需要一定的努力让用户理解你的工作，不过我想作为一个项目经理应该是有这个能力的，除非你的客户太过于固执或者他们根本不想让你做以后的工作
其实，如果目标系统是客户的核心业务系统，或者关键系统，就很少有失败的项目，因为客户方的重视程度不一样。我们正在开发的系统比较庞大，公司派出的开发团队稳定在80多人，客户方的技术人员、业务人员超过100人，封闭开发，遇到需求不明确等问题时也曾遇到楼上几位谈到的情况，但是不论如何都能解决，只是迟早。所以有几点我认为比较重要：
1、把客户项目当作自己的事情，不推诿；
2、控制局面，学会与客户有效沟通。
3、派有经验、有责任心、有耐心的骨干人员跟客户沟通。
4、减少硬编码，满足客户需求时有一定的预见性。
5、等等．．．
我看了楼上各位大虾的讨论,感觉到这是一个非常实际的软件工程方面的问题,实际上,在Software Engineering方面国外(特别是美国)比我们有多得多的经验,因为他们比我们起步的早!!!:),形成了一些系统化的方法论,如ISO9001、CMM等。因此,在这方面我就要好好向它们谦虚的学习,然后创新,来个后来居上.
但是,我们在学习过程中，往往没有学到其精髓，有时反而对其产生错误的理解。很多时候我们很多人只是纸上谈兵，满口ISO9001，CMM,这个标准，那个标准；就像当年孔乙已一样满口“知乎者也”，而客户往往只要你交付的产品会合他的要求，能够好用，也就OK了。
再就是，国外的那一套照搬照抄过来很多地方不一定适合我们国内的情况，因此我们必须在学人家的东西的过程中创造出自己的东东，我想这也就是“创新”了。而在这方面我们是做得很不够的，因此需要我们一代一代“软件人”不断的努力。有什么好的建设、想法，不管是成功的经验，还是失败的教训，拿出来大家一起分享，一起进步哦！！！：）
各位总结的都不错，收藏了
我也是刚刚从失败中来。我们的所有需求都是做成html静态页面来描述流程，需求分析内容都是和客户一一签字认可的。可是到中间时期，客户还是不断的提出更改需求，我们也就不断的迭代，累的是我们自己。真不知道该如何面对中国的客户呀。有点支持icean的想法，就是要培养客户的软件开发流程的思想。
我个人是这样认为的：
首先，做项目就要有把项目做到最小规模的心理准备，而且一开始就应该努力朝这样方向去做，不然一般的结果就是失败！
为什么要向着最小规模的方向去做，这样的道理其实是很简单的――这样的系统除去了所有花哨的功能，只保留了最基本的、最需要的功能，这样的系统相比之下是最简单的、最稳固的、最具有扩展性的。
为什么说最小系统是最简单、最稳固、最具可扩展性的？系统论中有个观点，就是简单系统才是最持久、最稳定的；复杂系统功能强大，但是相应的增加了很多不确定的因素，这导致系统内在的就有了不稳定性。在这里，我们承认这个原理，并且准备按照这个准则去进行需求的分析和项目的规划。
那么，我们怎么使用这个准则来分析需求和规划项目呢？概率论中有个观点，就是样本越多，我们依此得出的推断越接近真实。所以，需求分析中首先要做的就是大量的占有需求资料――当然，现实中真实的情况是往往随着项目的不断推进，大量的需求才开始涌现出来。因此，最有效的需求分析方法我的理解是这样的：在自己可以接触的范围内尽可能的收集需求，相关的或者不相关的（不相关的可以略看，不深入，但是最好能有个概念），尽可能在可以接触的范围内做到占有最多的需求样本。接着，在一定阶段内，对所占有的需求样本进行归纳分析，去除不必要的功能，只保留必须的功能，这就是当前需求（记住，当前需求的前提很重要，这说明随着时间的推移，需求可能会变，会增多）下的最小功能集。然后，把这个功能集中不易发生变化的部分和容易发生变化部分区分开来（区分的标准是，考虑在多种需求下哪些功能是相对固定的，哪些功能是容易随着需求的不同发生变更的）。在面向对象的编程方式中，功能是由不同对象的组合提供的，因此要慎重考虑对象进行交互的边界条件，尽可能的把耦合度降到最低；最后设计的结果可能是：某些对象提供的功能是相对不变的，某些对象提供的功能是易发生变化的；这样一来，未来可能的变化都被尽可能的集中在了最小的范围之内――集中在了那些功能易发生变化的对象之内，将来需求改变时，也许90％以上的改动仅仅在这些10％的易变对象中进行改动就可以达成目标了。完成这样的任务以后，在当前需求下的分析和设计任务就算基本完成；当需求发生改变时，在当前的设计上重复使用这种分析和设计方法，可以保证整个系统随着时间的推移，始终保持着一种最小功能集的状态，而且结构简洁、清晰、稳定，可以给以后的版本升级改造提供最大的灵活性和优异的升级架构，也为系统维护减轻很多的工作量。
我没有研究过ISO标准，我觉得那些都是形式化的东西。当真正掌握了科学的项目工程方法和精神，自然会符合ISO；否则，只是形而上学而已。
客户是上帝没错，可是不能一味的满足客户，因为客户不了解软件系统的开发特点。如果一味的满足客户，除了给软件开发人员增加不必要的麻烦和工作量，也是一种对工作不负责任的态度，因为这样就失去了实事求是的精神，而不实事求是的采取行动，失败自然在前方悠闲的等着。
我觉得我们可能过分强调行而上学的东西了,需求分析的过程应该是轻松的,不应该让用户去学习什么烦人的软件工程;向banq所说的,我们应该做的是一步一步引导用户,挖掘深度的需求
看了这个讨论，很有感触！
我认为大家说的问题就发生在我们的身边，每个项目管理人员、需求人员、系统分析人员、开发人员以至于公司的高层管理者都会有各自的感受，相信每个人都在为改善这些问题思考着。
总结自己负责的几个项目，深感客户需求分析的重要，但事实上客户需求的不明确、不确定是客观存在的。因为客户对自己的业务的理解的不明确、客户对计算机系统认识上的局限性、公司业务人员（市场、受前、需求分析人员）对客户的误导（系统功能的夸大描述）、需求分析人员理解客户需求的描述的不明确、开发人员为了避开繁琐的编码而对需求分析人员或者客户的引诱、客户和公司领导急功近利的心态、与市面上相近功能系统的盲目对比带来的片面理解、客户，公司领导甚至项目经理对需求分析的不重视等等很多原因使得需求分析工作困难重重。
基于这样的环境，要求需求分析人员要有良好的心态，宽容、乐观的性格，积极的工作态度，良好的理解、分析能力，不厌其烦得总做态度，与之相称的薪水：）
====================================
在我失败的这个项目里，当我写出文档给用户一一确认时，用户显得很不耐烦，她认为自己很忙，不愿意参与项目细节的讨论，尽管我一再向她解释不弄清楚这些问题，我们无法开展工作，但也还是难以获得用户的理解。在我们尝试与她们的经理沟通后，他们的经理默默地选择了自己写系统的方案。
====================================
看到这，我觉得有个问题大家也应该注意一下：在一些特殊的环境中，是客户公司/单位的职员故意阻挠需求收集工作的开展，为什么呢？
总归到底是人的问题，在一个皮包制件厂的实施项目的案例中，我遇到一个计件员，就是算一个包的所有物料的每项工序价的。他们以前是手计，没有电脑，现在在一个小型MRPII的系统加上这样的模块，我要收集他们这方面的需求，很细的需求，tnnd这个女人整天以不懂电脑为借口（其实她算懂的），很不配合我的工作，虽然在我的仔细“盘问”下她一点点的挤出来，我也同时在收集其它人的“口供”迫不得已阿，但终究她才最明确，毕竟10多年来只有她一个人在负责这个事。 为什么会这样呢？ 原因很简单，她现在做的事电脑几乎完全可以代替，如果系统实施成功了，那她岂不是要被炒鱿鱼？！ 所以我理解她这种保护性行为，但现实就这么残酷.....
第二个案例，某个县政府的部门，tnnd那部门的公务人员都是中年人，问他们需求时表述得含糊不清，好了，一点点的记录下来，到一定的阶段要签字确认时，他们说忙，要确认，拖得一天是一天，设计时也诸多挑剔，但他们是政府单位，出了高价买你的东西，你担心他走单甚过于对他的愤怒，有时只好忍、变通了，而他们这样拖的目的只有一个：这系统是上头要弄的，他们根本不想用。因为系统实施成功后，对他们百害无一利... 例如要学电脑啦，学打字啦，学这个OA系统操作啦，搞不好要竞争上岗啦，缩短了他们办事的时间导致工作量大增啦，工作被监督啦，等等... 至关键的一点，他们某些关系的财路给断掉了...
左右不是人的日子早就习惯麻木了.... 所以产生了很多“识时务”者，心里难受啊...
对于这样客户，我们无话可说，只是苦了我们IT业，为着这些害群之马，耗费了我们多少重复性的没必要的浪费青春的愚蠢工作，导致了多少流产项目，劣质项目的出现
遇到这些情况，只能要找他们领导解决了，不过上有政策下有对策，真佩服人的变通精神，改是改了，只不过改得变了方式的不合作而已，你总不能让人家的单位炒掉员工吧....
对楼上的说法大有同感，而且身有体会。
同样是在实施两个项目中的时候，很多人担心的是，系统实施成功后，对他们百害无一利... 学这系统操作啦，搞不好要竞争上岗啦，说系统导致额外的工作量大增啦，系统和年终考评挂钩的担心考核不好，没钱拿什么的。就开始消极抵抗，上面的人查，就拿话搪塞，什么项目搞这么久还没完成，什么什么的……，项目都没有弄清楚做什么，怎么可能完成。多次开会都不得要领。我们这些小年轻如何搞得过那些老滑头。说话含糊不清
业务流程说得颠三倒四，琢磨他的话就搞半天。
系统试用就像赶鸭子上架，还要在边上做全陪。一个一个模块手把手，一个按钮一个按钮，每个中文语句都要解释。以后教书用的上了。
楼上两位的讨论非常有意义，这是项目中经常会出现的，人之间关系；软件对象之间关系，都需要程序员搞定，是太难了。
据我的经验，没有不变的需求！我们能做的事就是与用户一起确定最基本的需求，尽量屏弃华而不实（有用户提出的，但很多时候是开发方的市场人员或项目经理提出的）的需求。控制需求的版本，需求精简化才能做到系统的易扩展。