## 连载:面向对象葵花宝典:思想、技巧与实践(17) - 需求分析518方法
对于大部分人来说,可能并没有机会进行需求分析,因为在大部分的公司里面,需求分析都是有很多工作经验的资深人员,或者是对系统很熟悉的老的开发人员。
所以,很多人都会对需求分析有一种景仰的心态,认为既然做需求的人要求这么高,那么需求分析一定很复杂、很难、很高级了。而且很多需求分析人员动不动就会教训“你要站在客户的角度”、“你要全面的分析”等,然后再抛出几个需求建模之类的玩意吓吓你。。。。。。
但其实做需求分析一点都不高深,只要掌握正确的方法,大部分人都能够做需求分析,而且可以做的很好!
而且这个正确的方法掌握起来很简单,不需要你另外再去买一本书刻苦阅读,也不需要你花费大量的时间去实践,去探索。
下面我们就来看,这个简单的正确方法究竟是什么。
我总结起来就是“**需求分析518方法**”,简称“我要发”,具体来说就是5W1H8C!!
5:5W,即When、Where、Who、What、Why
1:1H,即How
8:8C,即8个Constraint,包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性Compatibility
下面我们来详细分析这几个点。
#### 【5W】
5W:5W作为一组,首先是它们都以W开头,但这不是最关键,最关键的在于这些是一个需求产生的环境,或者说上下文(英文Context)。
为什么我们要关注需求产生的环境?很简单:环境影响需求。
举个很简单的例子:同样是垃圾桶,放在巴西贫民窟的要求和放在纽约帝国大厦肯定不一样。贫民窟可能有很多顽皮的小孩,将垃圾桶作为玩具,或者作为足球的射门目标;而帝国大厦都是文质彬彬的白领金领,对美学可能有特别的要求;因此,两个不同地方的垃圾桶,需求是完全不一样的。
有人会说,客户难道不是最明白他们需求的环境么?为什么他们不直接告诉我们?
前面我们提到,客户往往基于自己的经验、理解、学识等,给出一个解决方案,然后他们跟你说这是他们的需求。理想的情况,当然是客户非常在行,最好就是软件分析师出身的;但现实却往往不妙,很多客户对软件的理解可能仅仅停留在Windows甚至QQ上,甚至有客户会认为你会变魔法,只要他说一个简单需求,你就能变出他想要的!
客户当然不会是软件分析师,我们也不是魔法师,因此,我们必须亲自出马,弄清需求产生的环境。
==When==
这是和时间相关的环境信息,常见的时间信息有:
1) 季节信息:春夏秋冬等
2) 日期信息:节日、假日等
3) 作息事件:白天、晚上、凌晨、早晨、上午、下午、晚上、深夜等
一个简单的例子:我在以前公司做通讯设备的时候,如果是做数据倒换工具,都要求非常智能,最好是一键式操作?为什么呢,因为数据倒换都是在晚上凌晨2~4点进行,此时操作人员最困,思维最迟钝,如果你做的数据倒换工具需要操作七七四十九大步,九九八十一小步,而只要一步出错就全部重来,那么谁敢去操作?
==Where==
这个事和地点相关的环境信息,常见的地点信息有:
1) 国家、地区:不同的国家和地区有不同的文化、风俗、制度等;
2) 室内、室外、街道;
3) 建筑物
一个简单的例子:一个垃圾桶,放在室内就可能要求美观小巧(不占地方);而放在室外就可能要求防晒、防雨、防风、防疯子,而且要求比较大。
==Who==
这是和参与者相关的,注意我这里用的是“参与者”来描述的,而不是说“人”,为什么呢?
因为很多外部参与者不一定是“人”,例如外系统、动物等都可以算作Who里面的。
常见的参与者信息有:
1) 投资者、管理者
2) 使用者、维护者
3) 监督者、评估者:例如政府机构、监管机构等
4) 其它系统
一个简单例子,银行的ATM机,参与者有如下几类:
顾客:使用ATM机器取款、存款;
银行维护人员:每天将钱放进ATM机器;
质检机构:根据XX法律对ATM机进行检查;
==What==
这个就是客户最终想要的输出。例如一个文档、一份报告、一个图片、一个系统等。
一般情况下,这也是我们看到的最原始的需求。
==Why==
这个就是客户遇到的问题、困难、阻碍等,也是客户提出需求的驱动力。
只要是客户觉得不爽的地方都是Why的范围。
【一个长颈鹿的实例:5W】
有一个建筑公司的需求分析人员收到了一个客户需求“给我建一栋很大的房子”,于是建筑公司就建了房子,房子是欧式风格,又大又宽敞,全套宜家家居,全木地板,进口电器。。。。。简直是应有尽有,结果客户来收房子的时候说了一句话,让建筑公司吐血,你知道是什么话么?
客户说:“先生们,我是要一栋房子给我们的长颈鹿住!”
因此即使是简单的一句话需求,我们也需要详细分析。例如:
Who:这套房子的购买者是动物园、管理者是动物园的饲养员、使用者是长颈鹿、评估者可能是动物管理协会、卫生局等政府部门”
When:这个可能要求一年四季了,如果长颈鹿知识运来展览一下,那么就是展览的这几个月。”
Where:这个房子要建在动物园,而不是其它居民小区,那么动物园肯定有一些相关的规定”
What:要求一套房子,但不是简单意义上的房子,而是长颈鹿住的房子,这就需要考虑高度、围栏等”
Why: 这个就可能动物园要临时展览,也可能要引进长颈鹿,也有可能是原来的长颈鹿房子破旧了”
虽然我们前面讲的时候,5W都是一视同仁的,但实际上有一个W是非常关键的,如果这个W错了,那么即使其它4W全部正确,也可能导致最后没有满足客户需求,客户不满意。
这个最关键的W就是Why,因为只有真正了解了客户的需求驱动力,才能解决客户的问题,而只有解决了客户的问题,那么客户才会真正的满意。这也是我们前面提到的需求分析的终极目的是“挖掘客户的问题,实现客户价值”!
如下图形象的描绘了5W的关系:
![](https://box.kancloud.cn/2016-01-20_569f5cc9e225f.jpg)
#### 【1H】
H代表How,但具体是指什么How呢?
很多人常犯的一个错误是在需求分析阶段分析了需求如何实现,这样做是不正确的。需求分析阶段的How不是指如何实现需求,而是指需求本身的流程,如何实现需求那是设计阶段的事情!
你可能会有疑问:“需求本身还有什么流程”?
需求又简单和复杂之分,有的需求可能很简单,客户想要的东西也很明确;但有的需求比较复杂,涉及到多次交互,或者多个状态变化等,这种情况就要把需求的流程描述清楚。
举个例子吧,取款是一个需求,但取款本身包含多次交互,要插卡、输入密码、输入金额、打印账单、取钱这些步骤,How就是用来描述这整个流程是如何运行的。
说起来How很简单,但实际上这是需求分析工作量最大的一部分,How分析的结果是需求分析的主要输出,而且How分析的质量直接影响最后需求实现的质量。
在前面进行5W分析的时候,我们没有什么具体的指导方法,分析时主要靠分析人员的经验、水平,而How则不一样,进行How分析时有一套成熟的方法,这就是“用例方法”!我们将在后续章节详细介绍用例方法。
#### 【8C】
8C指的是8个约束和限制(Constraintes),具体如下:
| 性能Performance
性能是指系统提供相应服务的效率。一般而言,性能主要包括响应时间、吞吐量。
性能是很多系统架构设计的关键约束条件之一。例如,同样一个Web网站,虽然都是提供信息给用户流浪,但一个日访问量1万的网站,和日访问量10亿的网站,两者的设计是完全不一样的。
l 成本Cost
成本指为了实现系统而需要付出的代价。
成本也是很多系统架构设计的关键约束之一。例如,客户只愿意出100万来买这个系统,最后我们却设计了一个耗费1000万的系统,要么客户不愿买,要么我们自己亏损。无论哪种情况,最后都是我们赔本了。
l 时间Time
指客户要求什么时候交付。
l 可靠性Reliability
指系统长时间正确运行的能力,银行、证券、电信这些公司,对宕机时间要求很严格的
l 安全性Security
指对信息安全的保护能力,涉及到钱、身份证、社会保险号等需求对这个要求很高
l 合规性Compliance
指满足各种行业标准、法律法规、规范等,例如3C、SOX、3GPP、ITUT等
l 技术性Technology
有的客户可能要求我们采用某种技术,例如客户现在都是Windows的机器,那么就可能要求我们基于Windows平台开发
l 兼容性Compatibility
指我们的产品与系统与客户其它已有的产品或者系统的兼容能力,要知道现在很少有产品是孤立运行的,特别是在大企业、大公司中,多个系统都是互相交互、互相配合的。新的系统必须能够和已有的系统配合,否则将无法运行。
为什么我们要将这8个C单独列出来呢?
需求分为功能属性和质量属性,前面的5W+1H是属于功能属性,而8C是属于质量属性,一个需求最终是否被正确的实现了,既要看功能属性是否正确,也要看质量属性是否正确,两者缺一不可!
例如,你做了一个超牛逼的系统,功能超级强大,但一个操作需要10分钟,你觉得这样的系统客户有耐心用么?
- 前言
- (1) - 程序设计思想的发展
- (2) - 面向对象语言发展历史
- (3) - 面向过程 vs 面向对象
- (4) - 面向对象是瑞士军刀还是一把锤子?
- (5) - 面向对象迷思:面向对象导致性能下降?
- (6) - 不要说你懂“类”
- (7) - “对象”新解
- (8) - “接口” 详解
- (9) - “抽象类” 详解
- (10) - “抽象” 详解
- (11) - “封装” 详解
- (12) - “继承” 详解
- (13) - “多态” 详解
- (14) - 面向对象开发技术流程
- (15) - 需求详解
- (16) - 需求分析终极目的
- (17) - 需求分析518方法
- (18) - 用例分析
- (19) - 功能点提取
- (20) - 用例图的陷阱
- (21) - SSD
- (22) - 领域模型
- (23) - 领域建模三字经
- (24) - 设计模型
- (25) - 类模型
- (26) - 类模型三板斧
- (27) - 动态模型设计
- (28) - 设计原则:内聚&耦合
- (29) - 高内聚低耦合
- (30) - SRP原则
- (31) - OCP原则
- (32) - LSP原则
- (33) - ISP原则
- (34) - DIP原则
- (35) - NOP原则
- (36) - 设计原则如何用?
- (37) - 设计模式:瑞士军刀 or 锤子?
- (38) - 设计模式之道
- (39) - 设计原则 vs 设计模式
- (40) - DECORATOR模式
- (完)- 书籍已经出版