客户提出一堆需求，该如何处理?

ppt,html等再结合UML一是一个不错的选择，usecase是根据客户的要求总结出来的模型。在做需求分析的时候UML能够提供很多帮助。而且还可以帮助自己理解，设计系统。

一个最简单的办法就是用MS的VISIO，直接构造出想像中的原形的操作界面，然后在PPT中掩饰。

另外一种方法就是找一个类似的软件，将其屏幕截取下来，在PPT上和用户沟通。（注意把产品商标给remarked掉）

做原型也是一种了解需求的有效的办法，但是这种办法还是有局限。因为我们真正要了解的是系统要实现的功能，而不是界面交互的方式。而且，这种办法只能发现表层的需求，（也就是客户希望界面是什么样子）。不能发现深层的需求。（有些需求，客户自己并不清楚，只是有一个模糊的目标）。
需求还是要搞清楚的。在开始的时候，即使你不把问题问清楚就做出一副胸有成竹的样子，用户也不会跟你较真，但是等到用户用系统的时候，还是会一点点地把他们的要求表达出来。最后吃亏的，可能还是开发者。当然，如果公司能够很容易的拿到钱，那又另当别论。
Use case确实是一种分析需求的较好的办法。不一定要画图，但是可以应用它的思想。我以前见过一个做过很多项目的系统分析员，他并不知道UML这些"先进"的技术，但是他的方法与UseCase不谋而合。
我理解的Use Case分析，简单讲出来，就是从人入手，通过人使用系统的方式，发现业务对象及其关系。这就是我们的目标。
一定要打破砂锅问到底。要是他自己说不清楚，那就没法给他做。要是他坚持不说，那么早点得罪他比等项目做出来再得罪他划算。实际上，多数用户，如果他们真的想用这个系统，那么，问得越细，他越高兴。如果他们不想用这个系统，那么就要靠领导想办法了。他们要求的其实不是系统的功能，而是别的东西。

注意usecase和uml没有什么必然的联系,完全是两种不同范畴的技术手段.从本质上说usecase是和DFD类似的,是建立在功能分解的基础上的,实质上还是面向过程的技术.而面向对象的分析模型,也不仅仅是来自usecase这些客户需求,还来自领域和社会相关环境,同时最重要的还有其他项目的提纯.这一点就是积累和不断复用的结果.

做个简单实现，注意，不是原型哦。

不要怕烦，提取需求才是软件的根本问题．
robbin的方法不错．
往往用户的真实需求是隐藏在界面之后的，需要去分析和提取，不要满足与拿出用户满意的原型，９０％的可能性用户会在验收之前挑刺的

和用户一起分析这些需求的优先级，确定下系统的 scope 。

让用户列出希望有的需求列表，然后和他一起一个一个的稍微分析下，对每个功能，问问他，为什么需要这个功能，现在是怎么做的，如果系统实现了之后，将会变成什么样，会带来什么好处。其实就是和他一起找出好处最大的，能给他带来最大利益的几个，告诉他你自己的估算，先做这几个。

分清楚了优先级，就可以把这个大 list 分成好几个 list： must to have 的需求的 list，wish to have 的需求的 list 。完成 must to have 的，build 出一个 core system 再 improvement ，这样比较好些。

用户描述需求的时候总是想到什么说什么，抓不住重点，需求多的时候一定要搞清楚最关键的业务，也就是用户最迫切的最想要的是什么。

正确的废话

PPT确实是最直观的了，
HTML，　如果可以做到这步，需求差不多明确了很多了，
VISIO，画表，EXCEL，这些本来就是PPT的素材！