我们应当怎样做需求分析

很是认同这位哥们的说法，需求分许的开始就是系统角色的划分和边缘系统的交互调研。确定角色，再确定每一个角色的业务负责人或者说是需求签字人。事情就会好办很多

在需求分析中这些调研可以先从一个大会议的头脑风暴开始，充分暴露需求，在了解客户业务的基础上做每个部门，分角色的调研。逐步完善demo

永远不要忽视对公司组织结构的分析和区分权重，这对建立良好的客户关系和建立客户对个人的信任都非常重要

调研的目的就是完成一个客户满意的需求文档并最好做到签字。。不过签字。。。。不过签字。。。

需求确实非常重要，有时也应该引导客户，提出自己的意见~~~

做需求最好是帮客户把功能能简化就简化，能不要的就不要，不要盲目的帮客户去想，想的越多做的时候越难。

虽然还没有和客户真正的进行过需求调研，但这一两年的时间跟着一个有快10年左右金融行业需求分析师,感触颇深。

1、LZ举的几个例子基本都围绕需求这一块，实际上需求的撑控不是随便找个技术人员就可以搞定，特别是要求业务知识比较专业的行业，例如金融、保险、证券之类。合格的需求分析师决定着整个项目的成败。

2、需求调研亦不能仅仅需求分析师去参与，适当的有技术人员参与，若分析人员不懂技术一为的满足客户要求，最后只会把整个技术团队搞死，所以做需求调研的时候一定要有高级程序员一起进行调研，若有架构师参与更好，调研时候了解了客户需求后，由技术人员讨论后直接告诉客户实现的可能性，若特别困难可以当面解释清楚，一般这种情况下客户也可以接受。

3、一个合格的分析师能够把控客户的需求是必备条件之一。项目已经在开发，开发的过程中难免客户会对需求进行调整，添加需求。如果前期分析师对客户的需求把握的很好，能够透彻的理解，这时的变更亦不会影响全局，能够影响的就是新加的需求。
我们算个账：
若项目周期60个人月，10个人的team，项目130万，平均每月人员各种成本13W，原计划6个月完成此时盈利52W，毛利40%，已经非常不错了，IBM软件毛利也才40%左右。再细算一下，平均每天整个team成本13W/30=4333RMB,需求把握不好，多一天的时间你的盈利就少4333RMB，多一个月就是13W，如果达到10%以下毛利的，做这个项目还有什么意义。如果你项目比较特殊，例如政府项目之类，这种算法可能就不太合适。

如果客户还不停的加需求，项目金额能增加的话最好，不能增加就讲讲现有的利弊，如果项目没有盈利公司就会撤出整个项目组，导致项目无法完成，这肯定也不是客户想要的结果，以此来权衡客户。

4、若项目比较大，团队小，最好在项目成立时候尽最大努力组织这个团队满足现有的项目需要，并在开发过程中尽量避免人员流失，否则后果难以想象。若实在团队不能满足可以和客户进行讨论，分期分阶段进行，把需求划分一期二期等.....,把大目标划分为小目标，继而实现整个目标。

还有很多很多，合格的分析师需要多年的专注，不停的浸淫。

详读了以上兄弟的分析，都比较中肯。分析的比较到位，目前我遇到的项目就在需求上垂死挣扎，眼看着窗外的大楼从平地拔地而起，而我们的项目却遥遥无期，BUG不断，修改不断,好不痛苦...

不能完全苟同这个看法。客户也是人，是一群精明的人。你在功能上忽悠他，他就会在资金上忽悠你。面对客户应当学会引导，但这种引导应当是正向的、双赢的——他获得了他满意的软件，你稳健地、技术可行地完成了他要求的软件。这当然需要深入的业务与技术分析了。

看了楼主写的非常受益，我觉得demo的引入会改变很多事情，用简单的html来勾画出整个过程，这样是双赢。

项目需求还是很重要的，把项目的需求分析的清楚是很必要的。如果在没分析清楚的情况下做出的软件和产品很难得到客户的肯定，不能得到客户的肯定就意味着不能给客户带来利润和价值，那么这个项目是失败的。

受用了，原来加班是这样来的，呵呵。

楼主方法是好的，不知有没有实际用到一个项目的需求调研上了，还有楼主所说方法必然会经常要求客户进行讨论，有的开过几次会后就不会怎么配合了，这个时候又怎么办？