耗尽脑汁的需求分析工作--转自《火球-UML大战需求分析》

最新推荐文章于 2021-10-14 16:41:02 发布

chenghuyi8987

最新推荐文章于 2021-10-14 16:41:02 发布

阅读量151

点赞数

原文链接：https://my.oschina.net/joanfen/blog/169450

版权

1、需求分析面面观

客户需要的是一把梯子,系统分析员了解到的是一张凳子,开发人员做出来的是一张桌子,测试人员以为是一张椅子......很多角色参与项目工作,每种角色会从自身角色出发来理解需求,以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析 :

客户一方的总倾向是:自己少花钱,让软件公司多做事情。另外要说明的是:

而软件公司一方的总倾向是:多拿客户的钱,尽量少做事情。

影响各人对需求理解的主要因素有两方面:一方面是角色的思考倾向,上表反应了这点;另外一方面是人的需求分析能力,能力越强的人越能把握需求,本书重点讲解的内容就是如何活用 UML 来提升需求分析能力。

而更“离谱”的是:每个人嘴巴上说的需求和心目中的需求总是有差异的 ,所谓的“词不达意”,受表达能力所限,不是每个人都能完整准确地表达自己的想法 ;有时候客户今天想要这个,明天想要那个,甚至不知道到底想要什么!其实客户的这些表现,说明了客户对需求的认识是持续进化的。

2、持续进化的客户需求

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

楚国有人坐船渡河时 ,不慎把剑掉入江中 ,他在舟上刻下记号 ,说:“这是我把剑掉下的地方。”当舟停驶时,他才沿着记号跳入河中找剑,遍寻不获。这就是刻舟求剑的故事。

客户的想法总是在变化的,但总体来说是螺旋前进的,客户需求总是持续进化的,不要对此有任何抱怨,否则我们就是 “刻舟求剑”之人了!

某系统已经上线了,以下三种情况,你会更喜欢哪种情况呢?

A. 客户一直没有提出过任何问题。
B. 客户开始提了一些问题,但很快就没有其他问题了。
C. 客户一直在提问题,项目组解决这些问题后,新的问题又来了,如此不断重复。

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

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

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

从某种角度来说,需求变更其实是好事,说明客户对需求的理解更进一步,而我们觉得不适应,往往是因为我们对需求理解的进步程度不如客户。请看下图:

此图表示项目开始后随着时间的发展,客户和项目组对需求理解程度的上升趋势。

在时间=0 时,客户的曲线并不是从零开始的,而是有一定起点的。这表明,客户在项目刚开始的时候,对需求是有一定认识的。而项目组在项目最开始时,对需求的理解几乎是零。

随着时间的发展 ,客户对需求的理解越来越强 ,尽管项目组对需求的理解同样也变强 , 但项目组对需求的认识总是落后于客户 ,这样需求分析工作肯定陷于被动 ,总会被客户“牵着鼻子走”,很容易出现互相责怪的局面 :客户责怪项目组水平太差 ,而项目组责怪客户需求变来变去。

要打破这样的局面,项目组需要做到下图的效果:

项目刚开始时,客户对需求的理解确实比项目组强,但项目组在很短时间内对需求的认识超越了客户。从图中的 “交点”打后,项目组对需求的认识总领先于客户。项目组应具备超强的业务学习能力,切实理解客户的真正需要,为客户规划出真正符合其需要的软件系统。

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

手机短信订餐系统

接下来我将会介绍一个手机短信订餐系统的故事,这是一个由真实个案改编的故事, 通过这个故事来体会需求分析工作背后的道理。

某 IT 公司规模不大,员工 100 来人。公司有一个简单的定餐系统,员工每天可以在公司内部网站上提交当天午餐定餐,前台汇总各人定餐后,将定餐汇总传真给餐厅,餐厅根据传真送餐。

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

于是老板想出了这样的办法:做一个手机短信定餐系统,不在公司的员工可通过手机短信定餐。

于是成立了手机短信定餐项目小组,购买了手机短信收发的硬件,解决了选餐单、定餐、取消定餐等技术问题。但这个系统一会灵一会不灵,问题是出在软件、硬件,还是中国移动都难以搞清楚 !做项目做麻烦的事情之一就是遇到“幽灵问题”,时而出现时而正常 , 项目小组挥汗如雨地试图解决这些问题,可一直没有办法搞定。

老板大发雷霆了,怎么这样小的事情,竟搞成这个样子?

后来有人提出来:不在公司的员工,打电话回公司告诉前台吃什么,不就搞定了?

于是全世界恍然大悟,天啊!

需求分析核心的问题就是客户到底想要什么的问题!

客户往往只会有朦胧的大概的想法,他们提出来的需求,只是表面的,不全面的,甚至是互相矛盾的,我们需要透视它的本质。

我们做需求分析工作,往往会将需求分析和软件设计混在一起。需求分析核心目的就是解决软件有没有用的问题,而软件设计是解决软件用多大的成本做出来的问题。

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

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

给客户带来切实的价值才是我们真正的任务 ,而不是盲目听从客户的要求而不加分析。