《软件方法》需求启发

第7章 需求启发

我不知道应该说些什么，哦……爱你在心口难开

《爱你在心口难开》；词：佚名，曲：Sonny Curtis、Jerry Allison，唱：凤飞飞；1981

 

第2到第6章的内容都是关于如何思考和建模得到需求模型，但需求模型的质量依赖于需求的素材。从涉众处获取需求素材的工作叫做需求启发。

需求启发和需求建模互相影响。需求启发得到的素材质量越高，得到高质量需求模型的可能性就大大增加；需求建模能力越强，越能指导需求启发工作，从涉众处得到高质量的素材。拿做菜类比，如果采购的食材质量很差，技艺再高超的厨师也烹调不出美味的菜肴；不过，厨师技艺越高超，对食材的要求就会越严格，越能推动买菜的人去采购更好的食材。

7.1 需求启发要点

7.1.1 启发障碍

许多时候，开发人员把需求启发想得太容易。经常可以听到“采集需求”这样的表述，好像需求是蘑菇，乖乖地躺在森林里，开发人员需要时，就像采蘑菇的小姑娘一样，一个，两个，三个，四个……把它们都采回来。哪有这么容易！需求不是蘑菇。开发人员要能够像猎人一样，用锐利的眼睛发现隐藏在丛林中的猎物；像侦探一样，用慎密的思维判断出伪装成好人的凶手。

需求的一个启发障碍是知识的诅咒（Curse of Knowledge），意思是：一旦知道某个东西，就很难想像不知道它会是什么样子。1990年，斯坦福大学研究生Elizabeth Newton做了一个著名的心理学实验：让敲击者在桌子上敲击最常见的歌曲，听众根据听到的节奏回答是什么歌曲，然后让敲击者估计听众答对了多少。120次的实验中，敲击者预测听众猜对的比率会大于50%，真实的结果是听众猜对的比率只有2.5%。因为听众听的是敲出来的声音，敲击者听的是大脑里已有的歌曲。

知识的诅咒在需求启发中体现为沟通的困难。开发人员懂得许多软件设计和实现的知识，这些知识会有意无意地引导开发人员从实现的角度看需求；涉众在领域里面工作多年，许多事情在他看来一目了然，很难用开发人员能理解的言语表达出来。

需求启发的另一个障碍是做和定义的不同。涉众会做一件事情，不代表他能够把这件事定义出来教给其他人。在足球领域，号称球王的贝利、马拉多纳执教并不成功，最近十年的世界最佳主教练穆里尼奥踢球水平却很一般。

理解以下两点要点，有助于克服需求启发中的障碍：

7.1.2 和涉众交流的形式应该采用视图，而不是模型。

第1章说过UML的优点是提高沟通的效率，还拿五线谱做了类比。五线谱是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥要懂、歌手要懂（注意：是懂五线谱，不是人人都要用五线谱作曲），但听歌的不需要懂五线谱。同样的，UML只是在“软件开发人员”圈子里面的统一表示法，基于UML的沟通主要是发生在开发团队内部，不能强行拿着UML模型和涉众沟通。

经常有人问：客户看不懂UML怎么办？这个问题本身就有问题，提问者潜意识里可能认为“客户”是一个人。所谓“客户”其实是一大堆“涉众”，他们学历职位有高有低，年龄有大有小，健康有好有坏，关注的利益更是各自不同，怎么能寄望用一个模型和所有的涉众沟通？

那么，和涉众交流的介质是什么呢？不是需求模型本身，而是需求模型的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只关心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交流。涉众连谈话都不乐意，我们也可以通过观察来获取素材。需求启发的技能有许多种，不仅仅是浅薄的“画个界面草图给用户看”，“问用户想要什么功能”。许多伟大的创新正是有心人在涉众不作声的情况下，观察涉众的行为得到的。

如果不了解这个区分，直接拿UML模型去和涉众交流，很容易导致“四不像”。为了迁就不同涉众的知识水平，开发团队只好损害模型的严谨性，即使是这样，涉众也不一定接受，交流效果还是不好，而且还会因为涉众的交流形式多变而影响开发团队开发过程的稳定——双方都受害。客户的领导说，我不习惯看UML模型，就知道以前看的是××标准格式的文档，我只在这个格式的文档上签字，难道我们就不用UML建模了？下一个项目的客户领导喜欢另一种格式怎么办？下下个项目根本不需要签字怎么办？大众产品没有“客户领导”签字确认需求怎么办？不少开发团队十年如一日没有进步和积累，“交流影响开发”是原因之一。

开发人员有意无意把建模的目的理解成和涉众交流，有时背后的思想还是“懒”字，因为这样想，就有了推卸责任的机会：不是我不想建模，就算我建模了，客户不想看啊。

拿患者和医生类比，您想想下面的情况合理吗？患者想看核磁共振成像，医生就给他做；患者不想看甚至昏迷不醒，医生就干脆不做？显然不是这样，医生应该按照成熟的治疗套路，该做什么检查就做什么检查，该如何治疗就如何治疗。

图7-1 交流和开发分离

 

 

7.1.3 和涉众交流的内容应该聚焦涉众利益，而不是需求。

软件的需求规约相当于电影剧本。电影剧本并不是由观众直接提供的，而是由编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益来决定的。涉众没有资格、也没有责任提供需求。

。。。。。。。。。。。。。。。。。。。。

 

祝各位中秋国庆快乐，节日有空下载阅读！

《软件方法（上）业务建模和需求》第二版草稿pdf文件下载（适合手机屏幕），更新日期：2017.9.30

https://pan.baidu.com/s/1eSlcdsY

《软件方法（上）业务建模和需求》第二版草稿pdf文件下载（适合PC屏幕），更新日期：2017.9.30

https://pan.baidu.com/s/1nuXqDlf

您在阅读《软件方法》时如果发现错误，欢迎在群里告知。如果作者认为有道理，决定在下一次发布时根据您的意见修改，将付给您5.12元报酬，并在书中说明您的贡献。报酬通过支付宝或微信支付。

（1）任何您认为的错误都可以，包括错别字。

（2）同一错误仅支付最先指正者报酬。 

（3）请根据最新版本作指正。

目前挑错记录：

第五元素：找出142个错误，获得奖金727.04元

Lihongzhou：找出26个错误，获得奖金133.12元

半导体：找出21个错误，获得奖金107.52元

......

最新挑错

龙志超：找出6个错误，获得奖金30.72元

邹盛荣：找出3个错误，获得奖金15.36元

http://www.umlchina.com/training/course171014.htm

10月14-15日（周六日）深圳软件需求设计UML全程实作公开课

http://www.umlchina.com/training/courseadzoom.htm

10月17日（周二）19:30-22:30 领域驱动设计（三）