需求获取和需求分析

在总结需求分析之前，我先谈谈我对事物的认识吧。因为人对事物的认识才能有自己的观点，每个人观点不一样因此对事物理解不一样。也就是在获取需求和分析需求不一样。
学习和实践任何技术和事物都存成开始的入门和进阶最后精通。我个人对精通感冒。因为我知道精通是个高深的境界。

[b]学习事物观点：[/b]
[b][color=red]任何事物都有它的一般性和特性。掌握一般性也就等于入门，至于掌握特性那可能是遥遥无期。特性和一般性是互相转化。[/color][/b]
[img]http://dl.iteye.com/upload/picture/pic/58896/69fdd59b-1de7-35dc-805a-c6ca96cee140.jpg[/img]

在理解上面的观点的话：那么就来总结下需求的获取它有什么一般性和它有什么特性。一般性和特性怎么个转化法。怎么让你在获取和分析需求的时候更符合用户的意思和他的行为。

需求获取的手段有很多种，我比较常用的就是说、看、听。[color=red][b]说[/b][/color]则是去和真正使用系统的用户去交流。（这里是真正使用系统的用户而不是买你系统的客户）。[b][color=red]看[/color][/b]则是去看真正使用系统的用户对业务的操作或者对替代系统的操作。[b][color=red]听[/color][/b]则是在你提出问题后，把真正使用系统的用户当成你的上帝去聆听（用户更喜欢自己是老大，而不是你是老大）。
1.[b] 说和听的目的[/b]： 将整个要做系统与该用户有关的业务流程跟他进行交流。这可谓是你做需求的一般性。如果在说的时候你所说的流程得到用户的认可后，记住不要高兴。因为你只是成功了一步，那就是你还知道你所做系统的一般流程。也可以说你还了解这个流程。如果在说的时候被用户发现了问题，不要沮丧。其实这才是你有进步的地方。这时候你就认真聆听。不管你说还是听，如果你能够用UseCase画出来很好。如果不行，那么至少你的脑子里面要呈现出一张UseCase（UseCase不要忘了使用者的身份）。在完成了一般性的交流后，接着你必须要去引导用户说出他的一些特性的流程，可能不是很常用但是实际很重要的一些流程。你要想想任何人都可能会遇到处理一般事件和特殊事件。特殊事件是你不能忽视的，每个公司或者每个使用者都有它的特性。这些你都要尽量收集到。

2.[b] 看的目的[/b]： 其实是一个验证说的步骤，光说，听是不够完善的。毕竟人会遗忘。尤其是他认为不重要但是对未来的系统可能很重要的东西他没有说。这时候看尤其重要了。看操作者在处理业务的整个过程。通过看来验证你和操作者的说和他说给你听的事情。是否不一致，是否有不同的地方。记住一定要将看到的、听到的、交流的联系起来。互相进行验证。只有这样才能尽量获取到需求。

在获取需求的时候你必须对将去获取需求的公司或者用户有点了解。比如公司的业务，使用者的职位工作范畴等待。了解的越详细对获取越有帮助。如果能够了解该使用者的上下游也是一件好事情。毕竟事物有衔接。