也谈需求分析

　　不用怀疑，这是一个老生重谈的话题。不过此次和以往的话题可能有所不同，此次关注以下几个问题（不要说挂羊头卖狗肉啊）：
　　1、项目组的人员规模。
　　2、项目组开发的是什么类型的系统。联机事务处理（即业务支持）、MIS、嵌入式etc。
　　3、是否进行正式的需求采集，分析，形成正式的文档。
　　4、需求分析一般是谁来做，PM、老板，专职的分析人员还是其他人员？
　　5、如果有需求变更，是怎么处理的？

　　近期逛坛子，看到不少帖子说国内N多项目不写需求分析文档，甚至M多项目不做充分的需求分析，最终导致失败。各位在实务中是怎么做的，希望畅所欲言，此处先抛砖引玉，说说我的情况：

　　1、规模：12。
　　2、联机事务处理。
　　3、有，且形成正式的文档。不过采用的是项目组专用的，并不在整个公司层面使用。
　　4、专门的SA。
　　5、业务、用户方需求变更，需要走需求变更通道。特殊的需求，也会通融处理，在知会SA和PM的前提下，不经过变更通道直接接受变更。

　　一般来说，我们的需求实现的及时率，用户还是比较满意的，基本上每一个迭代周期内的需求都会按原定的版本计划发布，少有拖延。

我也说说我的看法：

1、做需求不是一次性的。很多项目把做需求当成一次性的任务，认为前期花大量的时间做需求就能够避免后期的需求变更。这是不可能的。

2、需求分析的工作量可大可小。遇到不勤快的需求人员，这项目就危险了。

3、做需求的时候过于看重功能而忽视项目的背景。当问“为什么要这个功能”时，需求人员只会说：“用户就这么要求的呀！”如果用户试过之后觉得不好用，需求人员会找尽借口把责任推到用户身上，比如“用户就是这样子的”之类的奇谈怪论。

4、需求文档改起来容易，而代码改起来却很难。很多项目也是被糟糕的设计拖累，不是 BUG 丛生就是无法满足用户需求。

5、修正错误的需求不是需求变更。在项目正式上线之前，真正的需求变更很少，那些所谓的“需求变更”实际上是对之前错误的需求进行修正。

1、RUP倡导的迭代开发，看来是有很深的现实基础和理论基础的。分而治之，是解决复杂问题的有效方法。对于复杂的需求也不例外。当业务复杂时，不妨先实现其核心的、最常用的、对甲方能产生最大价值的需求，其它需求放在后续的迭代周期实现。

2、这一关，不知道是人品、仅能问题，还是工作态度问题。如果人品有问题，明明知道是什么，但就不告诉你，只能fire；技能问题，当然只有提升了；态度问题，敷衍了事，明明可以做得更好，却不做，看来只有换人啊。

3、只能说需求分析人员技能有待提高，没有深入发掘用户的深层次需求，仅仅流于表象。善于抓住用户提需求的动机，是需求分析中的重要技能。而其，需求分析中，不是用户说怎么做就怎么做。用户那么说，是为了达到某个目的。实际上从一个点出发，到达目标的路径很多，用户给的可能并不是最优的。了解用户的动机，就可以帮助其寻找一个更好的解决方案。

4、冰冻三尺，非一日之寒；千里之堤毁于蚁穴啊，项目的失败不光光是设需求分析做得不到位导致的，它只是导火索。蹩脚的设计，不规范的文档，都难辞其咎。

5、和第3点同源。

PS：如果说需求是秘密的话，它也是可以表现、能被人理解的，这样说来，它也就不是什么秘密。而且对于一个成功的系统、项目，需求的内容最终是要被设计、开发人员接受的。我不觉得需求分析是神乎其神的东西，不觉得它是只可意会不可言传的，而是可以被系统化、被学习和传承的。

PS：不知道这位老兄是否战斗在需求分析的第一线，有如此深的感触？

我认为，项目的成功与否，很大程度上不是需求分析出问题。而是各个方面都做的不合格。

光谈需求是无用的。

政府项目背景有些很复杂，很多时候成功与否取决于项目的本质目的，有XXXX，项目已经成功了一半。

文档方面，文档正规不正规无所谓，文档的作用无非是明确的记录、描述事情，能看懂即可，能非常快速的看懂并且没有理解偏差最好，达到这点，需要项目组齐心。
抱怨文档没有的，一般沟通做的很烂。

复杂的项目的确是不仅仅是靠需求，而是靠牛X的设计，核心人员不可怠慢与忽视。

切不可抱着你离开了地球照样转的想法，这是官僚的表现，搞不定说明你无能，开除别人是将自己的（也可能是公司的或者其他人的）过错利用公司权力强加给别人，这样做很。。。
通常权力是放在那看的，不是用的。有些经理们过分的使用了强制力。
后果不说了，谁用谁知道。

一点愚见
欢迎斧正

　　
　　把事情做好的，需要周密考虑每一个环节，并不打折扣地在细节层面加以实施；要把事情做坏，随便捅捅漏子就能达到目的。成功的项目也一样，需要的不仅仅是好的需求分析，也需要好的设计，编码能力，测试的保证……不过，我仍然要强调，需求分析的重要性。你可以不一次性捕获分析完用户的需求，但是在你每次作分析、设计时，你都应该明白用户到底是想做什么。这就是所谓的不在浮沙上筑高台。

首先没必要扩大话题，就谈需求。

“能看懂即可”，这个要求实在太高了。

SB 的需求只会带来 SB 的设计。设计得再好，对不上需求不还是一坨粪。

看看thinking in UML

也发一个。
j2ee系统，行业性很强。实施团队+开发团队的构成。（ps:两个实施项目，同一开发团队支持）
人数：10人。
需求都是由项目上的实施人员收集和文档化（有模板），然后提供给开发团队。开发团队会有一到两个业务和技术都比较强的人对项目上提的这些需求进行分析，并和实施团队进行多次交流，最后确定方案，该的方案由开发团队编写，根据需要还会制作demo。实施人员会根据定下的方案修改他们自己的项目需求，附上工作量，让客户签字确认。

需求太神话了，其实就是个接口，直接雇佣一个用户的人更好，文档什么的要自己人来写，主要是有个记录。