我们应当怎样做需求分析

坐等楼主发布+1

好文章,坐等楼主发布+1

楼主写得很好，总结四点，如下：
1、当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。

2、我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。

3、一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。

4、敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。

需求分析在成熟的软件公司里面是一个要求很高的岗位，但是在中国确实随随便便的一个岗位，怎么可能做得好。
在美国，做“分析”的，可是比实际干活的挣钱多。

看了楼主的文章有很多感触，干了一年开发就转做需求，到现在已经2年了，应该说一直在摸索中前进吧。
借着楼主的宝地，我想提几个我的经验和教训。

第一是要抓住关键角色，大领导不用说了，当然是很重要的，要注意的是从基层升上来的中层领导，他们既能深入理解一线，又能从他们的工作中分析成果性的东西，是理解业务流程的关键。

第二我同意楼主说的，客户提到了一个想法，需求人员一定不要主观的去考虑喜欢不喜欢，而是能理性的分析这个想法的可行性，除了开发的技术可行性，更重要的是用户的业务可行性。比如用户有一次提了一个关于后勤物品管理想法，想法很好，我问他，谁能进行这种设定和管理呢？但是他后勤方面只有一个文员MM，明显无法进行这样的工作。于是这个想法就被他自己放弃了。

第三，需求需要与用户确认，确认的话，原型是个好东西，不管是对用户还是开发。Excel、Axsure等等，千言万语不如一张原型。

第四，敏捷这个东东听起来不错，也曾了解过，但是没用过。因为敏捷不单单是需求的事，需要用户、开发、测试、管理等团队的集体作用。需要需求人员与客户的沟通能力、项目经理的需求控制能力和开发团队的架构设计能力。我们团队基本上自动测试覆盖率不超过15%，敏捷不起来

不错，LZ写的很用心，谢谢分享~~~

一个很大的项目，连需求到上线给半年时间，怎么也做不完
其实，我觉得需求收集的手段固然重要，但是客户的理解，客户方接口人员的水平，对时间的合理计划 很多时候更重要的。

有幸在一家外企i工作过，人家一个很小的改动，都有详细的需求变动文档、设计、测试等等文档，最后光测试就2周（10个工作日）。。。
当然，这涉及到太多因素，不说了。。。

受教了。。感谢LZ分享。。

“计算机信息化管理就是一次改革，对以往手工管理模式的改革。如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢？”

发现平时很多人都是这样去解决问题的，完全不是站在最终问题的角度去解决问题，而是道听途说了某种技术好，然后就采用这种技术“硬套”待解决的问题，“硬套”的结果往往就是造成处理过程异常的繁杂和别扭。

需求分析花再多的功夫也不算多。