有效需求分析（前10章）
前言
需求分析思想：
需求分析最重要的是思维方式，要站在用户的视角展开，即“业务驱动”思想，关注问题而非方案。
以变更/优化型需求为例，针对用户提出的需求，首先要判断是方案（直接告诉你做什么）还是问题（告诉你他实际想解决的问题）。第一步就是澄清问题，2W1H，明确谁的，什么问题，并知道遇到该问题当事人目前是怎样解决的，若有概念的不确定，需明确；第二步了解该需求具体的使用情况，2W1H（谁，什么时候，怎样做），业务术语澄清，并了解该需求的使用频率及满足不了的后果，涉及到哪些人；第三步，提出建议，分别列出可行方案，成本比较，提出建议，对用户而言的优缺点等，并可简单问一下有无其它类似需求。
第1章 目标/愿景分析
首先说明预期高于现状才会产生需求；进而在预期与现状的差距中寻找问题和机会以确定目标；并提示在目标描述时应避免空洞无物、无法验证，可以采用场景化描述法，将目标真实、易理解、可验证、有感染力的描述出来。 接下来以具体案例说明如何分析目标，访谈问题、研讨机会、定义问题和机会、分析问题并确定解决方案，每个步骤都提供了具体步骤和方法。 最后以问题卡片的形式，指导大家如何进行实际操作，非常实用。
第2章 干系人识别
干系人是项目中涉及到的所有人，而我们在做需求分析时需要识别出关键干系人。
首先，根据目标识别关键干系人，可通过客户的组织架构去分析，在该过程中需要注意的是，干系人的影响度和与项目相关度要综合权衡，来正确识别关键干系人，从而正确认识需求的优先级。
其次，根据风险识别其他关键干系人，比如基层用户、具有一票否决权的专家、研发人员等根据具体风险，都有可能成为关键干系人，但绝不是关键干系人越多越好。在涉及基层用户时，可以采用“预期管理”策略，上线前降低预期，创造上线后部分超预期的效果；在有专家参与时，若因专家的过度参与使项目受阻，需要从专家的关键需求入手，做充分沟通，找到双赢的解决方案。
最后，生成干系人列表。
第3章 干系人分析
识别出关键干系人之后，接下来就要选择合适的代表进行调研，分析他们的关注点、阻力点，以及满足关注点、避免阻力点所需的功能、非功能需求。而阻力点，也就是对干系人带来的负面影响，很容易别人忽略。
首先，选择干系人代表，要具有代表性（能够覆盖各种差异的干系人）和典型性（能代表比较大比例的同类干系人），从职业角色（组织中的位置和核心工作职责）、个人特点（专业背景、职业经历，以了解其管理偏好、思考逻辑等）、联络信息（联络方式、工作时间、沟通方式偏好，以便选择最合适的沟通时间和形式）三方面了解信息。
其次，访谈干系人，分析关注点。采用“分而治之提问法”制定出访谈提纲，列出要访谈内容。可以基于KPI、工作主题、工作阶段三种角度进行分解。同时在分析关注点时，不仅要关注干系人希望通过系统解决的问题，还要关注系统可能给其带来的负面影响，描述分析结果时，从why（关注点/担心点）、how（功能需求）两个方面来描述。令外在写why时，要把握三个写作要点：一是从业务角度写，二是要以结果态写，三是必须体现价值。
最后，干系人关注点整理。有时干系人的关注点存在冲突，我们需要识别冲突并提出解决方案。并建立“干系人档案”。
第4章 业务子系统划分
对于比较复杂的系统，为了控制业务分析的复杂度，通常要对系统划分为各个子系统。在划分过程中我们要跳出技术实现角度划分的思维定式，从业务角度进行划分，才能更好的与用户沟通，提升用户的参与度。
首先，根据系统特点，选择合适策略，进行业务子系统的划分。相对复杂的新系统，可选择业务/职能分解（内部管理系统）、产品/服务分解（外部服务系统）、双维度划分（复杂业务系统）、关键特性划分（计算机域系统）等不同方式；业务简单，用户群单一的无需划分；原系统基础上做二次开发的，明确新增哪些子系统，对原有子系统的影响，原有子系统需做何修改即可。记住划分不是目的，而是手段。
其次，标识接口，确定关系。所谓“哪里有分解，哪里就有接口”，在已划分子系统的基础上，明确本子系统需要其它子系统提供什么服务；能够提供给其它子系统什么服务；这些服务谁提供，谁使用；哪些是现有的，哪些需修改，哪些需开发等。
再次，通过层次图（强调纵向分解）、构件图（强调横向功能，服务调用关系）、数据流图（强调横向数据交换、共享关系）等，将各子系统及之间的关系呈现出来。
最后，通过文档将分析结果记录下来。
第5章 业务接口分析
所谓“哪里有拆解，哪里就有接口”，划分完子系统之后，就要对彼此间的服务关系（业务接口）进行分析。进入正题之前，先区分两个概念：业务接口和系统接口。这是不同的概念，一个业务接口可以由多个系统接口实现；内容不同，业务接口分析，只明确why（用途与业务价值）、what（交互过程）及约束，不涉及how（解决方案）。业务接口分析步骤如下：
首先，明确接口的用途与业务价值。需厘清三个问题：
1.哪个子系统合适实现该接口；
2.哪些子系统会用，实现什么价值；
3.使用频率是怎么样的。
其次，细化接口的交互过程。在该过程中，会用到两种工具，一是时序图，呈现出接口的交互过程，二是数据词典，细化的定义出每次交互过程中数据包的构成情况。
接下来，确定接口设计约束。首先看客户的技术管理部门是否要求使用特定的数据，通信协议，或者遗留系统带来的限制；其次对数据传输、数据查询，加解密方面的性能要求进行分析，除此之外，还应考虑系统的部署环境，使用者特点等带来的设计约束。
最后，形成记录文档。
第6章 业务流程识别
企业或组织的核心价值在于相应外部客户的服务请求，通过一系列的写作来满足服务请求，为客户带来价值，同时为企业或组织带来价值。也就是说业务流程的起点是这些外部服务请求。
6.1 端到端流程
- 完整：所谓端到端，实际就是服务请求从提出到满足的全过程，也就是判断一个流程是否完整，应该站在服务请求的立场，判断服务请求是否满足或者被拒绝。
- 边界：识别业务流程时涉及两种边界。一是职能边界，也就是跨越了我们未涉及的业务领域；二是系统边界，也就是不属于系统关注的部分。
第7章 业务流程分析优化
做好业务流程分析，首先要了解两个方法：
7.1 分层业务流程
业务流程正常可以分为三层，第一层组织级流程，描述部门间的关系，供决策者阅读；第二层是部门级流程，岗位间协作关系，供管理层阅读；第三层是个人级流程，描述一个岗位的工作步骤。判断原则有两个：一是 是否与协作无关；二是 是否不是独立可汇报的单元。
7.2 业务流程八要素
五个基本要素：分工、活动、协作、产物关系、分支
三个管理要素：审核、规则、异常
第8章 业务场景识别
识别业务场景，目的是让用户产生共鸣，实现“用户为中心”的需求获取与理解，具体技术表现为用例和用户故事。
用例即业务场景、使用场景，比如同样是增删改查，不同的用户就会有不同的使用场景，比如图书管理员需要新增图书时可能有两种情况：办理图书入库、办理遗失图书返库，那我们如果简单定义成新增图书就不如定义成办理图书入库、办理遗失图书返库更容易被使用者接受。
用例也是有边界的，那么多大才算是合适的用例呢？我们把这个边界称为粒度。实际上一个用例就是一个完整的业务场景，应该是独立的、可汇报的、可暂停的单元。在一个信息系统中，业务流程是指不同岗位之间通过协作满足外部服务请求的过程；而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动。因此，从某个角度而言，粒度是由组织分工决定的。
用户故事，就是让用户或用户代表使用固定格式描述其需求，具体格式为：“作为xxx（角色），希望通过系统xxx（解决方案、功能要求），以便达成xxx业务目的、要解决的业务问题”。如果用户故事过大，还需要明确粒度的标准，对故事进行拆分。
第9章 业务场景分析
识别出业务场景后，接下来就是进行场景分析。
先站在用户的角度，对场景进行描述；
然后采用“场景——挑战——方案”的过程进行分析。
一般先从用户视角将场景进行细化，形成事件流，然后站在用户角度逐条分析会遇到哪些问题，最后针对问题，寻找解决方案。
第10章 管控点识别与分析
信息系统的核心价值之一是支持管理，而管理支持的核心是通过管理流程事前规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化。
在数据分析过程中，首先要明确“数据≠信息”，分析数据后，不妨多问为什么，从而挖掘出用户所需要的信息，比如，大家查询当日天气情况，实际是想了解如何穿衣等等。判断数据的完整性，需要明确想要获得的信息具体是什么。
管控点识别即通过数据分析实现的管理意图。比如一个考勤系统，可以通过业务报表来继续挖掘用户的深层需求，比如统计员工迟到情况，其实是为了评估员工积极性，找到该管控点，然后再从积极性角度分析，还有哪些报表可以反应该管控点，可以就此问题与用户进行交流。
