需求分析训练营讲义

事件是梳理需求的关键
事件是系统运转的驱动者
事件是流程/协作的开始
事件是直接触发系统的 事件可能退化为场景
系统是被动的，事件是其行为的触发点 企业/组织的核心价值在于响应外部客户的请求，通过一 系列的协作满足请求，为客户和企业/组织带来价值
事件 vs. 流程
• 事件 vs.系统响应/交互行为 业务事件 客户购买商品 客户提供信用卡 有前提吗？ 业务流程（一个团队） • 事件到哪是个头？ 业务 业务活动1（单个人） 客户想买一件衬衫 活动2 客户来到购物中心 业务 活动3 客户试穿衬衫 …… 业务步骤1 业务步骤2 客户购买一件衬衫 …… 触发系统吗？
延伸阅读：如何获取、 阅读要点
II. 方向
开天辟地
目标商 业价值
业务大块
范围
业务大块
Stakeh older
约束
事件列表
管控点列表
场景列表
百步穿杨
——定义项目(P2-S2)
SERU需求方法体系创始人
徐锋
Fra Baidu bibliotek义项目
锁定目标 理清Stakeholder
明确约束
问题定义
业绩差距 管理等提高的地方
需求模型中的基本单元 在构件下创建包来表示
划定项目的业务范围
主题域划分 标识事件
标识管控点
识别管控点
报表是管控需求的实现 管控点是一类报表 需细分为具体的报表项
基于KPI 全局 基于汇报机制
数据分析 管控点
进度
局部 (基于事件)
异常 数据分析
II. 脉络
泾渭分明
目标商 业价值
业务大块
范围
业务大块
分工带来了 WBS分解获得
执行权限限制 执行结果控制
分支
活动
审核
流程分层原则
组织级流程：以部门为泳道/职能带区， 抽象层次由读者对象的管理视野决定
部门级流程：以具体岗位为泳道/职能带 区，与协作无关且非原子性活动不应体现
个人级流程：通常没有泳道/职能带区(或 分为用户/系统双泳道)，可尽量细化
子流程：如果个人级过于复杂，还可 以再次分层
Stakeh older
约束
事件列表
管控点列表
场景列表
功能
管理效益
数据 领域建模
质量 质量场景
流程分析 场景分析
模型合并
剥茧抽丝
——理清行为脉络(P3-S4)
SERU需求方法体系创始人
徐锋
理清行为脉络
流程分析
业务功能分析
边界分析
所有系统都有流程吗？
典型的信息系统 涉及多单元的复杂嵌入式系统
长交互：事件场景 短交互：事件即场景
• 工作流分析不足
• Demarco针对业务系统提 出过改进方案
仍然走技术驱动路线
1940-60s
1960-80s
1980-2000s
2009-
需求分析的角度
企业级
业务建 模者
业务驱动的 需求分析师
系统级
UI驱动型 DB驱动型
需求分析的本质
个人
系统
组织
意识到的需求
收集
无意识的需求
分析
未梦想的需求
问题 机会
机会差距 新技术/业务带来的机会
破解混沌不清的目标
角度
内部溯源—项目发起人 外部寻因—高层
目标破解
方法
头脑风暴 访谈项目发起人、高层
模板
问题卡片—源于RUP
问题+成功标准+范围—源于ACT
1
问题
2
3 影响
结果
4
解决方案优点
头脑风暴法—厘清问题
时间范围 业务 / 组织范围
成功标准或成果 成果达成的时限 客观性 完整性 (主谓宾 )
接口
数据
数据构成：领域类字段 数据推演：DFD、状态图
全局质量树 质量 + 目标场景决策卡
需求价值树
项目目标
业绩差距(问题) 机会差距(机会)
业务价值
Stakeholder
Stakeholder列表
Stakeholder关注点
操作层要求
效率 质量
需求分析全局观
视角与方法 核心线索
工具和产物
组织信息化需求分析大局观
需求分析训练营
——需求分析师五项修炼之一
SERU需求方法体系创始人
徐锋
课程体系介绍
一个突破
五项修炼
两大方向
需求分析师五项修炼V2.0
方案创新力
技术理解力
沟通力
业务分析力
需求管理力
I. 大局
按图索骥
按图索骥
——需求分析全局观(P1-S1)
SERU需求方法体系创始人
徐锋
需求分析全局观
视角与方法 核心线索
电子商务 个人软件 简单嵌入式系统 DSS
信息系统中流程与业务功能的关系
最终用户
管理者
信息系统中流程的本质
层次性 内在性 目标性
流程必须分层 描述 组织级、部门 级、个人级
流程合理性是 整体评价的
流程是系统交 付的最小单元 流程是疱丁解 牛的关键
不理解流程不 访谈操作层
流程的本质性要素
流程多路径 应对不同情景
挖掘
需求分析全局观
视角与方法 核心线索
工具和产物
需求的五种类型
约束+质量
接口
功能
数据
功能需求
功能
报表
特性
业务功能
业务功能的梳理
主题域
流程
业务功能
事件识别
场景分析
五类需求梳理要点总结
需求分解树
业务流程(事件)活动步骤 行为 + 管理控制点报表项
应用 系统
业务 子系统
数据关系：领域模型
解决方 案人群
机会
问题影 响人群
高层访谈结构
目标实现的跟踪—产品大局观
日本车真不安全？
奥迪在中国为何畅销？
定义项目
锁定目标 理清Stakeholder
明确约束
Stakeholder
项目博弈中的筹码持有人
Stakeholder分析
出资人
评价者
使用者
Stakeholder分析
1 Stakeholder列表： 筹码量分析—优先级
特性抽取 法
遗留系统 分析法
呈现主题域划分结果
强调横向关系
构件图 数据流图 层次图
强调数据交换与共享
强调纵向分解
最基本
列表
我们需要表述什么？
构件
我们分解出来的子系统
子系统之间的服务关系
接口
实现 关系
服务是由谁提供的
谁将使用这些服务
使用 关系
构件图示例
划定项目的业务范围
主题域划分 标识事件
标识管控点
2 Stakeholder档案： 筹码付出—关注点
3 需求跟踪： 筹码获得—价值分析
定义项目
锁定目标 理清Stakeholder
明确约束
三类约束
项目约束
事实/假定
实现约束
经济约束 进度资源约束
环境约束 行政约束
需求方业务环境 用户群使用环境 技术方构建环境 业界技术环境
重要的背景 验收要点
对技术的假设 对业务的假设
317例，52.83% 107例，17.83% 82例，13.67%
用户退货 制成品折旧
制造缺陷 其他
45例， 7.50%
29例， 4.83% 20例， 3.34%
分析问题—原因排序
高
用户退货
运输损耗
影响度
投资机会
订单不准确
高投资回报
制造缺陷 其他 制成品折旧
低垂的果实
低 难
置之不理
可执行性
易
价值分析—RUP问题卡片延续
5.一级 统计
6.效能 考核 1.获取纳税人 数据
纳税人
税务效能考核管 理系统
1.受理
1.核查 /审批 3.业务 注销
2.业务撤销
征管系统
涉税窗口
业务科室
产物整理
事件列表
优先级排序，估算并制定迭代计划 作为制定访谈计划的依据
事件分析
SRS目录
主题域下的一级分解 如果事件退化为场景可直接为用例模型
模型中的包
用户可理解 高内聚 低耦合
内部低耦合：主题 域之间接口简单
成败案例分析(1)
帐户管理 基本交易 网上银行
借记卡 信用卡 基 金
网上支付
……
……
孰优孰劣？
成败案例分析(2)
机具 数据采集 小额支付 一卡通
公交 出租车 小额商户
数据传输
……
……
孰优孰劣？
分几层呢？
应该不断分解下去吗？ 到底应该分几级呢？ 分解的目的是什么呢？
• 完整的需求方法体系 • 业务域（SubjectArea）
业务事件（Event）/管理
控制点（Report）用例 (Use case），形成完整的
数据库驱动
• 将系统看成数据库操作
• 设计思想在主导需求 • 不好用，用户不满意
用户故事
• 强调业务价值
• 充分考虑开发人员 • 对现场客户依赖大
业务分解结构
制成品折旧
制造缺陷
订单不准确
用户退货
注意：类别可嵌套
分析问题—用亲和图演绎
运输 运输损耗 ？
生产 制成品折旧 制造缺陷 ？
销售 订单不准确 用户退货 ？
找到每类的其他原因
分析问题—绘制鱼骨图
运输
运输损耗 制造缺陷
生产
制成品折旧
废品率太高
用户退货 订单不准确
其他
销售
分析问题—定量分析
订单不准确 运输损耗
跑马圈地
——划定项目的业务范围(P2-S3)
SERU需求方法体系创始人
徐锋
划定项目的业务范围
主题域划分 标识事件
标识管控点
生活中的子系统划分
家装时如何分解子系统
汽车需求分几块
主题域划分原则
独立性：每个主题 域可以独立交付
系统耦合性的根源 的问题域本身蕴含 的耦合性
外部低耦合：与用 户/部门对应关系 简单(1对多)
组织级流程
部门级流程
子流程
个人级流程
描述流程：选择正确的工具
UML建模标准 语义最丰富 强调行为流 强调活动内容
IDEF建模标准 强调数据流 未表示出谁执行 计费类系统最适用
跨职能 流程图
活动图
时序图
数据 流图
商业建模标准 复用性强 用户最容易接受
UML建模标准 强调行为流 强调协作
如何分呢？
基本策略： 非计算机域按业务划分，计算机域按功能价值划分，遗留系统可例外
非计算机域
• 列出所有职能部门 • 列出所有产品服务 • 选择合适维度 • 合并同类项
计算机域
• 从概要的用户期望 描述中抽取关键特 性集 • 分解特性集
遗留系统
• 分析修改哪些 • 分析影响哪些 • 分析新增哪些
职能/产品 划分
列出问题
成功标准
问题范围
产出：一组即时贴
头脑风暴法—分析问题
1
用即时贴收集问题原因
2
用亲和图对其进行归纳
3
在亲和图基础上进行演绎
4
用鱼骨图定性问题
5
抽样调查帕累托图定量
分析问题—收集原因
问题1：废品率太高
用户退货 制造缺陷
订单不准确
运输损耗
制成品折旧
……
分析问题—用亲和图归纳
运输
生产
销售
运输损耗
1
决策层: 问题的解决 机会的创造
2
子系统事件级 业务域切分 事件梳理
3
构件图 | 层次图 上下文关系图
管理层: 管理效益
事件活动级 流程定义 流程优化
活动图 | DFD 0 跨职能流程图
执行层: 效率、质量、便利
活动步骤级 工作规程
用例图 | DFD n
分析是本质，建模是工具
1
先确定要描述什么再选择适合模型
并行、异步支持差
技术类系统更常用
现场出图：流程分析加速器
客户代表陈述
需求模板内容要点
业务需求 愿景 / 目标分析
业务分析 主题域分解
需求细节 业务功能描述
补充需求 全局质量属性
干系人关注点
项目背景
事件描述
管控点描述
报表描述
接口描述
设计约束
项目级约束
场景 / 报表项
领域模型
数据需求描述
UI 描述
需求模板内容要点
预期读者
给谁看，看什么？
定义
参考文献
针对本文档，避免混淆
• 打通业务工程与需求工程 之间的鸿沟 • 完整覆盖需求工程
结构化分析(SA)
• 数据流为核心时代的产物 • 数据存储：E/R • 数据处理与流转：DFD • 以IPO为需求描述手段
面向对象分析(OOA)
• 顺应发展的主流方法
• 工作流：活动图
• 信息流：领域类图 • 强调人：用例图 • 无法完覆盖需求工程 • 使用者的技术背景会使其
识别事件上下文关系图
用矩形表示系统，写上名称，视为黑盒子 确定Customer(外部客户、主题域外的Worker)
逐一分析Customer触发的事件，带出Worker行为
逐一分析Worker主动触发的事件 最后考虑时间、状态触发的事件
上下文关系图示例
分局领导 效能办
4.二级 统计 1.业务申请 1.审批决定
无模型标准
结构化：IDEF
面向对象：UML
需求分解树
需求模板内容要点
愿景/可行性研 究报告
客户(用户)需求 说明书
软件需求规格 说明书
• 要点
三份文档可能独立，也可能打包在一起 愿景/可行性研究报告独立，是在执行之前充分分析 客户需求与软件需求的分离，通常是因为编写人不相同 愿景/可行性研究报告针对管理层，黑盒视角写作 客户需求说明书灰盒视角写作，过渡性文档，取决于编写人 软件需求规格说明书不仅针对开发，还针对客户，是契约，可灰盒+白盒
别成为模型流派的“忠诚”拥护者 若不知某模型元素有何用就忘记它 模型无适用阶段，只有适用场合 建模工具不重要，建模方法是要点
2
3
4
5
UML vs. IDEF
建模方法发展史
算法为中心
程序流程图
数据为中心
数据存储：E/R图 数据加工与流转：DFD图
多维角度
物(数据)：类图 事(行为)：活动图 交互图 人(角色/场景)：用例图 ……
工具和产物
需求分析全局观 无专门方法 技术驱动
程序=数据结构+算法
• 科学计算应用时代产物
• 程序员承担了需求 • 我们已经远离
半业务驱动
业务驱动
UI驱动
• 误以为UI就是需求
• 设计思想在主导需求 • 经常系统形似神不似
用例驱动
• 系统外的用户视角
• 带来了业务视角 • 应用误区太多以至失效
SERU方法体系