需求获取和需求分析

  在总结需求分析之前，我先谈谈我对事物的认识吧。因为人对事物的认识才能有自己的观点，每个人观点不一样因此对事物理解不一样。也就是在获取需求和分析需求不一样。
  学习和实践任何技术和事物都存成开始的入门和进阶最后精通。我个人对精通感冒。因为我知道精通是个高深的境界。
 
  学习事物观点：
  任何事物都有它的一般性和特性。掌握一般性也就等于入门，至于掌握特性那可能是遥遥无期。特性和一般性是互相转化。

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

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

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

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

一直对需求分析比较头疼，新手来学习学习了。

嗯。。
需求分析写的不错啊。。
学习了。。

需求分析一直做不好，受教了！

这 好像在哪个地方看到过。。。

以我这两年的经验。我认为：
多听
总结---当天总结
反复讨论---第二天或者尽快讨论
深刻理解需求问题本质--这个最重要，你只有理解了客户想做什么，才能做好调研和分析
接下来就是文档书写的技能了。

只此一家，没有分店啊！全是个人的总结和心得！

朋友你好！你的经验观点我赞成，但是我可能有我的不观点。
学习任何知识，总结是必须的。
讨论也是必须的。理解客户想要的也是必须的。
文档写好那更是必须的。
但是你总结的好像是你的表像。 多听？ 你想过为什么要多听吗？你可能说因为是为客户做，当然要多听听他们的think。
但是多听的点要把握。不能迷失了你自己！
总结是必须的，那你是否能够告诉我总结的重点在哪里
反复讨论？那些点要反复讨论。是不是所有的都反复讨论。
调研和分析仅仅就是理解客户想要什么？

  在做需求的时候其实不同的Project是不一样的。不同的行业也是不一样的。最重要的是如果做多了Project的需求，哪天要做product需求的时候用Project的思维那有很大一部分偏差。
Project 和 Product在需求有很大一部分不一样。切莫定向思维分析。

朋友，你有需求分析经验有不同的观点，请你定要分享下！请稍微将你的观点列详细点！谢谢
恭候指教！

那么对付经常变动，且有时客户自己说不清或不明白的情况.