本文是徐锋老师的《有效需求分析》读书笔记，旨在记录学习过程，沉淀知识。需求分析的关键思维是业务驱动，即关注问题级的需求而非方案级的需求。
回到工作中，我们经常可以遇到这样的场景。比如客户想要做一个根据一天中每一刻的派单量的曲线，进行智能派单的系统。于是常见的问题来了，
“XX先生你好，这个系统你想要怎样子做呢？”
“就是按照我说的，根据这条曲线来进行智能化的派单呀”
“那么，这个曲线怎么来呢，我们是做成给你自主绘制还是要填入数据生成……”
“我不懂这些，你只要给我做出来就行了。”客户已经不耐烦了。
在这个例子中，我们的需求人员一直揪着客户，问客户该怎么做这个系统。拜托，客户自己知道怎么做，还要我们干嘛？
“该怎么做”关注的就是方案级的需求，而我们更应该关注客户提出这个方案背后的问题级需求，探索这个需求背后的目的，对于业务的意义是什么，然后再以专业的视角来提供解决方案。
本文通过价值需求、系统分解、功能需求主线、数据需求主线、非功能需求主线和补充规则和约束等6个方面，以及18个需求分析关键任务，阐述需求分析工作的整体概况。
当慈是一个宝规则,贴垦失,靓现复杂时,浮避行规则分析补充内容。
一、价值需求
价值需求分析为软件系统的需求分析提供灵魂和方向，在做一个系统之前，需要搞清楚做这个系统的目标是什么，所面对的目标人群是谁，是用来解决什么问题的。
1.1 做什么（关键任务）
做价值需求分析可以从三个关键任务来解析，目标分析、干系人识别和干系人分析。
1.2 为什么做（目标）
通过这三个需求分析关键任务我们可以了解到
- 软件系统为客户解决来什么问题，创造了哪些机会。
- 对系统而言，最关键的干系人有哪些。
- 对于干系人而言，他们对系统对关注点有哪些，会有哪些方面对顾虑。
1.3 怎么做（步骤）
任务1:目标分析
访谈问题，获取项目来源：项目的来源，一般是外部因素的触发，或者内部提出，通过与项目干系人的访谈，了解预期目标和现状之间的差距，从而定义系统要解决的问题
研讨机会：通过对新业务、新技术和新人群的分析，探讨机会场景。
定义问题/机会：从业务的角度客观描述问题。第一步是通过业务态、客观性、匹配性描述清楚问题；第二步是分析问题影响了谁，带来了怎样的影响。
分析问题并确定解决方案。第一步是深入分析问题，找出问题的根本原因；第二步是明确提出有效的解决方案；第三步，以措施+效果的方式提炼目标。
最后，输出问题卡片。
任务2:干系人识别
根据目标识别关键干系人：首先需要收集客户的组织架构，在组织架构图上标识业务相关部门，将部门的负责人标识为关键干系人；其次，如果这些业务相关部门有分支机构，则将分支机构的负责人也标识成关键干系人；最后，若部门或者分支机构存在资深的副职人员，并具有一定的影响力，则也标识成关键干系人。
根据风险识别其他干系人：如果实施系统会让众多的基层受影响，则这些基层人员也需要标识成关键干系人；当遇到具有一票否决权的领域专家时，同样需要分析他的关键需求并将其标识为关键干系人；最后，当系统的技术实现难度很高、实施存在困难和风险，或者上线之后运营工作十分重要的，也需要将开发团队和运营维护团队标识成关键干系人。
最后，输出干系人列表。
任务3:干系人分析
选择干系人代表：在每一类的干系人当中，选出最具有代表性和典型性的干系人代表，了解其基本信息。
分析干系人需求：选择干系人代表之后，分指标、分主题、分阶段的对干系人进行访谈，并分析干系人的关注点。
干系人关注点整理：收集干系人对关注点。不同的干系人之间的关注点可能存在冲突，识别这种冲突并提出相应的解决方案。
最后，输出干系人档案。
二、系统分解
待开发的系统可能非常复杂，涉及不同的业务，则需要将系统分解，分别进行详细的需求分析。
3.2.1 做什么（关键任务）
系统分解的关键任务是业务子系统划分和业务接口分析。
3.2.2 为什么做（目标）
当系统复杂、涉及到不同的业务时，就需要通过业务子系统划分，将系统分解成更小的业务子系统，以解决系统过于复杂的问题；业务接口分析的主要目的是了解各业务子系统之间的服务关系。
3.2.3 怎么做（步骤）
任务4:业务子系统划分
划分业务子系统：根据系统特点，选择合适的划分策略进行分解。
标识接口、确定关系：正所谓“哪里有分解，哪里就有接口”，在分解完成后，必须明确各子系统之间的服务接口。
呈现业务子系统划分：根据实际情况选择合适的图表来呈现划分的结果，以便读者建立清晰、直观的理解。”
最后，输出业务子系统描述。
任务5:业务接口分析
明确接口的用途与业务价值：哪个子系统实现该接口是合适的？哪些子系统会用，用来实现什么价值？使用频率大概是怎么样的？
细化接口的交互过程：使用时序图呈现接口的交互过程，使用数据词典定义出每次交互过程数据包的构成情况。
确定接口设计约束：看技术管理部门是否使用特定的数据、通信协议，或者遗留系统带来的限制。其次对数据传输、数据查询、加密方面的要求进一步分析。除此之外还应该考虑系统的部署环境，使用者特点等。
最后，输出业务接口分析表。
三、功能主线
功能主线的需求分析将从业务支持、管理支持、维护支持三个方面展开。
3.1 业务支持类功能需求分析
3.1.1 做什么（关键任务）
分析业务类功能需求，有4个关键的任务，分别是，业务流程识别、业务分析和优化、业务功能识别、业务功能分析。
3.1.2 为什么做（目标）
我们希望通过对业务类功能需求的分析，了解
- 如何通过系统固化、优化业务流程，提升流程执行效率，节约成本、降低风险。
- 如何通过系统拓展业务渠道。
- 如何通过系统将个人能力转化成组织能力。
3.1.3 怎么做（步骤）
任务6:业务流程识别
识别外部引发的主、变、支流程：本业务的子系统有哪些外部客户？有哪些外部员工会提出服务请求？针对外部客户、员工，他们的主服务请求是什么？端对端流程是什么？主服务有独立的变体吗？为了更好的服务客户有哪些辅助的支撑业务？
识别内部引发的主、变、支流程：有哪些内部员工会发起流程？有哪些特定时间、状态发起的流程？针对内部员工、时间/状态，最核心的业务诉求是什么？这些诉求有独立的变体吗？有相应的辅助支撑业务吗？
识别管理流程：管理流程有事先的管理、事中控制的审批/规则，以及事后的报表/数据分析等，可以从业务上线类审批，人、财、物、资源的管控，以及进度和异常控制，这三个方面入手。
判断业务流程优先级：判断优先级，应从主营业务和频率两个维度分析。频率高的主营业务为关键流程；频率低的主营业务为重要流程；频率高的非主营业务为有用流程；频率低的非主营业务为一般流程。
最后，输出业务流程列表。
任务7:业务分析和优化
选择流程图描述方式：根据读者，流程的类型选择合适的流程图来描述流程分析结果。流程图一般强调分工和各角色的活动，可以选择跨职能流程图和活动图。
勾勒流程主体：厘清业务中的分工、活动、协作、分支、产物关系5要素，搭出流程的主体框架。
补充事中管控点：厘清业务流程中的异常、审批、规则。
分析流程执行过程的监管需求：从管理者对流程的进度、异常等方面的管控，识别、补充一些辅助的相关需求。
流程优化：对流程进行优化的典型策略：
- 清除无效：找出流程中不能产生效能的、浪费的、低效的环节，然后清理掉。
- 简化高频：对频率最高的环节进行优化，流程效率将上升。
- 整合依赖：将相互依赖的环节整合在一起，提高效率。
- 自动化繁琐：把人做起来麻烦的事让电脑来做，提升效率。
最后，输出业务流程描述。
任务8:业务功能识别
基于流程图识别系统角色：要对这个流程进行支撑，至少需要涉及哪些用户？对于非必需的角色纳入系统支持有什么价值，不支持会有什么不足？对于系统而言，这些用户扮演的是什么角色？从权限系统的角度如何抽象这些角色？
基于流程图识别业务场景：沿着流程对每个活动、分支、判断点进行分析和思考，哪些业务活动要系统支持，哪些是半支持，审批是否属于系统内，判断点是否为独立环节。
补充业务场景：除了人触发的场景外，还有特定时间、特定状态触发的业务场景。
绘制用例图片段并概述业务场景：当所有业务场景都识别出来，就需要分角色绘制用例图。在这里，管理者可能更偏向于看业务逻辑的整体链条，因此用例图更多的是给执行人员看。
最后输出业务流程内业务场景列表。
任务9:业务功能分析
概述业务场景：用一句话概述用户执行该业务场景所要完成的业务目的是什么；用户在执行该业务前，系统需要检查什么状态。用户在结束该业务时，系统需要检查以确保在什么状态；除了场景执行者之外，还有谁关心它，关心什么？
细化业务场景的业务步骤：最典型的、用户预期内的业务步骤是怎样的（基本事件流）；针对各个步骤，有哪些潜在的变化（扩展事件流）；针对各个步骤，有无异常情况，异常情况怎么处理（异常事件流）。
遍历步骤分析困难，导出功能：在各个业务步骤、变化和异常情况下会遇到什么困难？针对这种困难，系统应该提供什么样的功能来支持？
识别环境与规则：分析场景时，需要考虑环境和业务特点给系统带来的影响：
- 性能相关：主要包括执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度（特别是一天内业务发生的频率不一时需要说明）
- 易用性相关：主要就是用户的成长经历和相关系统使用的经验，它对于系统易用性设计有指向性作用。
- 部署环境相关：说明用户所在的网络、软硬件等相关环境。
分析实现方式，初步完成交互设计：初步交互设计主要包括：
- 交互过程：也可以理解为界面流转图，用来表达你希望系统如何来实现该场景的所有业务步骤。
- 静态快照：即每个页面上的具体内容，可以使用纸上原型呈现。
- 设计说明：针对每个页面内容、界面流转做一些描述，核心在于说明自己为什么这样考虑，以及它是一种建议还是一种约束。
最后，输出业务场景分析列表。
未完待续………………
