软件方法笔记-2愿景

1,需求是不断变化的,涉众利益要稳定
2,对于从零开始的团队，可以把“愿景”作为第一个引进的概念，团队先对“为什么要开发这个系统”达成共识。
  另一个需要建立的概念是“涉众”，我在写的这些代码影响到谁的利益？化的作用
3,愿景:在老大看来，引进这个系统的目的是什么
4,老大:平时我们所说的“客户”，是最有“地位”的涉众，权衡系统的各种需求时，他的意见是最重要的
5,如果我们的系统是为某个特定组织服务的项目，老大是比较好找的，就是该组织的某负责人。如果是一个产品，不是针对某个特定组织开发，老大就相对难找一点。这个时候，也要学会具体化，把产品当成项目来做，先定位到具体的组织（人群），再从组织中找到老大。
6,需求是一口深井，永远做不完。只要您愿意，可以满世界去调研所有医院，甚至不用调研，拍脑袋就可以得出上万条需求。关键是需求的排序，老大和愿景就是排序的首要依据
7,愿景:可度量的目标(减少...提高...缩短...)
8,提高防汛决策准确度是愿景不是功能。功能是具体的，查看云图，上报水客运行情况，调度分析

9，(查看云图，上报水客运行情况，调度分析)描述的都是“做什么”，已经是系统的功能需求。愿景不是问系统有什么功能，而是回答买了这个系统，对组织有什么好处

10,老大心底里是有度量指标的，否则，系统摆在他面前的时候，他拿什么来判断系统好不好？不过，要得到度量指标不容易.老大不是开发人员经常能接触得到的。大多数时候，代表“客户”的是“甲方信息中心主任”这样的人，而实际上这个人无法代表老大，更无法代表形形色色的涉众，只能代表他自己

11,愿景是老大针对系统的目标，那其他人的目标难道不重要吗？其他人的目标也是要关注的，我们把它叫做涉众利益。愿景实际上就是系统最重要涉众的利益
12,用例使用“执行者”（Actor）和“涉众”代替了原来的“用户”，这是一个非常大的突破。“用户”这个词混淆了演员和观众的界限.用户指可能和系统有接口的人肉系统，之所以说“可能”，是因为系统的需求没有推导出来，无法真正判断用户是哪些。例如做一个银行营业系统，认为营业员是用户，找营业员去问需求。这样先入为主的想法已经束缚住了我们的改进思维——很可能老大更希望废掉营业员这个人肉系统，毕竟计算机系统不只是简单地把纸上的东西往电脑里搬.即使最终保留了营业员这个人肉系统作为“用户”，从“用户”身上所获得需求素材的价值也不可高估.
13,在，越来越多的系统“用户”不是人，或者说，和它接口的系统是另外一个电脑系统。两个电脑系统交互的需求，难道就不用做了，或者可以随便做？非也。那只是相当于上台表演的不是人，是功夫熊猫，是变形金刚，是喜羊羊灰太狼，台下对表演说好说坏的观众依然是人。建立“执行者和系统在台上表演，涉众在台下看表演”的概念，对执行者为非人系统的需求捕获很有帮助。
14例子：
系统: UMLChina业务系统


老大: UMLChina负责人潘加宇


目标（度量指标）:


*减少技术专家花在非建模技术事务上的时间


*减少助理在协助技术专家工作时出现的错误


*减少助理处理日常事务的工作量

参考:http://blog.csdn.net/joeyon1985