引导篇
第零章 软件需求全景图
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中定义的数据流图实现。