《火球——UML大战需求分析》(第2章耗尽脑汁的需求分析工作)—

本文主要是介绍《火球——UML大战需求分析》(第2章耗尽脑汁的需求分析工作)——2.2 持续进化的客户需求，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

说明：

《火球——UML大战需求分析》是我撰写的一本关于需求分析及UML方面的书，我将会在CSDN上为大家分享前面几章的内容，总字数在几万以上，图片有数十张。欢迎你按文章的序号顺序阅读，谢谢！本书已经在各大网上书城及书店销售，欢迎你的关注。

------------------------------------------------------------------------------------------------------------------------------

第2章耗尽脑汁的需求分析工作

摘要：怎么又变了？当初就应该让客户书面签字确认！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！软件项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件需求分析工作的风风雨雨，找出需求分析工作的根本之道，了解UML如何帮助我们提升需求分析的水平。

2.2 持续进化的客户需求

你可能曾遇到过这样的情况：客户今天想要一个苹果，明天改变主意要一条香蕉，但后天突然又说还是苹果好，到最后他想要一个西瓜！遇到这样的情况，你会抱怨客户吗？你会后悔当初没有让客户签字确认吗？

楚国有人坐船渡河时，不慎把剑掉入江中，他在舟上刻下记号，说：“这是我把剑掉下的地方。”当舟停驶时，他才沿着记号跳入河中找剑，遍寻不获。这就是刻舟求剑的故事。
客户的想法总是在变化的，但总体来说是螺旋前进的，客户需求总是持续进化的，不要对此有任何抱怨，否则我们就是“刻舟求剑”之人了！

某系统已经上线了，以下三种情况，你会更喜欢哪种情况呢？
A. 客户一直没有提出过任何问题。
B. 客户开始提了一些问题，但很快就没有其他问题了。
C. 客户一直在提问题，项目组解决这些问题后，新的问题又来了，如此不断重复。

情况A，估计客户没有怎样用过这套系统，所以没有提出什么问题。对于项目组来说，似乎不用再被麻烦的需求变更所纠缠，可以爽快地脱离此项目了。但对于客户来说，此系统白白花了他们的钱，对他们没有任何实际价值。而对于你所在的软件公司来说，你们项目组花费很大工作来做出来的软件系统，客户居然没有能用上，而你们公司很可能收不到项目的验收款项，此项目完全实现不了公司的战略。情况A的最终结果就是“双输”。

情况B，有两种可能：第一种可能，客户试用了一段时间系统，后来由于客户方面的某些原因（原因可能有：更换领导、上了另外一个更重要的系统等）不再使用本系统了；第二种可能，客户试用一段时间，提出了很多问题，而你们项目组不能很好地解决这些问题，甚至认为客户“无理取闹”，所以客户干脆就不再使用本系统了。出现情况B，本项目估计也很难能通过最终验收，软件公司最终也收不到项目验收款项，而最终结果很可能也是“双输”。

情况C，我曾经比较厌烦这样的情况，每天被客户的各式各样的小问题纠缠。其实这是相当理想的情况，说明客户在不断使用该软件。这些问题最开始会比较多，最开始项目组解决问题的速度会低于问题的产生速度，但后来问题会逐步减少，直到基本消失，软件和用户的“磨合”过程终于完成，系统成为客户日常工作中的一部分。出现情况C，我们项目组千万不要产生厌烦情绪，客户要真正用上软件，项目才算真正成功。软件只有对客户的工作真正有帮助，客户才算“赢”，而在客户能“赢”的基础上，我们软件公司才可能实现自己的“赢”。达致“双赢”是我们每个项目应追求的目标。

从某种角度来说，需求变更其实是好事，说明客户对需求的理解更进一步，而我们觉得不适应，往往是因为我们对需求理解的进步程度不如客户。请看下图：
图2.1 客户VS项目组对需求的理解1.jpg

图 2.1 客户VS项目组对需求的理解1

此图表示项目开始后随着时间的发展，客户和项目组对需求理解程度的上升趋势。
在时间=0时，客户的曲线并不是从零开始的，而是有一定起点的。这表明，客户在项目刚开始的时候，对需求是有一定认识的。而项目组在项目最开始时，对需求的理解几乎是零。
随着时间的发展，客户对需求的理解越来越强，尽管项目组对需求的理解同样也变强，但项目组对需求的认识总是落后于客户，这样需求分析工作肯定陷于被动，总会被客户“牵着鼻子走”，很容易出现互相责怪的局面：客户责怪项目组水平太差，而项目组责怪客户需求变来变去！
要打破这样的局面，项目组需要做到下图的效果：
图2.2 客户VS项目组对需求的理解2.jpg