当前课程知识点：软件工程与软件自动化 > 第一章 软件工程基础 > 1.3 唯一不变的是变化 > 授课视频3/3
嗨，大家好
下面我们继续讨论需求的捕获与分析
我们这部分主要讨论分析
捕获呢，经过各种各样的方式我们捕获得到了
并且对待变更呢，我们也做了一些应对
那么分析的时候呢
我们要确定几个方面
第一个方面就是要确定涉众
这是一个很重要的概念
就是利益相关人员
就是我做的这个软件会影响到哪些人
对哪些人有好处
对哪些人没好处
如果没好处的人
公司里有些部门
现在公司要开发一个软件
这个软件对他们这个部门来说没有任何好处
只能给他们带来更多的工作量
那么他们这个部门可能会觉得这件事与我没关系
甚至可能会影响到工作量了么
比如说，前几年北京刚刚施行一卡通的时候
就是公交一卡通的时候
原来的公交车上有个售票员么
一卡通自动刷卡的时候
售票员的工作就受到了威胁
一卡通上了
用户自己来刷卡了
那售票员就要失业了么
对他们来说
这是很大的一个挑战
如果你是一个售票员，你会怎么想？
欢迎这个系统上线
然后我就可以下岗了
挣不到钱了
所以在公司部门里面，有类似的利益相关的
如果我们软件的开发
上线运营影响到他们的工作的话
他们可能会阻挠或消极应对
所以对涉众的分析呢
是非常重要的
要确定涉众代表
公司里面哪些人分成哪几类的涉众
每一类的涉众里面我们要确定一个代表
他要能说了算
如果他说了不算
你和他交流
从他那里获取需求是没有意义的
然后在项目当中加入涉众代表
然后呢座谈，问卷调查等等
然后基于传统的需求捕获技术来捕获需求
然后我们要针对这种需求组建需求分析的队伍
就是要组建一个小分队来进行需求分析
这个人员不能太多
多了没有用
同时呢，这个需求分析人员
要具备一定的问题域的知识
比如说客户这个软件是搞航空领域软件开发的
如果你缺乏这个领域知识
那你这个业务就不容易理解
我们在和客户进行交流分析的时候呢
我们要把我们的初期的需求
往往会作为一个合同的附件附在合同的后面
这时候合同当中要说清楚
你这么多钱，比如500万的开发费用
我们要做什么和不做什么
不然的话呢
最后在交付的时候
客户说你应该包括这个东西
他说不应该啊，理解不一样
我见过一些开发合同上面写着
最后乙方要给甲方交付相关文档
这个相关两个字就非常的有问题
什么叫相关啊，这太模糊了
到时候交付的时候
他说某文档是相关的
你说是不相关的
这就容易扯皮了
在分析的时候
我们要分析哪些是稳定的需求
哪些是易变的需求
稳定的需求变化的可能性不大
我们在设计的时候就在这些稳定的需求之上
进行分析和设计
否则就像你把你的系统的架构设计
放在一个沙滩上一样
海水过来之后
沙子消失
你的设计就会崩溃
刚才提到了涉众
你一定要仔细的分析你做的这个软件
涉及到了涉众的哪些利益
尤其是那种损害了涉众利益的那些人
那些涉众
要在系统当中给予适当的补偿
那么什么是有效的需求分析人员呢
在现实的软件开发过程当中
大多数的需求分析人员
并不是一开始就是做需求分析的
一般都是从一线开发人员成长起来的
有一天老板说，小张，挺机灵的
不错，明天跟我去见见客户
那边有一个新的项目
一下子就从开发人员变成了一个需求分析人员
这是小型公司的情况
当然，随着公司的扩大
需求分析人员慢慢会逐步的固定下来
但是现在对软件公司来说
很少有那么专业的职位
需求分析人员
并且你就做需求分析
其他你什么也不做
很少有这种情况
开发人员平常都是在一个数字的世界当中
我们看看啊
盯着屏幕
双手在键盘上快速的敲打
目光说有点呆滞也好啊
说有点自信也好啊
游离在虚拟的数字世界当中
在现实世界当中
我们做需求分析
我们和客户交流
我们不能说句话让客户不高兴，
什么样的客户都有
这是两种不同的工作环境
需要不同的技巧
需要不同的训练
从开发人员直接转换为需求分析人员是不行的
需要一些专门的技巧的训练
具体来说呢
一个有效的需求分析人员
在需求分析的过程当中
我们要建立一个真正的伙伴关系
就是说，你是和人打交道的
你不是和计算机打交道的
这个时候呢
你要和他建立一个真正的伙伴关系
第二个能力
就是要在错综复杂的现象当中
发现问题背后的问题
这个很重要
就是我们说的超越用户
用户没看到的问题你看到了
在陌生的领域里面学的更快
一般情况下，我们的软件公司
除了行业软件公司
我们只做医药领域行业，只做百货的
其他公司更多的是什么都接
什么活都接，各个领域都接
你做完一个医药领域的软件
转身去做一个铁路领域的软件
那个领域对你来说可能是完全陌生的
这就需要你在陌生的领域内学的很快
你要和用户进行大量的交流
交流的时候呢
你需要用用户的语言
你不能用IT的语言，像C++，线程啊
什么socket啊
客户听不懂
作为需求人员呢
你要用一种用户能听得懂的语言进行交流
总之呢，一个有效的
我们这里不说优秀的需求分析员
只说有效
你能不能胜任这个工作
他必须用自己的智慧行动和真诚
去发现需求，挖掘需求
这时候，我们用一些好的方法进行训练
养成一些好的习惯
能够让我们的需求分析更加有效
怎么才能建立真正的伙伴关系呢
首先是意识问题
我们有句话说
技术如果离开了市场
将变得一文不值
从某种程度上来说，这句话是对的
技术是为市场服务的
如果没有市场的需求，技术放那儿会闲置
当然了，我们说我们的基础研究
是要领先于我们的应用研究
但是在一般的软件开发市场当中
我们要有一个服务意识
我们做软件开发的
我们是服务于客户的
我们技术很牛，很厉害
但是用户不需要
用户的需求我们满足不了
那我们的技术就一点用也没有
所以说我们做软件开发
做需求分析
要像饭店服务员一样
服务好客户
让他达到他的目标
尤其是他的业务目标
是我们努力的方向
培养人际关系，人和人打交道么
双方的合作有没有结果
取决于双方相处的是否愉快
如果我见了客户我就生气
我怎么进行需求的捕获和需求的分析呢
第三呢就是要有商业想象
有同学说了
我们本身就是搞技术的
我们缺的就是商业想象
我们是搞技术的
但是我们是技术方面的专家
我前面提到过二八理论
我们搞技术的不能只盯着技术
我们还需要一些管理啊
心理啊，经济学方面的
包括商业方面的基本知识
具有这样一个嗅觉
这样才能让你更好的用你的技术为客户服务
发现问题背后的问题
这个是需要一定的技巧和能力
如果需求分析只停留在表面的问题
用户说要这个，要这个
你说OK给你这个给你这个
你不能明白客户真正关心的是什么
你开发出来的软件
用户拿到软件之后，还行
都是按照合同开发的
但是我觉得这个软件不是太满意
哪儿不满意
说不上来
就是觉得不太好
不能发自内心的满意
用户的需求
他告诉你说我需要某个功能
你完成了，解决了
但是你没有解决真正的价值
我们举个例子，比如你女朋友说饿了，去吃饭
你说，哎，给你买了个面包，吃吧
你认为某某某做的挺好
你饿了，吃饭
但她的真正的需求可能是你
有好长时间没有陪她了，
所以说吃饭只是个表面的需求
而真正的需求是她需要陪伴
在和客户交流的时候呢
我们当然应该去熟悉用户的行业
用他们的语言来进行交流
不能用自己的IT行业的术语来进行交流
这里面第一，就是我们服务的意识
用户是上帝
用户是给我们付钱的
我们要让他们满意
我们要做出让他们满意的这种产品
所以说，这里面有一点科普的意思
有的人特别善于把这种IT领域里面的
特别高深的东西用特别通俗的语言
解释给别人听
有的做不到
越解释越复杂，有的人就是越解释越简单
在需求分析里面呢
我们常用的一种方式就是用例技术
就是我们UML里面的用例图
用例描述进行分析
这个用例呢
实际上就是对需求分析结果的过程的记录
这个用例呢，我们一般情况下画这个圈
椭圆形的一个用例
这个用例呢，可大也可小
大的用例，大颗粒的用例
实际我上是给客户看的
我告诉你，这个圈是一个订票
这个圈是一个用户管理
客户没有专业知识
他一看他也明白了
但是这么大粒度的这种用例图
对设计来说
对我们的设计人员来说是没有意义的
我们一看就明白，还用画个大饼图么
不需要，缺乏足够的信息
所以说对我们设计人员来说
我们希望这个粒度要够小
但粒度过小呢，客户又看不懂了
所以说这个用例图画起来就比较纠结
其实不用纠结
有的时候有些公司画出来两套用例图
一套用例图，大粒度，给客户看
让客户看一眼，哦，明白了
这几个饼就是我需要的那几个功能，没问题
给内部人员进行分析设计交流的时候
我画一个小粒度的，密密麻麻全是小饼
之间的各种关系
大家一眼也能看明白
所以我们对用例设计这块呢
我们也提到了
进行需求分析的团队人数要少不能太多
要具有不同的背景不同性格的人
对用例进分析
不同背景不同性格的人
为什么要这样强调呢
比如说，你有几个同学
大学的好友
你们想毕业之后创业
你们成立了一个创业公司
你们几个呢，脾气秉性
人生观价值观都完全一样
同样视金钱如粪土
很少有不同意见的
OK，现在你们公司面临着一个重要的决策
大家举手表决，一举手，全同意
于是呢这个决策就执行了
但实际上你这个决策可能把公司带入一个覆灭的命运
反过来，如果你们公司的决策层
有不同背景不同性格的人
有财务的，有市场的
有技术的，有法律的
但法律的现在小公司有专业的法律顾问，对吧
但是，你有这个不同背景不同性格的人
我们在讨论同样一个决策的时候
我们会从不同的方面不同的角度看待同一个问题
这样就会有不同的意见，就会有争吵
但这种争吵会让你的决策更科学更合理
从而引导你的公司生存下去
我们做需求设计的时候其实也是类似的
这样的话才能保证我们对用户的需求
从不同的角度进行分析
我们在用例分析的时候呢
尤其是出现了两个主要的误区
第一个误区就是
用例分析包括了整个需求过程
用例图啊，用例描述啊
画的不亦乐乎
实际上呢，用例分析不能涵盖需求的捕获
就是捕获完了才能进行分析
就是在传统的需求捕获的基础之上使用的
也就是说用例分析技术不可能包括需求的捕获
需求分析有人认为是分解的技术
它其实是一种合成的技术
它就是把你捕获的
从不同角度不同渠道获取的数据进行整合
最终进行分析
哪些人适合做分析呢
乐于学习，愿意学
跨领域要求我们学习
善于学，会学，并且学的快
跨领域的话
不可能给你一年半让你去学习新的领域
能够站在用户立场上思考的人
要有服务意识
我们是为别人服务的
放下这种高高在上的架子
性格不同的人组成的小而平衡的团队
总结一下，我们需求这块呢
原来说需求分析设计
它也上升到了一个需求工程的地位
需求工程基本上分成两部分
需求的开发和需求的管理
开发包括需求调查，分析和定义
形成一个书面的需求文本
需求规格说明书
需求管理呢主要是说有没有变更控制
需求这件事情我怎么跟踪
客户的需求我需要怎么样的反馈和确认
好，这部分的内容暂时到这里，谢谢大家
-1.1 软件工程的前生今世
--开篇阅读
--授课视频
-第一章 软件工程基础--1.1 软件工程的前生今世
-1.2 万变不离其宗
--授课视频1/3
--授课视频2/3
--授课视频3/3
-第一章 软件工程基础--1.2 万变不离其宗
-1.3 唯一不变的是变化
--授课视频1/3
--授课视频2/3
--授课视频3/3
--外部链接
-第一章 软件工程基础--1.3 唯一不变的是变化
-1.4 亡羊补牢为时不晚
--授课视频1/2
--授课视频2/2
-第一章 软件工程基础--1.4 亡羊补牢为时不晚
-扩展阅读与话题讨论
--扩展阅读
--话题讨论
-2.1 方法论来源于恐惧
--授课视频
-第二章 敏捷开发--2.1 方法论来源于恐惧
-2.2 敏捷是什么
--授课视频
-第二章 敏捷开发--2.2 敏捷是什么
-2.3 典型敏捷开发方法
--XP敏捷开发方法
-第二章 敏捷开发--2.3 典型敏捷开发方法
-2.4 敏捷不是万能药
--授课视频
-第二章 敏捷开发--2.4 敏捷不是万能药
-专家谈敏捷
-扩展阅读与话题讨论
--外部链接
--话题讨论
-3.1 面向对象核心概念和基本特性
-第三章 OO与UML--3.1 面向对象核心概念和基本特性
-3.2 面向对象设计基本原则
-第三章 OO与UML--3.2 面向对象设计基本原则
-3.3 通用职责分配模式(GRASP)
--通用职责分配模式
-3.3 通用职责分配模式(GRASP)--作业
-3.4 从重构到模式
--模式和设计模式
-第三章 OO与UML--3.4 从重构到模式
-3.5 使用UML设计面向对象系统
--UML综述
-第三章 OO与UML--3.5 使用UML设计面向对象系统
-3.6 主要UML模型图绘制技巧
--UML用例图
--UML类图
-第三章 OO与UML--3.6 主要UML模型图绘制技巧
-扩展阅读与话题讨论
--设计模式有毒么？
--话题讨论
-4.1 案例简介
--书籍参考
--案例说明
-4.2 对象模型之一
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.2 对象模型之一
-4.3 对象模型之二
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.3 对象模型之二
-4.4 对象模型之交互
--授课视频
-第四章 对象模型分析--4.4 对象模型之交互
-扩展阅读与话题讨论
--图书推荐
--话题讨论
-5.1 软件自动化概述
--软件自动化概述
-第五章 软件自动化技术--5.1 软件自动化概述
-5.2 典型自动化方法和工具
-第五章 软件自动化技术--5.2 典型自动化方法和工具
-5.3 文档自动化
--文档自动化视频
-第五章 软件自动化技术--5.3 文档自动化
-5.4 测试自动化
--测试自动化视频
-第五章 软件自动化技术--5.4 测试自动化
-专家访谈
-扩展阅读与话题讨论
--话题讨论
-6.1 持续集成
-第六章 CI/CD与DevOps--6.1 持续集成
-6.2 持续交付和部署
-第六章 CI/CD与DevOps--6.2 持续交付和部署
-6.3 DevOps
-第六章 CI/CD与DevOps--6.3 DevOps
-专家访谈
-扩展阅读与话题讨论
--DevOps专题
--话题讨论
-7.1 质量和质量保证
--授课视频
-第七章 软件质量保证--7.1 质量和质量保证
-7.2 软件质量模型
--授课视频
-第七章 软件质量保证--7.2 软件质量模型
-7.3 SQA组织与职责
--授课视频
-第七章 软件质量保证--7.3 SQA组织与职责
-7.4 全面软件质量管理
--授课视频
-第七章 软件质量保证--7.4 全面软件质量管理
-专家访谈
--专家访谈
-扩展阅读与话题讨论
--外部链接
--话题讨论
-8.1 软件过程综述
--授课视频
-第八章 软件过程改进--8.1 软件过程综述
-8.2 软件过程改进
--授课视频
-第八章 软件过程改进--8.2 软件过程改进
-8.3 能力成熟度模型
--授课视频
-第八章 软件过程改进--8.3 能力成熟度模型
-8.4 过程改进标准框架
--授课视频
-第八章 软件过程改进--8.4 过程改进标准框架
-扩展阅读与话题讨论
--话题讨论
-9.1软件复用综述
--授课视频
-第九章 软件复用--9.1软件复用综述
-9.2 软件构件技术
--授课视频
-第九章 软件复用--9.2 软件构件技术
-9.3 软件复用实施
--授课视频
-第九章 软件复用--9.3 软件复用实施
-9.4 微服务架构
--授课视频
-第九章 软件复用--9.4 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交
