项目需求分析 .pdf

项目需求分析重要性 看了听棠的“客户需求何时休”，深有感触，何曾自己不是被这 个问题整天困扰：客户需求，为什么总在变阿？做项目真辛苦阿！这 样的感叹整天都挂在口上。客户需求变动确实是一个软件开发永远不 变的话题。为什么小的软件企业面对经常变动的需求是如此的狼狈？ 到底要怎么做才能满足客户的需求？ 听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。 需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析， 了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供 给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之 内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、 规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自 然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成 的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的 了。 听棠所说到的几点，感受特别深： “其实问题出在开头，客户需求只是软件需求分析的一部分，虽 然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客 户的需求进行分析” “客户本身是不怎么懂技术的，客户只知道自己的业务需求，而 在软件设计时，是在把业务需求抽象到系统中实现的，把业务转变为 逻辑时，一切都应该符合逻辑的，但客户的业务思想有时候在软件系 统实现时会有问题的，这就需要分析时分析出来的。少了分析，问题 也会在后面的开发中暴露出来，到时可就更麻烦了。” “还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲）， 客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾， 而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从” 客户要求去做，当暴露这些问题时，你怪客户也没用啊。” “因此，很简单，在了解客户需求时，不要不动脑子，不要一味 的点头说“I C”，其实在表面的业务里面可能包含着N多的细节， 这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的 需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问 中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理 的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些 在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客 户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理 解的。” “客户的需求本身是无休止，因为他们本身也在变，但当你期初 的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么 大了。这其实也体现了系统的扩展性。” 需求分析，是一个项目提出方和承担方相互沟通的过程，一方是 系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方 相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业 务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求 方面的描述是不了解的，他们所能提供的只是他们最终要达到的功 能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求 后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让 客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交 流，最终才能取得较全面的需求，并减少后期的修改。 谨记一点，需求是经常变动的，只有先做好需求的分析，了解业 务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的 扩展空间，从而在需求发生变化的时候可以更从容的修改。 需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目， 但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： i. 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没 有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细 节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有 效性。 ii. 需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项 目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生