课程背景

本课程以workshop工作坊方式，着重讲解需求分析人员应该具备的两种视角：“站在全系统的高度看待人们需要用本系统解决什么问题”，以及“站在I/O的角度看待某一条具体的需求条目”。前者我们一般简称为“why to do”，后者我们一般简称为“what to do”。并且，显然，前者对后者是制约关系。

一般的，在信息系统的建设过程中，“需求分析”过程将依次完成如下的工作——

原始需求（Needs，又称“需要”）的调研与挖掘，即：需求开发（RequirementElicitation）工作；

从原始需求向IT系统整体业务需求转化，即：商业分析（BusinessAnalysis）工作；

以上两个部分从整体上理解系统/产品待解决的问题、待交付的价值，解决系统/产品“Whyto Do”的问题

对业务需求的“用户场景级”分析，即：业务需求分析（BusinessRequirementAnalysis）工作

业务需求转化为软件需求，即：需求规格化（RequirementSpecification）工作；

以上两个部分从细节上理解系统/产品具体的需求条目，解决系统/产品“Whatto Do”的问题

需求的验证与确认；

以及，在上述所有工作中，有关需求变更控制的相关工作。

课程说明

本课程方案全程采用Workshop工作坊方式组织实施，即：受训学员将被分为若干小组，每个小组使用同一个项目场景顺序完成4个实战演练，内容涵盖上述3大领域。

课程特点

强烈建议直接采用贵公司的实际存在的信息系统建设项目（已完成的或者正在进行的）作为学员分组演练案例，以提升学员“身临其境”的体验。另外，课程中所有用于讲解的案例都将根据贵公司的业务领域特点、过程体系与产品研发生命周期进行定制化。

课程对象

产品经理、需求分析人员（含业务分析人员）、高级设计人与开发员、高级测试工程师。

课程大纲

第一天

Module 1概述：需求开发与需求管理管理的“Yes”与“No”

角色扮演游戏

• 过程：讲师扮演客户，学员（分组）扮演需求调研人员，模拟需求开发过程。

• 讲评：通过演练来认识“靠谱的需求从哪里来”的命题，认识需求开发与需求管理的常见误区——边界不清晰、缺少可视化监控手段以及无限制拔高用户对系统的期望值 ……

• 需求开发与需求分析过程中的常见问题

• 需求开发与需求管理过程中要完成的蜕变——从“把事做正确”到“做正确的事”

• 做好需求分析的第一要务——我们交付的是系统的价值，而非软件本身

• 需求分析的BBR模型，同时也是各个相关方干系人对于一个软件系统的最高要求——“帮忙不惹事”

• 案例剖析

•  “桌面以上的需求/明确表明的需求”Vs.“桌面以下的需求/隐含的需求”——重点关注哪些没有被讲出来的需求

• 需求开发与需求管理中的3个基本问题

  
  

Module 2打开需求的黑匣子

• Attention! 我们说的可是“需求”—— “需求”基本概念、各类“需求”的定义（功能需求、非功能需求/质量属性、设计约束的定义）和各个层级的需求（用户需求/业务需求、产品需求与产品组件需求）

• 需求开发和需求管理在软件研发过程中的位置和地位、需求开发和需求管理与软件研发流程其他环节（例如：系统测试、架构设计……等）的关联关系

• 现实总不如看起来那么美好之1——需求开发和需求管理过程中的两大常态：1）“用户讲不清楚需求”和2）“需求总是处于变更当中”

• 现实总不如看起来那么美好之2——你从用户/市场/业务部门同事那里接收过来的“需求”（原始需求）通常存在哪些问题：

1. “业务流程”与“系统流程”的边界不清晰

2. “用户期望”与“系统功能”“的边界不清晰

3. 只有“系统能做什么”，没有“系统做的有多好”

4. 最容易被忽略的一类用户——Administrator

• 三种不同详细程度的“需求”：白云级需求、风筝级需求和场景级需求

• 你准备好了吗——作为需求分析人员，在一个项目的需求开发和需求管理过程中你将承担怎样的角色与职责？

• 你能讲的清楚吗，你自己项目的“独特性”特征是什么？

• 你能讲的清楚吗，你自己项目的“目标”是什么？或者仅仅只以一句“按时保质的完成任务”作为搪塞，并不清楚或者没有关注到自己的项目会给客户带来的价值？

Module 3捕捉和挖掘需求

• 决定捕捉需求策略的三大要素——客户/用户参与程度、需求分析人员的熟练程度、技术性约束条件

• 我们交付的是“价值”而非“项目”本身——如何从孤立的用户需求中判断系统整体上的“交付价值”

• 诺兰模型永放光芒——如何有效的引导和限制用户的“期望值”

• 需求挖掘技术哪家强？实际案例展示——有效的需求捕捉与无效的需求捕捉正反案例介绍与剖析

分组演练1：各分组根据选定的项目场景，分析项目的相关方，并据此制定1份需求开发计划，明确：

1. 项目有哪些相关方，他们各自的诉求是什么；

2. 定义向每一个相关方考查的问题重点/维度，并确定考察方式；

3. 用一句话概括总结项目的“建设目标（暨交付价值）”

【特别企划】：演练中可以使用贵公司自己的实际项目作为演练场景。

• 捕捉需求的热身活动：需求调研计划与需求调研提纲（含案例分享）

• 需求开发的方法之1：访谈

• 需求开发的方法之2：业务逻辑捕捉

• 需求开发的方法之3：联合需求工作会议

分组演练2：使用演练1的成果，识别案例中需求不明确或者缺失的部分，并据此制定需求调研提纲与问题列表

------------------------------第一天内容结束----------------------

第二天

Module 4 需求的分析（上）

• 需求分析的基本原则：问题的识别、评估、平衡和综合

• 分析功能性需求的三种工具之1

• 早期需求分析的神器——用户故事（User Story）与用户故事地图（User Story Mapping）

• 讲得清楚每条需求“以便于给用户带来怎样的价值”是用户故事方法最神奇的地方

• 使用用户故事地图来勾勒需求全貌

• 正反案例介绍与剖析：用户故事描述“风筝级”需求的实例

分组演练之3：使用“用户故事地图”方法划分系统的逻辑结构，然后使用“用户故事” 方法分析演练项目场景中由讲师指定的5项需求

Module 5 需求的分析（下）

• 分析功能性需求的三种工具之2

场景级需求的分析神器——用户用例（UseCase）

UseCase所带来的“如来神掌”效应：区分“系统”与“用户”的边界

正反案例介绍与剖析：用户用例描述“场景级”需求的实例

分组演练之4：使用“用户用例”方法分析演练中由讲师指定项目场景的3项需求

• 分析功能性需求的三种工具之3

当“谁也讲不清楚系统的需求”时使用的分析神器——原型法

原型法最关键的地方——你需要哪一部分的原型？

原型法的“需求评估”环节如何操作？

• 分析非功能性需求的“八元方法”——从8个维度分析非功能性需求

需求的平衡

使用Kano模型判断需求的优先级

使用“二叉树”方法设定需求的优先级

Module 6需求建模与需求规格化

• 需求建模——使用符号化语言动态的描述需求

需求建模的方法之一：过程流

需求建模的方法之二：数据流图

需求建模的方法之三：实体－关系图

• 需求规格化——使用自然语言动态的描述需求

两种模式的需求规格说明书文档的样例——IRF（界面原型-业务规则-业务流程）和UseCase（用户用例）

需求的命名规则

“好”的和“不好”的需求描述样例剖析

Module7本次培训总结及答疑

为何放弃治疗——为什么不愿意把需求写清楚？

让我们一起把把脉吧——如何在贵公司有效开展需求开发与需求分析活动