一个实际的需求分析例子（希望和大家交流）

[clamp_chen]

这是我们公司目前正在进行的一个项目，我主要负责需求分析这一块。
这个项目比较大，问题呢大大小小也有不少，有些已经解决了，有些正在解决，还有些正在想办法解决。
之所以发在这里主要是想和各位交流一下，因为不是什么特定的问题，所以没有分数，请多包涵。

本人简介：学习时兼职过两个小项目，做程序开发，毕业后做过一年的程序开发，后来作一个小项目的项目经理，主要负责客户需求分析和其他一些杂事，基本上从头参与到底了。现在在这个项目里负责需求分析这一块。
由于本人并不是计算机专业出身的，并没有系统的学习过软件工程，因此一直是一边做一边学的，又没有人带，很希望有人交流一下。

项目简介：（基于保密原因，不能介绍的太详细）
项目蛮大的，是一个总体的系统解决方案，硬件软件都有的，软件开发费大概是几百万。
客户是一个很大的国有企业，这个项目所涉及的部门也很多。

[f190]

我做项目也有一些时间了，有些体会供你参考
1，搞好跟用户之间的人际关系（最最重要）
2，使用一种能够熟练使用的开发工具和开发模式，不要片面追求高精尖
3，要真正体会用户驱动模式的含义，这样做出来的东西才会有人用
4，找一个系统分析的老手帮你们分析商业逻辑，此人必须精通客户所在的行业业务，否则很容易做出四不象来
5，参考同行业类似系统
6，程序的模块化很重要，要能够每隔一段时间拿出一个能独立运行的的程序用
努力吧

[hcgui]

gz

[dreamfisher1]

不知道为什么现在已经进入了测试阶段呢?
如果是这样,那这个项目的周期估计将会很长.
因为用户会不断提需求,你们不断改进,而且,在改进过程中,很可能会发现以前的一些不足,或者会照顾不到以前的一些情况,将来进行数据分析(决策)设计的时候,将会很难受的.
我的想法是将这个项目分成几个阶段,首先做最核心的部分,并留下充分的接口以进行后阶段的设计和开发.(这需要敏锐的分析和预见能力)
在后阶段的设计和开发中,肯定会发现前一阶段的不足和考虑不充分的地方,建议对其进行评估,以决定是重新来过还是修补.强烈建议重新来过比较好.
另外,对于交付后用户的意见,如果是BUG,当然立即改,如果是变化了的需求和新"思路",则建议集中了一起改,不然,版本很不好控制的.
说了说自己的想法和经验.

[clamp_chen]

本来准备再开一栏的，但是出了点问题，那就继续在这里回吧，希望帖子不会太长，呵呵。

谢谢楼上各位的意见，我就不一一回复了。
目前总结如下：
1.和客户应该搞好关系。我在这一点上确实做的不够，还是书生气比较重，嘿嘿。不过另外还有人专责公关的，具体情况我也不是很清楚了。但是由于我们所接触的用户比较多，直接和我们有关的用户目前还比较配合，但是其他的用户配合程度相对就低一些，如果影响到他自身利益的话还会有抵触情况。
2.需要有精通客户业务的系统分析员。这一件事情是我们最头痛的地方，不要说系统分析员，就是精通客户业务这样一件事情，在客户那边也是由若干个人拼起来的。也就是说，每一块都有人精通，但是精通全局的没有。我现在是每一块都捎个边，能说上几句，但是说到深度就远远不够了，导致底气不足。行业内其他的公司有类似的人员，但是不是轻易挖的过来的（已经有一个有经验的博士过来了，但也只是其中一块业务比较精通）。目前也只是内部挖潜了。
3.外部接口定义。和其他各个系统协商接口也是很让人头痛的，大多数系统都很难谈，毕竟这些接口对他们没什么好处。接口的定义，数据的准确性都是需要一次次开会才能确定下来，平均谈一个接口要花2个月协商（这还是在了解业务的情况下），再花2个月开发和测试，再花若干个月核对数据。一旦接口定义变更，这些事情还得重来一遍，痛苦啊。
4.内部组织。由于整个团队比较缺乏经验，而且也正在实施规范化软件工程的过程中，因此比较混乱。而且一开始战线拉的太长，导致人手不够。不过目前情况已经有所好转，团队架构在逐步稳定。
5.阶段划分。其实目前才是第一阶段的尾声，第二阶段马上就要开始了。如果客户还让我们继续做的话（估计是会继续做下去的），最起码还有一年多忙乎呢，甚至可能更长。

下一阶段的需求分析计划（我会参与开发架构的讨论，但是计划不是由我定的，因此这里就不讨论了）：
1.明确目标。只对着一个业务方面下手，这一块的客户支持比较强一点。
2.加强业务培训。目前的打算是到客户那边去蹲上几天。
3.和用户培养良好关系。这个我就比较外行了......
4.分清楚各类文档的范围。我计划有以下几份文档。
1）原始调研报告。将客户的意见完整记录下来，以录音作为辅助，作为后来者的重要参考；
2）业务需求。框定范围，确定需求边界，确定涉及到其他部门和系统的接口内容，确定主要业务用例。
3）用户需求。业务用例细化。在这一步将要求用户签字确认，确定功能点。同时进行业务建模。
4）接口需求。根据业务需求和用户需求产生的接口需求，主要是和其他系统的接口内容。这一步会和接口系统签字确认。
5）功能需求。功能点细化，将给出界面原型，并邀请用户和技术人员一起评审，并演示业务用例的实施。这一步争取用户签字确认，不过从实际情况来看比较困难。

请各位对以上计划多提宝贵意见，谢谢！

[romberg2002]

看了这么多，唯一的感觉就是没有责任心。我是这个组的，我负责这方面，所以我不管其他人怎么干，我不管他们做得怎么样，多么的合情合理呀。同志，如果你能从别的侧面想一想，如果你能站在更高的高度看这个项目，你会做得更好。我跟一些做了多年的程序员的人聊天时，给我的感觉就是他们都在混，已经没有了年轻人应有的创造力和冲动，更没有了工作的激情，有的只是埋头干活，不问结果，自扫门前雪。而他们则笑我幼稚，笑我没经验，阅历少。我承认我的阅历跟他们相比是少了点，但在激情在创造力上我一点都不少，毕竟我有自己的产权，有自己的技术。。。呵呵。fulltop-zhejiang?

关于楼主的问题，我帮不了你的大忙，但我知道，在整个过程中，你最需要做的就是跟客户保持好关系，而且不仅仅是你，包括所有参与这个项目的跟客户接触的人员都要如此，在内心里都要清楚客户的地位。你们是在向客户学习（需求分析阶段），他们虽然不规范，但他们有他们的难处，你们的责任是让他们满意，其他的事是你们没法改变的（当然能改变最好，如果你们能让客户放弃某些利益的话）。需求分析是否要在最开始就做细，各公司有不同的做法，只要能保证整个框架稳定就好。还想说一点就是，不要认为有专门做公关的，公关就跟你们没关系了，事实上你们尤其是你（需求分析员）最应该做好公关。再有就是需求分析员太少。一点愚见。

[w102272]

如果可能的话，你首先应该向用户强调，成立一个该项目的联合领导小组。包含双方的主要人员。对方必须有一个有实权，能作决策的领导作为重要的组织人，以便协调各方的利益和业务需求的变更。在大多数项目失败中，需求不明和缺乏计划都是导致失败的最重要原因。没有实权领导的推动，几乎肯定是要失败的。

所谓“精通客户业务的系统分析员”，不要过高想像系统分析员的领域知识。或许这些的人从来不存在。其实客户本身就是最好的“精通客户业务的需求分析员”，在需求清晰的情况下，建立合理的IT架构并不象你想像的那么困难。
因此，你必须让客户深度参与你的项目。必须让客户认识到他们有责任对自己的项目成功负责，毕竟大家谁都不希望自己的项目失败。
可以考虑类似，由客户方最精通业务的人（最好包含一位又懂业务又有权力的领导），建立主要需求部分的“客户代表”，参与你们的需求调研和决策过程。一个部门经理级别的人物根本不足以担当合格的客户代表。

总之，目前你面临的这个问题，主要问题在客户方。但是并非一点可采取的措施都没有。

[ytaozi]

同感w102272(Wonder)

[f190]

“精通客户业务的系统分析员”？这当然是一个项目成功必不可少的条件。
中国这么多软件项目烂尾，就是因为一些程序员写了一两年程序就以为自己已经是当然不让的系统分析员了。我亲眼见到一个一个的软件公司没有任何行业积累就要贸然帮企业设计ERP。。。连会计基本原理都没搞清楚也跟企业的总会计师有板有眼地调研。。。唉。。。

[mvp2000]

我的建议是， 做好心理准备，后期的维护期会有大量的修改工作，有一些模块可能还要推翻。

但这应该可以和客户解释清楚，不会让客户后面太反感！

[hnzsy]

老兄，如果没有用户的有力支持，任何一个项目都不可能成功，不知你现在作的项目是否是ERP,如果真是的话，你要想成功，就必须保证以下条件：
1、用户方项目总指挥必须是企业的第一或第二把手，只有高层领导的亲自参与才能
保证各部门的配合流畅，也只有企业的高层领导才能利用手中的权利清除掉一些
不和谐的声音（切记）
2、你作为需求人员必须熟悉业务
3、不要妄想等所有需求都清楚了才开始设计，由于企业人员的素质相对较差（特
别是以前从来没有信息化的单位），因此，你最好把你的一些想法在界面上表示
出来（不要很规范、详细,就当是界面原型吧）
4、需求调查完后，你应该建议用户方的总指挥召开一次各部门业务专家（不是领
导）的评审会，你的需求是否正确，只有他们才知道。然后双方签字，形成规范
文档，目的是对需求进行约束。当然，这样的会议通常要开多次才能最后形成基
线


以上条件只有有一项不满足，我建议你马上走人

[pangyunqing]

呵呵，还是小心吧，我这里一个朋友做软件公司部门经理，跟进一个项目快8个月了，哪个集团有42个分公司，要做个OA系统

[boydontcry]

呵呵，要用户签字？
1种可能：他怕担责任，不愿意签字
2种可能：他签字了，可是他要改动，你能拿他怎样，他是客户，他还是国企的，呵呵，你和他说道理？

做这种国企的胡子工程，最关键的我觉得还是和客户把关系弄好，
至于系统，马马虎虎就行，记住，理想主义者绝对不要来做这种所谓
的企业业务应用系统，否则会碰的头破血流。大部分的软件企业都差不多，
不要怕自己的东西臭。

[boydontcry]

SE提供的行业数据显示，需求分析占据整个系统生命周期一般为30％左右，而且需要有一个强有力的团队来完成。CMM里面第一个KPA就是需求管理，也就是说对需求而言你必须实现从需求分析，需求定义，需求开发，需求跟踪验证最后到关闭的很大的一个过程。
成熟的软件企业应该在需求管理团队建设上投入很大，应该有非常熟悉业务流程的需求分析人员，要有能够将这些业务流程转化开发为SRS和Use Case的需求开发人员，需求组的Team Leader应该负责整个需求的协调和跟踪工作，这样我想能够基本保证这个环节不至于失败。
看看你们开发团队的组织架构（所谓的需求组就楼主一个人），看看楼主提供的个人简历（经验还非常欠缺，自己的锻炼是另外一回事，此处并不是攻击楼主），看看你们的系统分析设计的薄弱程度，就知道你们公司现在的软件开发管理还出在非常混乱的阶段。
SE和CMM都重点提及的是软件开发团队应该定义角色，划分明确的职责和工作接口，但是现在看来你们的Project Manager好像没有什么行动，倒是楼主倒是责任心很强，作为工作精神是可嘉的，但是我觉得作这种工程的心态一定要保持好，做好自己分内的工作，配合好他人的工作，负自己该付的责任就问心无愧了。
祝楼主好运。

[mars884813]

我个人觉得贴主有些书生气。

其实我觉得目前的问题用攻关手段解决要比用技术管理的手段来解决来得容易，成功的机会也会高一些。

如楼上一位同志所说，不要有太多的理想主义。社会有明朗的一面，可有时确实也会散发一些血腥味。

[mars884813]

写错一个词，“攻关”应该是“公关”。

[stone_wu]

over?

[stone_wu]

over ?

[freebird2002]

变化是绝对的，要有勇气和信心去面对。多看几遍《谁动了我的奶酪》吧，从哲人的思想中寻求力量，在充满变化的世界学会生存，并且要生存的更好。

衷心的祝你成功，沉住气，扎扎实实的一步一步努力，有这么多的人帮你，你还能不成功吗？

[flashman]

关注

[index]

mark