## 连载：面向对象葵花宝典：思想、技巧与实践（15） - 需求详解 很多人像老黄牛一样辛辛苦苦做了很多年软件开发，但却连“需求”到底是什么都不清楚。当然，没有人自己会承认这点！ **【需求到底是什么】** 凡事都有一个开头，软件项目也不例外，对于软件项目来说，需求就是项目最开始的一个输入。 参考维基百科，需求定义如下： In systems engineering, a requirement can be a description of what a system must do, referred to as a Functional Requirement. 简单翻译一下就是：需求即系统需要做什么。 但正是这个简单的定义，让很多人陷入了**陷阱**：需求即功能。 单纯从字面意思来理解这样也是没有问题的：系统需要做什么，当然就是系统要提供什么功能了！ 我们来看一个简单的例子：ATM自动取款机。 有的人说，ATM的功能是取款、存款、查询余额，所以针对ATM的需求应该是：取款、存款、查询余额； 有的人说，ATM的功能有很多：识别卡、密码认证、点钞、验钞、查询余额、跨行取款等，所以针对ATM的需求应该是：识别卡、密码认证、点钞、验钞、查询余额、跨行取款。 如果你是ATM购买商，你认为哪种才是你的需求？ 如果你是ATM制造者，你认为哪种才是你的需求？ 如果你是ATM使用者，你认为哪种才是你的需求？ 可能大部分人都会支持第二种，原因很简单：取款也要密码认证、存款也要密码认证，所以密码认证是一个需求，而不是分到两个需求里面。 而且第二种方式划分需求有一个好处：系统最后提供的功能和需求基本上是一一对应的。 看起来很美妙，但其实我们忽略了一个问题：采用第二种方式的主要原因是我们对ATM机很熟悉了！ 但如果换一个身份，比如说你是一个只识字的农民工，你对ATM机的要求会是“识别卡、密码认证。。。。。。”这样专业的需求么？ 肯定不会，你的需求应该是“取款”、“存款”、“查询余额”。 我们继续打破砂锅问到底：为什么农民工兄弟的需求肯定是“取款”、“存款”、“查询余额”，而不是“识别卡”、“密码认证”、“点钞”。。。。。。？ 我们假设一下，假如农民工兄弟对ATM的需求是“点钞”，那么就会出现这样滑稽的场景：他经常拿着卡去ATM机，让ATM机点一下钞；又或者他的需求是“密码认证”，那么他经常拿着卡去ATM机验证一下密码。 你当然不会看到这样的场景，农民工兄弟也不会有这样的需求，他只管能取到钱即可，因为取到钱他就可以拿钱去花了，至于取钱的过程中管你是密码认证、点钞还是验钞，说的搞笑一点：他更希望把卡插进去，钱就自动吐出来而且不受限额。   相信到这里，你已经能够明白需求和功能的差别了，我们总结一下： 需求：对客户来说有价值的事情； 功能：系统为了实现客户价值而提供的能力；   因此，区别是需求还是功能的方法很简单了：只要判断是否对客户有价值。 我们可以举更多例子来证明这个方法： POS机：“买单”是需求，“商品扫描”、“金额汇总”、“收银”等是功能，因为买完单后顾客就能将产品拿走； 汽车：“驾驶”是需求，“发动机”、“刹车”、“加速”等是功能； 打印机：“打印”是需求，“进纸”、“设定”、“与电脑连接”等是功能； 。。。。。。 （有兴趣的朋友可以自己多想想） ## 【需求非常重要】 俗话说，万事开头难，需求是软件项目的最开始输入，肯定是非常重要的，按道理来说也应该是需要重点关注的。   然而现实情况却恰恰相反：很多项目都不怎么重视需求！   你可以经常看到这样的场景： 需求分析人员和客户沟通了一下，然后把客户的要求简单整理了一下就交给研发了。。。。。。 项目计划比较紧，那么就把需求分析阶段加快一些吧（实际上就是减少投入时间）。。。。。。 产品给了一个简单的需求，为了能够快速交付，没有怎么分析就开始设计编码了。。。。。。   虽然看起来时间是节省了，项目是加快了，然而最终的结果却令人失望：据统计，有将近1/3的项目失败或者陷入困境时因为需求原因导致的！   这个就是所谓的“垃圾进垃圾出（Garbage in, garbage out）”的效果，即： 如果最开始的输入是错误的，后面的过程再怎么优秀，最终都会输出垃圾产品。而且可能是后面越优秀，最终输出越垃圾，就像你朝一个错误的方向跑步，跑得越快离正确的终点越远一样。   举一个虽然恶心但很形象的例子：给你一坨屎，你放到饼干生产线上，最后生产出来的不是饼干，而是像饼干的一坨屎！：）   你可能会说，错了我改还不行么？ 当然是可以的，但你要做好心理准备，还有一个更加令人抓狂的事实：修复需求错误的问题的成本非常高昂！   我们假设编码阶段发现和修复一个错误所耗费的人力是1个单位，那么在测试阶段修复需求错误的成本是5~10倍，在维护阶段（产品正式应用后），修复需求错误的成本是20倍，而如果在需求阶段修复需求错误，成本只需要0.1~0.2即可。   也就是说，需求错误的成本存在这样的比例关系：维护阶段修复 = 需求阶段修复 * 200 ！ 原因显而易见：如果你的需求错了，那么你几乎是要把软件项目重做一遍！   相信经过前面的分析，你对于需求的重要性已经有了充分的认识了。 请时刻牢记：需求很重要！