《火球——UML大战需求分析》(第2章 耗尽脑汁的需求分析工作)——2.3 给客户带来价值，需求分析之正路

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

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

2.3 给客户带来价值，需求分析之正路 

手机短信订餐系统

接下来我将会介绍一个手机短信订餐系统的故事，这是一个由真实个案改编的故事，通过这个故事来体会需求分析工作背后的道理。
某IT公司规模不大，员工100来人。公司有一个简单的定餐系统，员工每天可以在公司内部网站上提交当天午餐定餐，前台汇总各人定餐后，将定餐汇总传真给餐厅，餐厅根据传真送餐。

可是有这样的问题：部分员工因为上午请假或者外出工作，无法再网站上提交订餐，以至于中午回到公司时没有饭吃。

于是老板想出了这样的办法：做一个手机短信定餐系统，不在公司的员工可通过手机短信定餐。
于是成立了手机短信定餐项目小组，购买了手机短信收发的硬件，解决了选餐单、定餐、取消定餐等技术问题。但这个系统一会灵一会不灵，问题是出在软件、硬件，还是中国移动都难以搞清楚！做项目做麻烦的事情之一就是遇到“幽灵问题”，时而出现时而正常，项目小组挥汗如雨地试图解决这些问题，可一直没有办法搞定。
老板大发雷霆了，怎么这样小的事情，竟搞成这个样子？
后来有人提出来：不在公司的员工，打电话回公司告诉前台吃什么，不就搞定了？
于是全世界恍然大悟，天啊！

需求分析核心的问题就是客户到底想要什么的问题！
客户往往只会有朦胧的大概的想法，他们提出来的需求，只是表面的，不全面的，甚至是互相矛盾的，我们需要透视它的本质。
我们做需求分析工作，往往会将需求分析和软件设计混在一起。需求分析核心目的就是解决软件有没有用的问题，而软件设计是解决软件用多大的成本做出来的问题。

需求分析首要任务是保证软件的价值，我们必须保证做出来的软件是符合客户的利益的。如果我们不能看清楚客户的真正需要而仓促上马，则很可能付出巨大成本仍然不能满足客户的利益。

手机短信定餐系统要解决的问题其实就是：让不在公司上班的员工也能方便地定餐，手机短信定餐系统本身并不是需求，只是一种解决方案而已。当然因为这个要求是老板提出来的，所以项目组可能就没有进一步思考这个系统的必要性了。我们的客户提出具体要求的时候，我们往往不能思考这些要求背后的需要是什么，而直接将这些客户要求当成客户需求来处理。
给客户带来切实的价值才是我们真正的任务，而不是盲目听从客户的要求而不加分析。

需求分析的大道理

软件需求分析工作到底是一个怎样的工作呢？我们如何才能把握住真正的客户需要，做出给客户带来实在价值的软件系统呢？
我们说说需求分析的一些大道理：
首先我们需要明确项目的背景，我们要回答这些问题：也就是为什么会有这个项目？客户为什么想做这样的一个项目？如果没有这个项目会怎样？
了解背景的基础上，我们需要进一步了解以下内容：
1) 本项目解决了客户的什么问题？
2) 本项目涉及到什么人、什么单位？
3) 本项目的目标是什么？
4) 本项目的范围是怎样的？
5) 本项目的成功标准是什么？
以上这些内容，我们称之为客户的“需要”。

接下来，就可以定详细的需求规格说明书了，一般我们会对功能性需求和非功能性需求都列出详细的要求，我们把这些要求定义为“需求规格”。
 
图 2.3  背景 需要 需求规格

做需求分析工作时，我们往往只看到“需求规格”这个层面，这是很表面的需求。我们应该透视这些表面的需求，去挖掘客户的“需要”。如果我们不清楚客户的“需要”，就很容易被“需求规格”所“迷惑”，难以做出对客户有实际价值的软件系统。

我们再回顾一下“需求分析面面观”小节中提到的各种角色的特点，越是基层的客户，他越容易提出“需求规格”级别的需求，越是高层的客户越容易提出“需要”级别的需求，当然有时候连客户中高层也不能很清楚的描述自己的“需要”是什么。
项目组不应该只将自己定位在软件的制造者，而应该是软件价值的创造者。我们不是为客户提供一套软件系统，而是提供一套能提升客户价值的服务。所以项目组不应该被动地接受需求，而应该主动出击，帮助客户找出真正的需要，整理出符合客户需要的需求规格。
如果我们能说出客户内心深处真正想要的，而客户又不能表达出来的东西，我们才能真正做到“为客户带来价值” ！UML将会帮助我们提升需求分析的能力。

 

 

 

请看下一节……

 

作者：张传波

创新工场创业课堂讲师

华为某团队高级顾问

《火球——UML大战需求分析》作者

www.umlonline.org 创办人