有效需求分析
引导篇
软件需求全景图
有一天夜里，资深需求分析师老余刚忙完一个重要的项目，带着放松的心情进入了梦乡。这时他年仅3岁的小孩夜里醒来，吵着要吃饼干。孩子的妈妈首先被吵醒，带着情绪地训斥了小孩：“半夜三更吃什么饼干，好好睡觉！”
没想到小孩不依不饶，继续哭闹着，不久老余也被吵醒了……
他安静地起身到了客厅，找了一小会儿，果然没找到饼干！他随手拿了两块吐司面包走进卧室，脸上掠过一丝自信的微笑。“小子，没有饼干了，吃点面包填填肚子吧！”老余边说边把吐司塞到小孩手中。果然，小孩接过面包后就不再哭闹了，吃完一片就乖巧地躺下。不一会儿，老余家又回归了平静。在这个例子中，小孩提出“要吃饼干”，这实际上是一个方案级需求。由于家里没有饼干，因此妈妈认为孩子提出了一个不合理的需求，于是想办法让小孩放弃这个需求。而老余则快速意识到了这个方案级需求背后真实的问题级需求是“饿了”，因此找到了可行的解决方案——吃面包，小孩的需求也得到了满足。
价值需求就是从黑盒子视角回答“整个软件系统为客户解决了什么问题、创造了什么机会”，“对于系统而言，最关键的干系人有哪些”，“各个重要干系人对系统的关注点是什么？有哪些担心（阻力点）”三个本质性问题。价值需求是组织应用类软件系统需求的灵魂和方向，但在很多此类需求分析实践中，这部分做得相对薄弱。这将使得项目范围更容易蔓延，客户从中获得的利益与价值不容易呈现，从而导致客户满意度难以有效提升。
详细需求就是从灰盒子视角完成三个主题的分析：“为了给客户提供业务、管理、维护支持，需要提供哪些功能？”“系统所涉及的问题域中有哪些数据，之间是何关系？”“所处的业务环境会带来哪些约束和质量要求？”
这三个主题实际上就是详细需求中的功能需求、数据需求、非功能需求三条主线。
功能主线的梳理可以从业务支持、管理支持、维护支持三个角度展开。
业务支持最典型的是三类：首先是固化、优化业务流程，因此业务流程是核心；其次是业务延伸到新的通道（诸如手机端），最后是将个人能力转化为组织能力，而这种能力存在于具体的业务场景中，因此“专家场景”是核心。
软件系统对管理的支持，主要可以体现在三个方面：
(1)事前风险避免，通过增加管理流程；
(2)事中风险控制，通过“规则”和“审批”；
(3)事后总结优化，通过“数据分析”。
前两种通常会在业务支持分析中统一处理；第三种则应该独立进行分析。
系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也需要有相应的功能来支持。
要厘清维护需求，简单来说，就是从灰盒子视角回答两个问题：“有谁会需要对系统进行维护？”“他们需要执行哪些维护任务？”
功能主线是从“工作流”线索分析的。
数据主线，重点就在于厘清组织中的“信息流”。
数据主线的需求分析就是从灰盒子的角度回答三个问题：“系统相关的问题域中有哪些业务数据？”“它们之间是什么样的关系？”“每个业务数据的具体构成是怎么样的？”
非功能主线的需求分析就是从灰盒子的角度回答一个问题：“系统相关的外部环境会带来什么样的约束和质量要求”。
通过价值需求、详细需求（包括功能、数据、非功能三条主线）的梳理，识别并描述业务功能、业务报表、业务数据、质量场景、业务接口五类最小需求单元，基本覆盖了需求分析的所有内容。此外，还有两方面内容，一是约束，二是规则，有时需要单独进行更加详细的分析
价值需求篇
1 目标/愿景分析
项目目标也可以称为愿景，是组织应用类软件系统项目、产品的灵魂，是对于出资人（或发起人、属主）而言价值的体现。
目标分析这一关键任务，可以分成四个步骤执行。
(1)访谈“问题”：通过对关键干系人的访谈，识别预期与现状的差距。
(2)研讨“机会”：通过与领域专家、技术专家、用户代表的交流，寻找潜在机会。
(3)定义问题/机会：描述问题、机会，以及它影响谁、产生什么结果。
(4)分析问题并确定解决方案：深入分析问题，然后确定策略级的解决方案。
访谈“问题”、研讨“机会”两个步骤可以根据实际的项目需要选择只执行一步，或者两个步骤都执行。
当你根据不同的项目触因选择合适的策略调研出问题场景，或者通过与业务领域专家、技术专家、需求团队从新业务、新技术、新人群的角度研讨出机会场景之后，接下来的一步就是清晰地定义它们。
经营层面的问题通常会是高层最关注的方向；
涉及管理模式、业务模式的宏观管理问题也会是他们关心的内容。千万别把操作层遇到的非共性困难当作问题列入目标分析。
描述问题只是第一步，紧接着应该说明这些问题影响了谁，给他们带来了什么样的影响，使得故事更加完整。在这部分的描述中，也要注意把握三个要点。
1)指代清晰，具体到人
2)视角匹配，影响明确
3)推理合理，层次清晰
我们需要提炼出一句话，对这个目标场景进行概述。其要点在于业务态、价值态，以“措施＋效果”的结构描述。下面这个例子就不太符合要求：构建物资管理系统，避免物资脱节。这个描述虽然是以“措施＋效果”的结构描述的，但“措施”不够业务态，“效果”没有体现价值态。更合适的是：基于安全库避免物资脱节，为门店扩张奠定后勤基础。
2 干系人识别
对于任何产品、项目而言，都会涉及各种干系人（Stakeholder），他们有着不同的诉求、关注点，甚至存在着各种冲突。在需求分析过程中，识别出关键干系人是十分重要的事情。
这个模板由类型、名称、说明、相关度、影响度五个栏目构成。
(1)类型：包括出资人/发起人、使用者、评价者、其他四种类型。
(2)名称：即该干系人的名称，通常会以职位的形式描述，也可能会以角色的形式描述。
(3)说明：简要说明他为什么是我们的关键或重要干系人。
(4)相关度：项目与他直接相关吗？涉及他的利益或责任吗？可以使用“高、低”两级评估或“高、中、低”三级评估。
(5)影响度：他对项目的方向、验收有很强的影响力吗？可以使用“高、低”两级评估或“高、中、低”三级评估。
相关度、影响度两栏通常仅限于开发团队内部阅读，不宜直接提供给客户代表阅读，以免带来不必要的麻烦。
3 干系人分析
识别出关键干系人只是第一步，选择合适的代表进行调研，分析他们的关注点、阻力点，以及满足关注点、避免阻力点所需的功能、非功能需求是一个重要任务。
干系人分析这一关键任务，可以分成三个步骤执行。
(1)选择干系人代表：如果有多个干系人，则应从中选择一位或多位典型的代表，以便聚焦。
(2)访谈干系人，分析关注点：通过访谈等手段，收集原始需求信息及相关反馈，从中分析出关键的关注点和阻力点。
(3)干系人关注点整理：横向评估不同关键干系人之间诉求、关注点的冲突，并制定相应的应对策略。
干系人档案模板主要包括三部分内容：基本信息、核心关注点和备注。
(1)干系人基本信息：主要包括名称、类别（与干系人列表的类别相同）、相关度、影响度（这两个同样只给开发团队看，不直接提供给客户代表）、职责（该干系人的工作职责要点，以便更好地理解他的关注点）、代表（如果有多名，从中选择一个）、联系方式（以便找到他）。
(2)核心关注点：逐条写出该关键干系人的关注点（正需求）、阻力点（负需求），还可以考虑写出相应的功能需求；另外，对其编号以便跟踪，判断重要度（可以使用“高、中、低”或“关键、重要、有用、一般”进行评估）以便管理。
(3)备注：记录一些其他便于理解干系人的相关信息，诸如专业背景、职业发展过程等。
详细需求篇 系统分解子篇
4 业务子系统划分
业务子系统划分这一任务主要包括以下三个步骤。
(1)划分业务子系统：根据系统特点，选择合适的划分策略进行分解。
(2)标识接口、确定关系：正所谓“哪里有分解，哪里就有接口”，在分解完成后，必须明确各子系统之间的服务接口。
(3)呈现业务子系统划分：根据实际情况选择合适的图表来呈现划分的结果，以便读者建立清晰、直观的理解。
划分业务子系统不是目的，而是一种手段，一种控制复杂度的手段。如果系统涉及的业务简单、用户群单一，那么就没必要划分。
5 业务接口分析
在“业务接口分析”模板中，可以分为三部分：接口概述及用途、接口交互过程与数据包说明、接口设计约束
(1)接口概述：包括接口名称、提供该接口的子系统，以及使用它的各个子系统（包括使用的子系统名称、使用该接口的业务目的、什么时候使用、大致频率如何）。
(2)接口交互过程与数据包说明：如果交互过程比较复杂，可以考虑使用序列图来呈现，而数据包则可以使用数据词典来细化。
(3)接口设计约束：最典型的有协议要求（指定使用的相关协议）、性能要求（诸如响应时间等）、环境要求（网络、部署环境、用户使用环境等方面的信息）。
详细需求篇 功能主线子篇
6 业务流程识别
7 业务流程分析与优化
业务流程分析，最重要的是厘清业务流程八要素，包括五个基本要素（分工、活动、协作、产物关系、分支），三个管理要素（审核、规则、异常）。
业务流程分析这一关键任务，可以分成四个步骤执行。
(1)选择流程图描述方式：根据读者、流程类型选择合适的流程图来描述流程分析的结果。
(2)勾勒流程主体：厘清业务流程中的分工、活动、协作、分支、产物关系五要素，搭出流程的主体框架。
(3)补充事中管控点：厘清业务流程中的异常、审批、规则。
(4)分析流程执行过程的监管需求：从管理者对流程的进度、异常等方面的管控，识别、补充一些辅助的相关需求。
我们在做业务流程分析，而不是画活动图、数据流图，这些图只是分析的一种结果。
勾勒出流程主体之后，也就厘清了业务过程；接下来可以花时间通过沟通、讨论，对流程事中控制的管理要素进行分析。这主要包括异常、审批、规则。在实战中，建议按照以下步骤来补充这些事中管控点。
(1)首先和业务专家、客户代表就“异常”进行交流，主要的思考方向是：“是否存在完全不能够按这个业务流程执行的情况？如果存在，那么应该怎么处理呢？”诸如“应急流程”、“绿色通道”等，都是典型的“异常”处理流程，建议用文字或另一张流程图来描述它们。
(2)其次再把重心放在“审批”上，可以询问“现在有哪些审批点？还有哪些环节存在执行风险？需要增加什么样的审批？由谁来审批合适呢？”等问题来收集相关信息。
(3)最后再沿着流程，思考一下是否需要设置一些规则。从规则类型角度上，主要有两类，包括“决定是否能够执行、如何执行”的行为规则，以及操作权限、数据构成等数据规则。具体在实战中，可以从以下几个角度逐一思考、梳理。
①协作间规则：也就是用于控制流程协作的规则，诸如“物资管理员应在每个月5日前向采购部门汇总本月物资采购申请单”。
②业务活动执行规则：也就是在执行各个业务步骤时需要遵循的规则，诸如“在体检科室，只对盖章的体检单进行体检”。
③数据规则：针对表单、文档、生成产物的格式、内容进行限制的规则，诸如“所有金额取小数点后两位”。
8 业务场景识别
用例、用户故事的精髓在于“用户视角”，在于“业务场景/使用场景”。它要求你不再关注于系统提供什么功能，而是用户在什么场景下需要系统提供支持。
9 业务场景分析
当我们识别出系统要支持的业务场景之后，将以“场景—问题/挑战—方案”的逻辑来分析每个业务场景，从而导出所需的功能。这种思路将取代传统需求分析方法中使用的“输入、输出、处理”模式。
对一个场景的分析，首先需要“概述业务场景”，以便大家对这个场景建立总体的认识。具体来说，
有三个思考点：
(1)该业务场景中，用户要实现什么样的业务目的？
(2)执行该场景有什么前提条件？结束前需保证何状态？
(3)除场景执行者之外，还有谁关心它？关心什么？
细化业务场景的业务步骤时，可以通过访谈用户代表、观察他们工作，或者直接收集他们的操作规程作为输入。在执行的过程中，可以思考三个问题：最典型的、用户预期内的业务步骤是怎么样的（基本事件流）；针对各个步骤，有哪些潜在的变化情况（扩展事件流）；针对各个步骤，有无异常情况，异常如何处理（异常事件流，通常是错误处理部分）。
质量要求和约束是有局部性的，在分析一个业务场景时，还应该考虑到环境、业务特点给系统实现带来的要求和影响。通常可以从以下几个方面着手分析。
(1)性能相关：主要包括执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度（特别是一天内业务发生的频率不一时需要说明）。
(2)易用性相关：主要就是用户的成长经历和相关系统使用的经验，它对于系统易用性设计有指向性作用。
(3)部署环境相关：说明用户所在的网络、软硬件等相关环境。
需求分析需要做初步交互设计，起到澄清需求的作用，作为后续专业交互设计师(UI/UE)完成最终设计时的建议或约束。而初步交互设计中主要包括以下几个方面的内容。
(1)交互过程：也可以理解为界面流转图，用来表达你希望系统如何来实现该场景的所有业务步骤。
(2)静态快照：即每个页面上的具体内容，可以使用纸上原型呈现。
(3)设计说明：针对每个页面内容、界面流转做一些描述，核心在于说明自己为什么这样考虑，以及它是一种建议还是一种约束。
在这个“业务场景分析”模板中包括场景概述、场景分析、例外分析三部分；对于业务系统而言，场景就是操作层用户要执行的任务，因此在模板中用“任务”来代替了“场景”一词，以便用户更易于理解。
(1)场景概述：说明该场景/任务的名称（任务名称）、该场景/任务的执行目的（任务简述）、执行该场景/任务的前提条件（任务前提），以及该任务出现的频率（任务频率）。
(2)场景分析：以“场景/任务、问题/挑战、方案/所需功能”的形式整理分析结果。其中，“子任务”一栏写出该场景最预期的步骤及每个步骤的问题；“任务变体”则写出一些扩展事件流及相应的问题；最后在“所需功能描述”部分写出这些问题、挑战所需要的功能，如表9-11所示。
(3)关键例外：在该场景中一些特殊的、需要开发特点功能来支持的场景例外，这个部分并不是必填的。需要注意的是，它们并不是一种正常执行过程中的分支（或称为变体），而是一种例外情况，如酒店前台要接待一个旅游团就是“办理入住”这个任务的关键例外。
10 管控点识别与分析
在执行该任务时，应该首先在子系统层面寻找相关的决策层（也就是高管）、管理层用户（也就是中、基层管理者）；然后在流程层级寻找相关的管理层用户；最后应该在整个系统层级寻找相关的决策层用户。
标识出所有相关的管理者之后，接下来可以通过访谈、侧面了解、职位职责及考核指标分析等方法来标识其希望通过系统来实现的管控点。管控点表示想通过数据分析实现的管理意图）。
11 业务报表分析
业务报表分析的重点在于厘清报表的使用场景、报表的内容，以及输出的相关要求。
业务报表分析首先要清晰地定义出它的使用场景。在这一步中，核心是厘清三个问题：谁使用、为什么用、使用频率如何。
报表的本质不是“事件流”，而是“内容”，即生成报表之前要输入什么条件，从哪里得到所需数据源，生成哪些数据项及其格式、计算方法。
(1)生成报表所需的输入条件：可以使用界面呈现，也可以说明需要哪些查询条件。
(2)数据来源：直接列出该报表应该从哪些数据表中获得基础数据，如果涉及大量的数据表，也可以考虑画一张领域类图片段，把涉及的数据表、数据表之间的关系都呈现出来。另外，还应该说明统计口径，也就是对哪些数据进行统计。
(3)报表中的数据项、格式、计算方法：逐一列举报表中各个数据项，以及每个数据项的格式、计算方法。
12 维护需求分析
本任务的核心目标是：分析系统投入使用之后，运行维护阶段所需要提供的辅助功能，主要包括配置、运维、升级迁移及其他三方面。
要执行好“维护需求分析”这一任务，关键在于抛开功能性思考，转而识别有哪些“维护场景”，以及该维护场景需要提供什么支持。
对于信息系统而言，第一种最典型的维护场景就是“各种配置”，以应对变化带来的影响。既然配置是应对变化，那么标识配置性维护场景就应该从变化入手，系统会遇到什么变化呢？从里到外主要有以下几方面。
(1)用户群变化：也就是使用这个系统的用户发生改变，他们的职位发生改变，他们的权限发生改变。因此，要想维护用户、维护角色、维护权限，也就相应地需要一些配置功能。对于权限而言，核心包括功能权限、数据范围权限、分配权限的权限。
(2)流程变化：企业的流程总会根据自身在发展过程中关注点的改变而不断进行调整，以满足阶段性管理目标。因此，如何有效应对流程变化对系统带来的影响，是需要提前考虑的。
(3)数据变化：随着企业业务的不断发展、深化，会需要在系统中引入更多的数据项、更多的数据细节。因此，如何应对未来数据项的增加、数据构成的调整与变化，也是需要提前考虑的。
(4)法规变化：企业在经营过程中，有时会涉及法律法规的要求，而法律法规在一定的时间周期内可能会更新或出台不同的实施条例。因此，应该考虑到当这些法规发生变化时，如何有效地应对。
在系统运行过程中，运维团队有责任保证系统安全、可靠、稳定地运行，因此需要一些系统工具来支持这些工作。这方面可以从“正常时”、“故障时”两个角度展开分析。
对于系统正常运行时，主要涉及的运维场景有两个方面：一是对运行状态的监控，二是数据备份。
系统在运行时，必然会出现各种各样的故障，因此需要故障定位、排错、故障恢复及应急措施的支持。
除了配置、运行时维护之外，典型的其他维护场景包括运行前的初始化，系统升级、迁移时所需的支持。
(1)系统初始化：在系统第一次安装、部署时需要提供什么样的工具支持，如安装工具、初始化配置工具、测试工具等。
(2)系统升级：系统在升级时需要提供什么样的支持，如远程升级、自动化升级、版本检查等。
(3)系统迁移：每次升级时，是否需要对原有系统进行数据迁移，是否需要支持双系统并行运行等支持。
详细需求篇 数据主线子篇
13 领域建模
在信息系统需求分析中，数据主线的重点在于范围与关系，也就是哪些数据要纳入系统，它们之间的关系是什么，而领域建模正是解决这两个问题的关键。
领域建模的结果需要选择一个模型来表示，可选的模型只有两个：E/R图和类图。由于E/R图只能描述关联关系，而类图能够呈现出更多关系，因此强烈建议使用类图。
在类图中，“类”是最基本的元素，它表示一个具体的业务数据。它用一个长方形表示，分为类名、属性（字段）、方法三栏。
14 业务数据分析
数据应用分析，就是厘清哪些流程、场景在使用这些数据，使用这些数据的哪些部分，甚至厘清CRUD的关系；通常我们只需要对核心的、重要的业务数据执行这一步骤。
第一件事，在于分析哪些流程会使用这些数据。如果需要的话，还可以使用更加复杂的CRUD矩阵来细化，说明这些流程会Create（创建）、Retrieve（查询）、Update（更新）、Delete（删除）这些数据。
数据构成分析，首先要厘清这个业务数据包括哪些字段，然后针对各个字段厘清以下几方面的内容。
(1)数据类型：诸如字符串型、整型、布尔型等。
(2)数据规格：主要包括长度、精度信息，也可以直接使用数据表设计中的规格描述方式，诸如Varchar(100)。
(3)约束/取值范围：也就是该字段可以接受的值，对于复杂的取值范围还可以考虑使用传统的“数据字典法”描述。
(4)其他：如“是否非空、是否为键值、是否自动编号”等细节，如果该字段的值是计算出来的，那么还应该提供计算公式或计算方法。
数据的结构特点、使用特点等细节，将影响程序实现，对于核心的、重要的数据可以考虑对其做相应的分析，下面是一些供参考的思考线索。
1、结构特点
(1)主要字段与次要字段：也就是用户主要会看哪些字段，它将决定在列表中显示哪些字段。(2)稳定字段与不稳定字段：针对新业务带来的数据通常是不稳定字段，在表结构设计时需要考虑未来的扩展。
2、使用特点
(1)即时数据与历史数据：多久才算历史数据？这将影响历史数据的迁移，以提高实时查询的速度。
(2)关键字段与辅助字段：谁会被用来作为关键字？我们可以使用索引等手段来加快速度。
在“业务数据描述”模板中，主要分成三个部分：
(1)数据构成分析；
(2)数据应用特点：数据与流程之间的关系，以及数据窗口分析；
(3)数据使用特点，也就是其他说明部分。
这部分主要是描述数据构成，包括说明数据的字段名称、类型/规格、约束/取值范围等。下面一部分则用来说明哪些流程会使用到这些数据（数据与流程之间的关系）、分别使用到哪些部分（数据窗口分析）。而最后的“其他说明”部分则用来描述数据的结构特点、使用特点等。
详细需求篇 质量主线子篇
15 标识关键质量需求
16 质量场景分析
补充篇
17 业务规则分析
18 约束分析
约束实际属于非功能需求，非功能需求包括质量和约束两类，质量是对我们的要求，约束是对我们的限制。约束又分成两类，一类是项目约束，一类是设计约束。
项目约束，主要可以从进度、资源、预算三个角度来进行整理。
(1)进度要求：建议不仅仅列出最晚交付时间值，还应该理解这个最后期限背后的理由；诸如是为了新业务上线？新法规正式实施？参加新品展示会？以便更好地指导分阶段交付，以及未能完全满足时的预案。
(2)资源支持：明确接口人、开发/测试环境支持等；有一个小技巧，可以争取用户为每个业务主题设置相应的业务接口人，以获得更大支持。
(3)预算要求：在需求分析中一般不涉及，通常直接参考合同约定。
实现约束，主要可以从技术选型、部署环境、开发环境角度来进行整理。
(1)技术选型：客户有时会对开发提出具体的技术选型要求。通常原因有以下几种：一是相关政策、法规规定，诸如国产化平台要求；二是内部规范要求；三是接口人的技术偏好。前两者一般是不能改变的，第三种则有协商可能。
(2)部署环境：对实现产生约束的另一个方面将是部署环境的影响，主要包括遗留系统，用户采购的软硬件平台（服务器、终端、网络等），用户所处的国家、文化区域、社会环境（这将涉及用户的相关使用偏好、语言等相关内容），甚至生命周期也会有影响（如果是长生命周期对技术的先进性要求更高）。
(3)开发环境：实现约束还可能受到开发人员的技术能力、开发资源的影响而改变，也就是“开发人员能不能干、有没有资源干”。当然，这是需求分析工作中通常不必明确考虑的。
