有效需求分析

引导篇

第零章 软件需求全景图

0.1业务驱动的需求思想

 0.1.1方案非需求

传统的需求分析是站在技术角度，关注“方案级需求”，现在的需求分析更加关注“问题级需求”。

0.1.2变更/优化型需求分析任务执行指引

（1）澄清问题

（2）了解背景

（3）建议并确定解决方案

 

 

图0-1  变更/优化型需求分析任务执行指引

★关于进一步的需求挖掘，只挖掘问题，不挖掘方案

0.1.3变更/优化型需求分析任务产物

变更/优化型需求分析模板～～

0.2组织应用类软件系统需求全景图

组织应用类软件系统需求分为价值需求&详细需求。

价值需求主线包括：目标场景&干系人关注点、阻力点

详细需求主线包括：行为需求、数据需求、非功能需求

 

 

图0-2 组织应用类软件系统需求全景图

0.3价值需求主线

价值需求的三个本质问题：

1.整个软件系统为客户解决了什么问题、创造了什么机会

2.对于系统而言，最关键的干系人有哪些？

3.各个重要干系人对系统的关注点是什么？

所以，价值需求分析的关键是在于执行好   目标分析、干系人识别、干系人分析三个任务。将会产出的成果物是：多份《问题卡片》，场景化定义项目目标；一张《干系人列表》，列出所有关键干系人；多份《干系人档案》，针对每个关键干系人整理响应的关注点和阻力点。

 

 

 

图0-3 价值需求主线的”任务—产物“示意图

0.4详细需求

从灰盒子角度完成三个问题的分析：“为了给客户提供业务、管理、维护支持，需要提供哪些功能？“  （功能需求）

”系统所涉及的问题域中有哪些数据，之间是何关系？“（数据需求）

”所处的业务环境会带来哪些约束和质量要求？"(非功能需求)

0.4.1子问题域分解

 

 

图0-4 子问题域分解的”任务—产物“示意图

系统分解模型可以选用层次图、构件图、数据流图等图表来呈现分解结果。子问题域分解任务就是从灰盒子视角回答“系统涉及哪些子问题域，他们之间有什么关系？”

当完成子问题域分解任务之后，还需要执行业务接口分析这一任务，定义各子问题域的业务接口，说明这些接口的用途、谁实现、谁使用等细节。

0.4.2 功能主线

有人按照白盒子思维，就是技术驱动、有人按照业务用例->系统用例，有人让客户说出“作为...希望系统实现...以便...”

但是可以换个角度，理清系统中的所有功能是因为什么而存在的，主要是以下三个角度。

1.业务支持

典型的三类：

（1）通过系统固化、优化业务流程----提升流程执行效率、节约成本、降低风险。

（2）通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上。

（3）通过系统将个人能力、知识转化为组织能力、知识。（注意专家场景）

从灰盒子视角回答——根据目标和干系人的关注点，系统需要涉及哪些业务流程？

——这些业务流程是如何定义的，需要优化吗？
——系统对业务流程中所有场景都要支持吗？还是只支持一部分？
——有哪些业务场景的工作经验需要模型化？

 

图0-5 业务支持需求分析的“任务--产物”示意图    这一块要再好好看看，没看明白？？？？？

2.管理支持

主要的三方面：

（1）事前风险避免，通过增加管理流程

（2）事中风险控制，通过“规则”和“审批”

（3）时候总结优化，通过“数据分析”

从灰盒子视角回答——管理层用户希望通过系统实现哪些管理、控制需求？

——希望通过系统做哪些辅助决策？

——要实现这些管理、控制、决策支持需要哪些信息？用什么方法获取它们？

待补充

 

图0-6管理支持需求分析的“任务--产物”示意图

 

3.维护支持

待补充

 

价值需求篇

第一章 目标/愿景分析

1.1任务执行指引

 

 

图1-1 目标/愿景分析任务指引

1.2知识准备

执行好目标分析任务，要理解三个知识点：需求=预期-现状；问题和机会就是目标；目标的三种描述方式

1.2.1 需求=预期-现状

当预期与现状对比时，出现不同的结果，会影响用户对我们需求调研时的态度，当态度消极时，需要我们提出新预期，让用户进入”预期高于现状“的状态，从而积极的参与需求调研。

1.2.2 问题和机会就是目标

问题场景、机会场景目标分析都是针对项目发起人、出资人、项目属主。

1.2.3 目标的三种描述方式

1.定性描述：从总体趋势、属性、宏观的角度来表达，指出一个模糊的方向，无法有效地界定系统的范围。

2.定量描述：依据smart原则：specific具体的、measurable可衡量的、attainable可实现的、relevant有相关性的、time-based有时限性的

3.场景化描述：

 1.3任务执行要点

目标分析可以分为以下步骤进行：

（1）访谈问题：通过对项目关键干系人的访谈，识别预期与现状的差距。

（2）研讨机会

（3）定义问题/机会

（4）分析问题并确定解决方案

1.3.1访谈问题

 

 

 

图1-4访谈问题的典型策略

1.外因触发项目

最常见的触发项目的外因包括：参观考察、竞争对手动向、热点及新技术趋势。

（1）触因：参观考察——策略：分享收获

（2）触因：竞争对手动向——策略：竞品分析

（3）触因：热点及新技术趋势——策略：分享理解

2.内部触发项目

表象原因决策提问法：还原表象、分享原因、共商对策三个提问步骤

当我们面对多元线索的大问题时，可以使用分而治之提问法——可以按照职能、产品服务、工作主题进行分解。

1.3.2研讨机会

1.新业务——自己理解：不是创造新的业务、工作流程，而是创新一些机制、方式，不是把1变成2，而是把1处理成十个0.1

（1）追标杆：标杆是指某个特定领域  商业模式  最领先的 公司

（2）赛同行：看前面的同行

（3）借他业：行业和行业之间是相互融合的

2.新技术

3.新人群

1.3.3定义问题/机会

1.描述问题

（1）业务态——是指从业务的角度阐述问题和机会，而不是从系统的角度阐述。        高管关注”问题、机会、成本、效益“

（2）客观性——讲事实，客观数据

（3）匹配性——项目的目标、愿景都是针对高管层，所以要关注管理层的视角问题。高管层最关注经营层面的问题，其次涉及到管理模式、业务模式的宏观管理问题。因此千万不要把操作层遇到的非共性问题列为分析目标。

2.分析影响

（1）指代清晰，具体到人

（2）视角匹配，影响明确——主要是从高管管理层的角度出发，完成目标场景（包括问题场景、机会场景）的描述

（3）推理合理，层次清晰——这个需要经验了，多向他人请教

1.3.4分析问题并确定解决方案

1.分析问题

（1）鱼骨图法——当认为问题是由一系列子问题构成的，可以用这个方法分解问题

（2）问题现状树法——认为问题是由一系列因果关系产生的。参考《高德拉特问题解决法》

（3）系统思考法——认为问题是由一系列因果关系产生，并且包含促进因和阻碍因两种。

2.明确解决方案策略

在描述方案时，从宏观角度说明，并且强调具体策略。

3.提炼”一句话目标“

要点在于业务态、价值态，以”措施+效果“的结构描述。

1.4任务产物

1.4.1问题卡片模板

 

详见word文档

1.5剪裁说明

有时候我们遇到的是项目是问题、前景明确的，这时候就不用花时间进行目标/愿景分析了。目标/愿景分析是项目的方向和灵魂，对这项任务的分工和花费时间要慎重。

第二章 干系人识别

识别出关键干系人很重要。

2.1任务执行指引

 

 

图2-1干系人人物识别任务指引

2.2知识准备

stakeholder  注意到项目是一个博弈的活动，需要折中和平衡，这时找到关键核心持码人，就能获得项目的成功。

2.3任务执行要点

2.3.1根据目标识别关键干系人

执行该步骤时，先收集客户的组织机构，再根据目标、愿景判断。

步骤一：标识涉及的部门

步骤二：将部门负责人标识为关键干系人

步骤三：将分支机构负责人标识为关键干系人

步骤四：将涉及部门或分支机构存在资深的副职负责人标识为关键干系人

注意：实际项目中，大家会受到干系人影响度的干扰，比如职位等，但是忽略了他与项目的相关度，从而错误识别了关键干系人。

 2.3.2根据风险识别其他关键干系人

1.众多基层受影响——一般不会把基层用户作为关键干系人。这时可以采用很多方法，比如提前管理预期，让基层关键干系人在系统上线前降低预期，再创造上线后的部分超预期~

2.一票否决的担忧

3.实现存在高风险——比如系统生命周期很长，运维工作十分重要，那运维也是关键干系人

2.4任务产物

2.4.1干系人列表模板

2.5裁剪说明

干系人识别一般不宜被裁剪。

第三章干系人分析

3.1任务执行指引

 

 

 

图3-1 干系人分析任务指引

3.2知识准备

干系人负需求：对项目干系人会带来的负面影响。

做干系人分析的时候，要从正、负方面考虑。

3.3任务执行要点

三个步骤：

（1）选择干系人代表——多位干系人时，要选择一位或者多位典型的代表，以便聚焦。

（2）访谈干系人——

（3）干系人关注点整理——

3.3.1选择干系人代表

1.优选代表：注意代表性、典型性     啥区别？？怎么分辨？？

2.了解基本信息：职业角色（在组织机构中的职位&关键工作职责）、个人特点（专业背景&职业经历）、联络信息（联络方式、工作时间、沟通方式偏好等）

3.3.2访谈干系人，分析关注点

1.访谈干系人

访谈之前，根据“分而治之提问法”策略法，制定访谈提纲，列出访谈的内容树。

（1）基于KPI分解——

（2）基于工作主题分解——

（3）基于工作阶段分解——

实际的时候需要组合使用以上分解方法。

2.分析关注点

在干系人关注点分析时，要从两个角度出发：——他们希望系统解决什么问题、提供什么业务支持   ——他们希望系统避免出现什么样的负面影响

在描述分析结果时，要包括两部分：——干系人关注点/阻力点（why）——功能需求（how）

在写why的时候，要把握三点：——从业务角度出发——以结果的态度写——必须体现价值？？？？？

3.3.3干系人关注点整理

不同干系人关注点之间会产生冲突，需要识别冲突，并提出解决方案。

3.4任务产物

3.4.1干系人档案模板

3.4.2干系人档案示例

3.5剪裁说明

干系人分析是干系人识别的延续，一般不可以剪裁。但干系人相对少，关注点、阻力点简单明确，可以剪裁掉《干系人档案》，直接在干系人列表中写明关注点/阻力点。

系统分解篇

第四章 业务子系统划分

待开发的系统有时相当复杂，为了控制分析的复杂度，通常需要分解成更小的部分，这可以根据实现结构来分解，但是在需求阶段更推荐根据业务来划分。

4.1任务执行指引

 

 

图4-1业务子系统划分任务指引

4.2知识准备

业务视角划分vs技术视角划分

技术角度来组织需求分析文档，难以建立全局观。

4.3任务执行要点

以下三个步骤：

第一步：划分业务子系统——根据系统特点，选择合适的划分策略进行分解

第二步：标识接口、确定关系——哪里有分解，哪里就有接口。分解完成之后，必须明确各子系统之间的服务接口。

第三步：呈现业务子系统划分——根据实际情况选择合适的图表来呈现划分的结果。这里的图表不仅仅限接口文档。

4.3.1划分业务子系统

将复杂分解简单～～

 

 

图4-2划分子业务系统的典型策略

1.按业务智能划分

典型的部门职能：产、销、供、管

2.按产品/服务分解

通常在开发“外部服务系统”时，我们可以先梳理出“业务结构树”，然后以不同的产品/服务作为划分线索。有时，某些“内部管理系统”中也采用这种角度划分。

3.双维度划分

很复杂的系统要业务职能划分&产品/服务划分进行结合

4.按关键特性分解

待开发的系统是“计算机领域”的主题时，要按关键特性分解，比如安防系统，要从传感器系统、报警系统、视频系统等等。

5.分析对遗留系统影响

基于对原系统的改造和升级时，可以直接分析：新增那些子系统、修改哪些子系统（源码级）、影响哪些子系统（只需要通过配置、加接口实现）即可。

4.3.2标识接口、确定关系

哪里有分解那里就有接口

 

 

 

图4-5 标识接口、确定关系的典型思考点

4.3.3呈现业务子系统划分

 

 

图4-6呈现业务子系统划分的主要方法

（1）层次图——强调纵向分解

（2）构件图——存在横向行为、服务、调用关系需要呈现出来。注意构件图常用的四个元素：业务子系统、业务子系统之间的服务关系、服务提供方、服务使用方

（3）数据流图——推荐使用IDEF中定义的数据流图实现。

4.4任务产物

4.4.1业务子系统划分模板

4.4.2业务子系统划分示例

4.5裁剪说明