在总结需求分析之前，我先谈谈我对事物的认识吧。因为人对事物的认识才能有自己的观点，每个人观点不一样因此对事物理解不一样。也就是在获取需求和分析需求不一样。
学习和实践任何技术和事物都存成开始的入门和进阶最后精通。我个人对精通感冒。因为我知道精通是个高深的境界。
学习事物观点：
任何事物都有它的一般性和特性。掌握一般性也就等于入门，至于掌握特性那可能是遥遥无期。特性和一般性是互相转化。
在理解上面的观点的话：那么就来总结下需求的获取它有什么一般性和它有什么特性。一般性和特性怎么个转化法。怎么让你在获取和分析需求的时候更符合用户的意思和他的行为。
需求获取的手段有很多种，我比较常用的就是说、看、听。说则是去和真正使用系统的用户去交流。（这里是真正使用系统的用户而不是买你系统的客户）。看则是去看真正使用系统的用户对业务的操作或者对替代系统的操作。听则是在你提出问题后，把真正使用系统的用户当成你的上帝去聆听（用户更喜欢自己是老大，而不是你是老大）。
1. 说和听的目的：
将整个要做系统与该用户有关的业务流程跟他进行交流。这可谓是你做需求的一般性。如果在说的时候你所说的流程得到用户的认可后，记住不要高兴。因为你只是成功了一步，那就是你还知道你所做系统的一般流程。也可以说你还了解这个流程。如果在说的时候被用户发现了问题，不要沮丧。其实这才是你有进步的地方。这时候你就认真聆听。不管你说还是听，如果你能够用UseCase画出来很好。如果不行，那么至少你的脑子里面要呈现出一张UseCase（UseCase不要忘了使用者的身份）。在完成了一般性的交流后，接着你必须要去引导用户说出他的一些特性的流程，可能不是很常用但是实际很重要的一些流程。你要想想任何人都可能会遇到处理一般事件和特殊事件。特殊事件是你不能忽视的，每个公司或者每个使用者都有它的特性。这些你都要尽量收集到。
2. 看的目的：
其实是一个验证说的步骤，光说，听是不够完善的。毕竟人会遗忘。尤其是他认为不重要但是对未来的系统可能很重要的东西他没有说。这时候看尤其重要了。看操作者在处理业务的整个过程。通过看来验证你和操作者的说和他说给你听的事情。是否不一致，是否有不同的地方。记住一定要将看到的、听到的、交流的联系起来。互相进行验证。只有这样才能尽量获取到需求。
在获取需求的时候你必须对将去获取需求的公司或者用户有点了解。比如公司的业务，使用者的职位工作范畴等待。了解的越详细对获取越有帮助。如果能够了解该使用者的上下游也是一件好事情。毕竟事物有衔接。