课程简介
为了帮助需求分析人员以上问题有清晰的认识、完整的了解和全面的把握，我们“有效需求分析训练营”这门课程。本课程除了对“需求”的基本概念、“需求管理”的基本框架和目前主流的需求分析方法做出了明确阐述，更为重要的是，凭藉讲师在多种不同行业客户的成功经验（金融、电力、能源、通讯、物流、中间件……），本课程还将对业界优秀企业关于需求开发与需求管理方面的最佳实践进行深入的分享、分析和论述，使用“工作坊”的形式以重点关注学员在可操作性能力方面的提升。
目标收益
- 分析业界公司在需求管理和需求开发过程中的误区，并分享成功经验；
- 站在“项目交付价值”的全新角度了解在需求开发和需求分析的过程、以及在这个过程中各种技术和方法论的使用特点；
- 理解需求捕捉时的主要方法：用户故事、业务概念分析、最小原型法；
- 理解需求分析/需求建模的主流方法：User Story 用户故事、UseCase用户用例、数据流图、有限状态集图、实体/关系图……；
- 理解非功能性的分类、示例以及如何获取的方法；
- 掌握规格化需求时的注意事项与模板示例；
- 了解需求评审时的3种常用的方法：正规检视、同行专家评审与走查；
- 了解需求变更控制的流程、要素与注意
培训对象
项目经理及项目管理（PMO）人员、需求分析人员、高级开发与设计人员、高级测试工程师
课程大纲
| Module 0概述：需求开发与需求管理管理的“Yes”与“No” |
➢ 需求开发与需求管理过程中的常见问题 热身联系：角色扮演游戏 过程：讲师扮演客户，学员（分组）扮演需求调研人员，模拟需求开发过程。目的是：1）热身以及2）团队融冰 讲评：通过演练来认识“靠谱的需求从哪里来”的命题，认识需求开发与需求管理的常见误区——边界不清晰、缺少可视化监控手段以及无限制拔高用户对系统的期望值 …… ➢ 软件项目的“魔鬼数字” 关于软件项目已经被证明行之有效的、被广加利用的一些经验数据，例如： 需求分析和需求开发活动的工作量占比至少应该达到多少？ 工具对于效率提升的极限可以达到多少？ 极端情况下进度最多可以被压缩多少…… ➢ 一个不是问题的问题——谁该来写需求？研发？业务？产品？ 案例剖析：“IT引领业务”的A银行信息科技部 Vs.“IT支撑该业务”的B银行信息科技部 “做正确的事” Vs.“把事做正确”——需求开发与需求管理过程中完成的蜕变 做好需求分析的第一要务——我们交付的是价值，而非产品本身 案例剖析 “桌面以上的交付价值”Vs.“桌面以下的交付价值”——哪些没有被讲出来的需求 案例剖析之一：化繁就简 案例陋习之二：去简就繁 需求开发与需求管理中的3个基本问题和3个拓展问题 小结：需求开发与需求管理是一个公司的核心竞争力 |
| Module 1打开需求的黑匣子 |
➢ Attention! 我们说的可是“需求”—— “需求”基本概念、各类“需求”的定义（功能需求、非功能需求/质量属性、设计约束的定义）和各个层级的需求（用户需求/业务需求、产品需求与产品组件需求） ➢ 现实总不如看起来那么美好之1——需求开发和需求管理的两大常态：1）“用户讲不清楚需求”和2）“需求总是处于变更当中” ➢ 现实总不如看起来那么美好之2——你所接收从用户/市场人员/业务人员转发过来的需求通常存在哪些问题： “业务流程”与“系统流程”的边界不清晰 “用户期望”与“系统功能”“的边界不清晰 只有“系统能做什么”，没有“系统做的有多好” 最容易被忽略的一类用户——Administrator ➢ 三种不同详细程度的“需求”：白云级需求、风筝级需求和场景级需求 ➢ 你准备好了吗——作为需求分析人员，在需求开发和需求管理过程中你将承担怎样的角色与职责？ 你能讲的清楚吗，你自己项目的“独特性”特征是什么？ 你能讲的清楚吗，你自己项目的“目标”是什么？或者仅仅只以一句“按时保质的完成任务”作为搪塞，并不清楚或者没有关注到自己的项目会给客户带来的价值？ |
| Module 2 捕捉和挖掘需求 |
➢ 决定捕捉需求策略的三大要素——客户/用户参与程度、需求分析人员的熟练程度、技术性约束条件 ➢ 真的需要“倾听每一个客户的声音”吗——客户的“痒点”和“痛点”是什么、我的系统/产品将解决他/她的什么问题 ➢ 我们交付的是“价值”而非“项目”本身——如何从孤立的用户需求中判断系统的“交付价值” ➢ 诺兰模型永放光芒——如何有效的引导和限制用户的“期望值” ➢ 挖掘需求技术哪家强？实际案例展示——有效的需求捕捉与无效的需求捕捉正反案例介绍与剖析 分组演练之1：各小组分析演练场景的内容，识别各自的相关方及其关注点，并且用“一句话”总结本项目的交付价值 【特别企划】：演练中可以使用贵公司自己的实际项目作为演练场景。 ➢ 捕捉需求的热身活动：需求调研计划与需求调研提纲（含案例分享） ➢ 需求开发的方法之1：访谈 ➢ 需求开发的方法之2：业务逻辑捕捉 ➢ 需求开发的方法之3：联合需求工作会议 分组演练2：使用演练1的成果，识别案例中需求不明确或者缺失的部分，并据此制定需求调研提纲和问题列表 |
| Module 3 需求的分析 |
➢ 需求分析的基本原则：问题的识别、评估、平衡和综合 ➢ 分析功能性需求的三种工具之1 早期需求分析的神器——用户故事（User Story） 讲得清楚每条需求“以便于给用户带来怎样的价值”是用户故事方法最神奇的地方 正反案例介绍与剖析：用户故事描述“风筝级”需求的实例 分组演练之3：使用“用户故事” 方法分析演练项目场景的5项需求 ➢ 分析功能性需求的三种工具之2 场景级需求的分析神器——用户用例（UseCase） UseCase所带来的“划一刀”效应：区分“系统”与“用户”的边界 正反案例介绍与剖析：用户用例描述“场景级”需求的实例 分组演练之4：使用“用户用例”方法分析演练项目场景的3项需求 ➢ 分析功能性需求的三种工具之3 当“谁也讲不清楚系统的需求”时使用的分析神器——原型法 原型法最关键的地方——你需要哪一部分的原型？ 原型法的“需求评估”环节如何操作？ ➢ 分析非功能性需求的“八元方法”——从8个维度分析非功能性需求 ➢ 需求的平衡与“二叉树”方法设定需求的优先级 |
| Module 4需求建模与需求规格化 |
➢ 需求建模——使用符号化语言动态的描述需求 需求建模的方法之一：数据流图 需求建模的方法之二：实体－关系图 需求建模的方法之三：状态迁移图 分组演练之5：使用“状态迁移图”完成演练项目场景的顶层建模，使用数据流图分析指定的需求。 ➢ 需求的规格化的基本原则 两种模式的需求规格说明书文档的样例——IRF（界面原型-业务规则-业务流程）和UseCase（用户用例） 需求的命名规则 “好”的和“不好”的需求描述样例剖析 分组演练之6：使用IRF方法撰写需求规格（含非功能需求） |
| Module 5需求的分解与跟踪 |
➢ 需求的分解——从用户需求/业务需求到产品需求，从“用户的视角”——>“产品的视角” ➢ 需求的跟踪的两种方法——需求跟踪矩阵、需求履历 ➢ 如何针对“增强开发模式”跟踪需求 ➢ 需求的横向跟踪的解决方案 ➢ 需求重用，以及“模式重用”的案例介绍与剖析 分组演练之7：根据第6个演练的成果，进一步使用使用IPO方法撰写产品需求规格说明书文档 |
| Module 6 需求的评审与确认 |
➢ 需求评审的方法介绍： 正规检视 同行专家评审 走查 ➢ 关于需求分析和需求管理的既往经验集成——需求评审检查单 分组演练之8：小组交换第7个演练的成果、使用“走查”方法评审对方的需求规格 |
| Module 7 管理需求变更 |
➢ 变更管理的流程 ➢ 变更管理的度量 |
| Module8 本次培训总结及答疑 |
➢ 为何放弃治疗——为什么不愿意把需求写清楚？ ➢ 让我们一起把把脉吧——在贵公司如何部署需求开发与需求管理活动 |
|
Module 0概述：需求开发与需求管理管理的“Yes”与“No” ➢ 需求开发与需求管理过程中的常见问题 热身联系：角色扮演游戏 过程：讲师扮演客户，学员（分组）扮演需求调研人员，模拟需求开发过程。目的是：1）热身以及2）团队融冰 讲评：通过演练来认识“靠谱的需求从哪里来”的命题，认识需求开发与需求管理的常见误区——边界不清晰、缺少可视化监控手段以及无限制拔高用户对系统的期望值 …… ➢ 软件项目的“魔鬼数字” 关于软件项目已经被证明行之有效的、被广加利用的一些经验数据，例如： 需求分析和需求开发活动的工作量占比至少应该达到多少？ 工具对于效率提升的极限可以达到多少？ 极端情况下进度最多可以被压缩多少…… ➢ 一个不是问题的问题——谁该来写需求？研发？业务？产品？ 案例剖析：“IT引领业务”的A银行信息科技部 Vs.“IT支撑该业务”的B银行信息科技部 “做正确的事” Vs.“把事做正确”——需求开发与需求管理过程中完成的蜕变 做好需求分析的第一要务——我们交付的是价值，而非产品本身 案例剖析 “桌面以上的交付价值”Vs.“桌面以下的交付价值”——哪些没有被讲出来的需求 案例剖析之一：化繁就简 案例陋习之二：去简就繁 需求开发与需求管理中的3个基本问题和3个拓展问题 小结：需求开发与需求管理是一个公司的核心竞争力 |
|
Module 1打开需求的黑匣子 ➢ Attention! 我们说的可是“需求”—— “需求”基本概念、各类“需求”的定义（功能需求、非功能需求/质量属性、设计约束的定义）和各个层级的需求（用户需求/业务需求、产品需求与产品组件需求） ➢ 现实总不如看起来那么美好之1——需求开发和需求管理的两大常态：1）“用户讲不清楚需求”和2）“需求总是处于变更当中” ➢ 现实总不如看起来那么美好之2——你所接收从用户/市场人员/业务人员转发过来的需求通常存在哪些问题： “业务流程”与“系统流程”的边界不清晰 “用户期望”与“系统功能”“的边界不清晰 只有“系统能做什么”，没有“系统做的有多好” 最容易被忽略的一类用户——Administrator ➢ 三种不同详细程度的“需求”：白云级需求、风筝级需求和场景级需求 ➢ 你准备好了吗——作为需求分析人员，在需求开发和需求管理过程中你将承担怎样的角色与职责？ 你能讲的清楚吗，你自己项目的“独特性”特征是什么？ 你能讲的清楚吗，你自己项目的“目标”是什么？或者仅仅只以一句“按时保质的完成任务”作为搪塞，并不清楚或者没有关注到自己的项目会给客户带来的价值？ |
|
Module 2 捕捉和挖掘需求 ➢ 决定捕捉需求策略的三大要素——客户/用户参与程度、需求分析人员的熟练程度、技术性约束条件 ➢ 真的需要“倾听每一个客户的声音”吗——客户的“痒点”和“痛点”是什么、我的系统/产品将解决他/她的什么问题 ➢ 我们交付的是“价值”而非“项目”本身——如何从孤立的用户需求中判断系统的“交付价值” ➢ 诺兰模型永放光芒——如何有效的引导和限制用户的“期望值” ➢ 挖掘需求技术哪家强？实际案例展示——有效的需求捕捉与无效的需求捕捉正反案例介绍与剖析 分组演练之1：各小组分析演练场景的内容，识别各自的相关方及其关注点，并且用“一句话”总结本项目的交付价值 【特别企划】：演练中可以使用贵公司自己的实际项目作为演练场景。 ➢ 捕捉需求的热身活动：需求调研计划与需求调研提纲（含案例分享） ➢ 需求开发的方法之1：访谈 ➢ 需求开发的方法之2：业务逻辑捕捉 ➢ 需求开发的方法之3：联合需求工作会议 分组演练2：使用演练1的成果，识别案例中需求不明确或者缺失的部分，并据此制定需求调研提纲和问题列表 |
|
Module 3 需求的分析 ➢ 需求分析的基本原则：问题的识别、评估、平衡和综合 ➢ 分析功能性需求的三种工具之1 早期需求分析的神器——用户故事（User Story） 讲得清楚每条需求“以便于给用户带来怎样的价值”是用户故事方法最神奇的地方 正反案例介绍与剖析：用户故事描述“风筝级”需求的实例 分组演练之3：使用“用户故事” 方法分析演练项目场景的5项需求 ➢ 分析功能性需求的三种工具之2 场景级需求的分析神器——用户用例（UseCase） UseCase所带来的“划一刀”效应：区分“系统”与“用户”的边界 正反案例介绍与剖析：用户用例描述“场景级”需求的实例 分组演练之4：使用“用户用例”方法分析演练项目场景的3项需求 ➢ 分析功能性需求的三种工具之3 当“谁也讲不清楚系统的需求”时使用的分析神器——原型法 原型法最关键的地方——你需要哪一部分的原型？ 原型法的“需求评估”环节如何操作？ ➢ 分析非功能性需求的“八元方法”——从8个维度分析非功能性需求 ➢ 需求的平衡与“二叉树”方法设定需求的优先级 |
|
Module 4需求建模与需求规格化 ➢ 需求建模——使用符号化语言动态的描述需求 需求建模的方法之一：数据流图 需求建模的方法之二：实体－关系图 需求建模的方法之三：状态迁移图 分组演练之5：使用“状态迁移图”完成演练项目场景的顶层建模，使用数据流图分析指定的需求。 ➢ 需求的规格化的基本原则 两种模式的需求规格说明书文档的样例——IRF（界面原型-业务规则-业务流程）和UseCase（用户用例） 需求的命名规则 “好”的和“不好”的需求描述样例剖析 分组演练之6：使用IRF方法撰写需求规格（含非功能需求） |
|
Module 5需求的分解与跟踪 ➢ 需求的分解——从用户需求/业务需求到产品需求，从“用户的视角”——>“产品的视角” ➢ 需求的跟踪的两种方法——需求跟踪矩阵、需求履历 ➢ 如何针对“增强开发模式”跟踪需求 ➢ 需求的横向跟踪的解决方案 ➢ 需求重用，以及“模式重用”的案例介绍与剖析 分组演练之7：根据第6个演练的成果，进一步使用使用IPO方法撰写产品需求规格说明书文档 |
|
Module 6 需求的评审与确认 ➢ 需求评审的方法介绍： 正规检视 同行专家评审 走查 ➢ 关于需求分析和需求管理的既往经验集成——需求评审检查单 分组演练之8：小组交换第7个演练的成果、使用“走查”方法评审对方的需求规格 |
|
Module 7 管理需求变更 ➢ 变更管理的流程 ➢ 变更管理的度量 |
|
Module8 本次培训总结及答疑 ➢ 为何放弃治疗——为什么不愿意把需求写清楚？ ➢ 让我们一起把把脉吧——在贵公司如何部署需求开发与需求管理活动 |
近期公开课推荐