需求分析标准工作方法

前言

需求的底层逻辑是用户痛点或兴趣（问题或机会），但行业、赛道、业态等都是变量，如何调研和挖掘就是方法论。本文档主要列举基于业务驱动，以业务为中心的 B 端软件系统需求分析常用概念、方法和工具，旨在帮助产品经理提高业务理解、需求分析工作质量和产出效率，标准工作流无需严格执行所有任务，产品经理可根据实际场景裁剪取用。

概念与模型

如统计学家 George E.P.Box 所说：“从本质上讲，虽然一切模型都是错误的，但有些还是有作用的”，本文列举所有模型、公式，都有受限的应用范围。

需求定义

普通人视角：“需求是现状与预期的差距。”
工程师视角：“需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，是一种对系统开发进程的约束。”

抽象思考

常见的需求分析视角：

菜单结构： B 端软件系统就是带一定业务逻辑的增删、改查功能；也有人说，做需求就是先搭菜单结构/功能模块。这些都是典型的白盒子视角，是从开发视角来说的技术驱动需求理念。这一视角，会让用户对需求分析过程敬而远之，写出的需求文档也将令用户望而生畏。

业务用例：我们应该先找业务用例，再找系统用例，从用户的角度来“发现”。这虽然是一种“黑盒＋灰盒”的视角，但大量实践者苦于难以有效地完成思维角度的切换；另外，这种较小粒度的抽象方法，容易在需求分析过程中陷入树木而忽略森林，很难对软件系统进行全局设计和把控。

用户故事：我们应该让现场客户用“作为 ×××，希望系统实现……以便……”的句型说出他的需求。这也是一种完美的黑盒视角，但真的能够把“讲清需求”的责任转移到用户身上吗？这种转移真的有利于需求分析吗？

实际上还有更好的思考角度和做法，那就是厘清系统中的所有功能是因何而存在的。如果我们站在更宏观的角度上来看，实际上最核心的 B 端系统的功能需求无外乎以下几个方面：

👀

- 通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险、提高效果质量等；
- 通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等新途径和模式；
- 通过系统将个人知识、能力转化为组织知识、能力，借助新技术实现自动化、智能化模型；
- 通过系统实现数据的信息化，实时共享，辅助管理决策。

以业务为中心，围绕组织战略及愿景，业务价值和目标，业务角色-场景-路径，开展从上至下，从主干到分支的业务调研及分析，较为适用于项目型 B 端软件系统。

分析模型

模型 1：三个层次的软件需求

模型 2：用户体验要素

模型 3：业务导向需求分析

价值与优先级

如何去评估需求的价值？（以 B 端项目型需求价值为讨论对象，暂不考虑商业化产品）

B 端需求的价值更多体现在解决业务问题，实现业务价值，所以需求的价值应优先考虑业务价值，如下列元素：

👀

- 与核心（主营）业务的距离；
- 业务流程递进、依赖关系；
- 业务流程完整性；
- 业务频次；
- 影响范围（用户范围、关联业务）。
……

需求价值 = 新体验 - 旧体验 - 替换成本

体验的改进（包括但不限于流程简化/自动化/智能化等），量化评估需求价值的例子：

👀

- 处理相同业务对象耗时变化（如审批一个合同耗时降低）;
- 人工处理的业务对象变化（如需要审批的合同数量减少）;
- 直接或间接经济效益；
- 相关业务指标变化。 ……

需求优先级应该以业务价值/开发成本来衡量。理想情况下优先做业务价值最大，且成本最小的需求。需求的优先级还要以功能之间的递进关系，依赖关系，比如一般要先实现基础数据建立，再实现核心业务流程，再实现功能整合业务协同，数据汇总智能化等。将业务价值与四象限法（重要/紧急；频率/用户量；收益/成本；……）组合使用，可以较为有效地对需求进行优先级排序。

标准工作方法

这里将以 2.3 中模型 3 业务导向需求分析方法，展开列举 B 端软件需求分析标准工作流的 18 个关键任务。

价值需求

价值需求就是从黑箱模型视角回答：

TIP

- 整个软件系统为客户解决了什么问题、创造了什么机会？
- 对于系统而言，最关键的干系人有哪些？
- 各个重要干系人对系统的关注点是什么？有哪些关心？

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

任务 1 - 目标分析

目标就是问题和机会。

TIP

- 问题场景：如果客户预期高于现状，通常可以通过访谈获得；
- 机会场景：如果客户对现状满意，就要提出 新预期 来让他产生需求。关键在于从用户角度思考，而不是从系统中找优点；
- 目标分析主要针对的是项目发起人、出资人或项目归属人。

需求 = 预期 - 现状

👀

- 预期 ＞ 现状，用户通常会积极配合需求调研；
- 预期 ＝ 现状，用户表现不积极，很难用直接调研的方法获取需求；
- 预期 ＜ 现状，用户会抗拒变化，对需求调研表现消极。

针对后两种情况，需要通过对现状的深入了解，提出用户可能为之心动的“新预期”，从而使“预期 ＞ 现状”。

变革公式：D×V×F ＞ R

不满情绪（Dissatisfaction）× 变革愿景(Vision) × 初步实践（First Step）> 变革阻力（Resistance）。

需求或项目落地阻力较小的场景：问题 够 “痛”，机会够 “好”，实践 够 “浅”。

🔔 定位问题与机会的参考路径：

使用《问题卡片》记录问题与机会：

定义出问题和目标后的三种描述方式：

TIP

- 定性描述：

从总体属性、趋势、宏观的角度来说，如“全面提升客户服务质量”、“全面提高沟通效率”。仅指出了一个模糊的方向，无法有效界定系统的范围；

- 定量描述：

SMART 原则，具体的、可衡量的、可实现的、有相关性的、有时限性的；

- 场景化描述：

用故事场景来描述用户的期望，包括当前的现状、它所引发的影响，以及系统可以采用的策略。

剪裁说明

在实践中，可能遇到目标十分清晰、明确的项目，这时可以考虑跳过这一任务。典型的场景包括：

（1）因相关法规的改变，需要改造系统以适应新法规需求；这时监管部门、上级部门的验收标准就是目标；

（2）企业因开拓一项新的业务，因此改造系统以便提供支持；这时新业务上线就是目标；

（3）为业务服务提供一种新的通道，如原来要现场办理，现在增加电话或网站办理，这种情况也可以弱化目标分析的工作。

🔔 由于目标分析是整个需求分析工作的灵魂和方向，因此在剪裁该任务时一定要谨慎。

任务 2 - 干系人识别

干系人的英文原词是 Stakeholder，在各种中文文献中还常被译作涉众（RUP）、相关人员、利益相关者、风险承担人。对于任何产品、项目而言，都会涉及各种干系人，他们有着不同的诉求、关注点，甚至存在着各种冲突。项目涉及的各个部门之间可能会因为考核指标、诉求、利益点的不同，甚至是冲突，而提出完全“相克”的需求。

项目是一个博弈游戏，重要的是获得足够的筹码，也就是需要找到关键的筹码持有人（Stakeholder），赢得足够的筹码就可以赢得项目，并且你也不可能获得所有的筹码。

👀 提供识别项目中的关键干系人的常见思路：

使用干系人列表，管理干系人范围及定位：

裁剪说明

干系人识别这一任务通常不宜被剪裁，毕竟它是从宏观的角度抽象出项目、产品中最核心的需求。

任务 3 - 干系人分析

识别出关键干系人只是第一步，选择合适的代表进行调研，分析他们的关注点、阻力点，以及满足关注点、避免阻力点所需的功能、非功能需求是一个重要任务。

可以按以下路径思考：

阻力点类似于 KANO 模型中的反向（逆向）需求，或负需求。

干系人的分析完成后，可用下表记录：

可以将表 2、表 3 结合使用：

裁剪说明

干系人分析这一任务是干系人识别的延续，因此通常也不宜被剪裁。如果干系人相对少，关注点、阻力点简单明确，可以剪裁掉《干系人档案》文档，直接在《干系人列表》的“说明”栏中写明关注点和阻力点即可。

详细需求

👀 详细需求就是从灰箱模型的视角完成：

TIP

- 功能需求：为了给客户提供业务、管理、运维支持，需要提供哪些功能？
- 数据需求：系统所涉及的问题域中有哪些数据，之间是怎样的关系？
- 非功能需求：所处的业务环境会带来哪些约束和质量要求？

划分业务域

任务 4 - 划分业务子系统

假如待开发的系统相对复杂，涉及多种不同的业务，为了控制分析的复杂度，我们通常需要先将其分解成更小的部分。可以根据实现结构来划分，但在需求阶段更推荐根据业务来划分。

可以按以下路径思考划分业务子系统：

使用下表，记录业务子系统间及服务接口：

裁剪说明

划分业务子系统不是目的，而是一种手段，一种控制复杂度的手段。如果系统涉及的业务简单、用户群单一，那么就没必要划分，就可以剪裁掉该任务。

任务 5 - 业务接口分析

标识出各个业务子系统之间的服务关系之后，就需要针对这些服务关系（即业务接口）逐一分析。

👀 分析思路如下：

使用下表进行记录：

裁剪说明

业务接口是指不同业务子系统之间的服务关系，因此只要系统中存在多个业务子系统（也包括修改、影响的子系统）就需要执行该任务。有时我们将修改原有的业务接口，那么建议先说明原有的业务接口，再说明修改要求及修改理由。

功能主线

任务 6 - 业务流程识别

信息系统的核心价值之一是支持业务，而业务支持的核心是对业务流程的固化、优化和重构。在需求分析时，识别出相关的业务流程是关键任务之一。

可以按照下图思路进行：

如何去着手识别业务流程呢？可以借助一个定义：企业或组织的核心价值在于响应外部客户的服务请求，通过一系列的协作满足服务请求，为客户带来价值，同时为企业／组织带来价值。也就是说，从全局上看业务流程的起点通常就是这些外部服务请求。

👀 识别端到端流程的关键在于以下两点：

TIP

（1）完整：所谓的端到端，实际就是服务请求从提出到满足的全过程。判断一个流程是否完整，应该站在服务请求的立场，判断服务请求是否满足或者被拒绝。

（2）边界：识别业务流程时涉及两种边界。一是职能边界，也就是跨越了我们未涉及的业务域；二是系统边界，也就是不属于系统关注的部分。业务流程可以用下表记录。

裁剪说明

业务流程是由一系列角色协作，以满足服务请求的闭环。如果要设计的系统是诸如 POS 机等只存在单一用户、主要以人机交互为主的系统，那么可以跳过“业务流程识别”、“业务流程分析与优化”这两个任务，直接执行“业务场景识别”任务即可。

任务 7 - 业务流程分析与优化

在标识出相关的业务流程之后，接下来的关键任务就是逐个流程进行了解与分析，绘制出流程图，并对关键流程做适度的优化。要做好业务流程分析与优化，首先要深入理解两个概念：第一，业务流程是分层的；第二，业务流程分析的关键是厘清流程八要素，包括五个基本要素（分工、活动、协作、产物关系、分支），三个管理要素（审核、规则、异常）。

👀 业务流程天然可以分成三层：

TIP

（1）最宏观的是组织级流程，画的是部门间协作关系，供决策层读者阅读；
（2）第二层是部门级流程，画的是岗位间协作关系，供管理层读者阅读，业务流程分析应在这个粒度上进行；
（3）第三层则是个人级流程，画的是一个岗位的工作步骤，应该到业务场景分析时再细化。

可以通过以下思路进行绘制：

业务流程优化是一个很宏大的话题，在此仅提供一种方法做参考，“ESIA”模型：

TIP

∙E（清除无效）：找到流程中不产生效能的、浪费的、低效的环节，然后想办法清除；
∙S（简化高频）：对频率最高的环节进行优化；
∙I（整合依赖）：将相互依赖的环节整合在一起，缩短路径；
∙A（自动化繁琐）：把人做起来麻烦的事让电脑来干。

使用下表来记录描述

裁剪说明

在“业务流程标识”任务中找到的所有业务流程，有时并不涉及多个岗位（或其他角色，如系统）参与，这时整个业务流程就将退化成为一个业务场景。针对这种情况，通常无须再对这种业务流程进行分析，直接将其标识为业务场景即可（参见下一任务业务场景识别）。

任务 8 - 业务场景识别

识别出系统相关的业务流程，然后对这些流程进行详细的分析、优化，接下来就需要识别出这些流程中存在哪些和系统相关的业务场景。这也是业务为中心需求分析方法的重要任务。

在一个信息系统中，业务流程是指不同岗位之间通过协作满足外部服务请求的过程；而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动。因此，从某种角度而言，粒度是由组织分工决定的。

识别业务场景，可以按照下图思路：

可以使用用户故事，对业务场景进行描述。

用户故事是敏捷开发中一种轻量的、有效的用户需求描述方式，它希望用户或用户代表以“作为 xxx（角色），希望通过系统 xxx（解决方案、功能要求），以便达成 xxx 业务目的、要解决的业务问题”的形式提出需求，也可以由有经验的产品经理/业务分析师产出。具体方法可参考《用户故事与敏捷方法》，《七步掌握业务分析》，《用户故事地图》，在此不做展开，可以用故事卡的形式进行记载。

裁剪说明

业务场景识别这一任务不能被剪裁，因为在业务为中心的需求分析方法中，它是封装需求的“原子级”单位。我们使用“业务场景识别”→“业务场景分析”来代替“模块划分”→“功能分析”这种传统的分析方法。

任务 9 - 业务场景分析

当我们识别出系统要支持的业务场景之后，将以“场景—问题／挑战—方案”的逻辑来分析每个业务场景，从而产出所需的功能。

对业务场景进行分析可以按下图思路进行：

在进行业务场景分析后，可以使用下表记录业务场景：

（1）场景概述：说明该场景／任务的名称（任务名称）、该场景／任务的执行目的（任务简述）、执行该场景／任务的前提条件（任务前提），以及该任务出现的频率（任务频率）。

（2）场景分析：以“场景／任务、问题／挑战、方案／所需功能”的形式整理分析结果。其中，“子任务”一栏写出该场景最预期的步骤及每个步骤的问题；“任务变体”则写出一些扩展事件流及相应的问题；最后在“所需功能描述”部分写出这些问题、挑战所需要的功能。

（3）关键例外：在该场景中一些特殊的、需要开发特点功能来支持的场景例外，这个部分并不是必填的。需要注意的是，它们并不是一种正常执行过程中的分支（或称为变体），而是一种例外情况，如酒店前台要接待一个旅游团就是“办理入住”这个任务的关键例外。

🔔

可根据场景，将产生的功能进行分类，可形成业务目标、功能架构图、信息架构图、页面流程图、用户故事地图等工具，进而进行初步的原型设计。

裁剪说明

业务场景分析这一任务 不能被剪裁 ，因为在业务为中心的需求分析方法中，它是对封装需求的“原子级”单位进行分析。我们将通过业务场景的分析，推演出用户所需要的功能需求。

任务 10 - 管控点识别与分析

正如上文所述，信息系统的核心价值之一是支持管理，而管理支持的核心是通过管理流程事前规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化。

前两个部分通常与业务流程识别、分析相结合，而通过数据分析实现管理优化就是本任务的核心主题。该部分重在分析其目的，即识别管控点。

可按照下图进行工作：

使用下表记录管控点：

使用下表进行管控点分析:

（1）相关干系人：指出该管控点有哪些管理层用户会使用到，如果他们的阅读重心不同，还应该用文字指出。特别是当相关干系人包含决策层和管理层时，他们的角度通常都会有所不同。

（2）管控点目标：清晰地从业务角度，以价值态的形式说明各个干系人希望通过这个管控点（可能是报表，可能是 BI 需求，可能是数据挖掘、大数据实现）达到的业务目标。

（3）所需业务报表：管控点通常是需要一些“指标”来分析的，而“指标”则是由一堆数据来体现的；如果这个管控点所需的数据分析可以从相对固定的数据源中获取，并且可以采用相对固定的查询条件来分析，那么就可以简单地使用报表来解决。如果你的管控点可以用报表实现，那么就应在此列出你认为所需的业务报表，以便后续进一步分析。

（4）BI、数据仓库／数据挖掘需求：有一些指标、数据分析的要求无法简单地使用报表来实现，那么就需要使用更复杂的手段。如果要采用 BI、数据仓库／数据挖掘、大数据等技术，在此应该明确出你认为需要对哪些指标、哪些数据进行挖掘，以黑盒子视角明确相关的需求。

剪裁说明

管控点识别与分析是信息化系统需求分析中的一项重点内容，但如果你开发的系统不包括通过数据分析来支持管理，那么本任务可以剪裁掉。如果你开发的系统是经营分析、大数据分析等项目，那么该任务将成为重中之重。

任务 11 - 业务报表分析

当识别出管控点并对其分析之后，如果需要使用业务报表来实现，那么接下来应对各个报表的需求进行描述。参考思路如下：

按下表对业务报表进行描述：

（1）报表概述：包括报表名称、使用者、业务意图、使用频率四个栏目，也就是讲清楚该报表叫什么、谁会使用、多久用一次、用来干什么。

（2）报表实现分析：包括报表输入条件、报表输出格式要求、报表数据来源分析、报表数据项说明四个栏目，也就是说明生成这个报表之前是否需要输入查询条件，生成的报表是什么样的格式，报表的数据从哪里来，以及每个内容项的格式是什么。

（3）报表相关要求：主要包括报表是否要打印、是否有特定的图表要求、图表是否要打印、如果生成的报表有多页应该如何处理、分类小计如何处理、是否存在特殊排序需求（即用升序、降序无法解决的需求）、统计口径方面是否有需要交代的地方。

裁剪说明

业务报表与业务接口、业务功能、业务数据、质量场景一样，是系统五大基本元素之一。只要系统中存在业务报表需求就需要执行该任务；如果没有报表需求即可裁剪。

任务 12 - 运维需求分析

本任务的核心目标是：分析系统投入使用之后，运行维护阶段所需要提供的辅助功能，主要包括配置、运维、升级迁移及其他三方面。

更改/优化的需求

运维期间接收需求，经常遇到“方案级需求”。业务驱动的需求思想是站在用户视角展开的，关注的是“问题级需求”。需求分析任务的起点是发现和定位问题，终点是解决问题，产品经理是“问题解决者”，而不是简单的需求传递者。可使用附件 3-《需求池文档》，维护管理问题与需求对应关系。

👀

如何发现和分析问题？提供一种思考路径：

数据主线

任务 13 - 领域建模

在信息系统需求分析中，数据主线的重点在于范围与关系，也就是哪些数据要纳入系统，它们之间的关系是什么，而领域建模正是解决这两个问题的关键。常用的领域建模工具有两个：

E/R 图和类图。由于 E/R 图只能描述关联关系，而类图能够呈现出更多关系，因此建议使用类图。领域建模通常由后端开发工程师完成，产品经理也可以根据实际情况协助完成，在此不对领域建模展开阐述，可阅读 UML 建模相关书籍。

剪裁说明

领域建模的核心目的在于厘清系统中应该引入哪些业务数据（范围）、它们之间是什么关系，因此业务数据越多、越复杂，领域建模工作就越重要。建议在以下几种情况时，必须在需求分析过程中执行领域建模工作：

（1）对于开发团队而言，该系统涉及的问题域是新的、相对而言不熟悉的，为了能够更好地理解业务术语的意义、关系，应该执行该任务。

（2）系统中涉及的业务数据较多（大于 50 类），或者直接进行数据库设计比较困难时，也应该执行该任务。

任务 14 - 业务数据分析

当我们通过领域建模或其他方法标识出系统所涉及的业务数据之后，我们还需要细化每个业务数据的构成细节，也就是“业务数据分析”。业务数据分析依旧是一个很宏大的命题，感兴趣的产品经理可自行阅读相关书籍。

在此仅列举一部分要点：

（1）数据应用分析：就是厘清哪些流程、场景在使用这些数据，使用这些数据的哪些部分，甚至厘清 CRUD （创建、查询、更新、删除）的关系。

（2）数据构成分析：首先要厘清这个业务数据包括哪些字段，然后针对各个字段厘清它的数据类型、数据规格、约束/取值范围、其他。

（3）数据特点分析：结构特点：主要字段与次要字段、稳定字段与不稳定字段；使用特点：即时数据与历史数据、关键字段与辅助字段。

裁剪说明

除非要开发的系统中不涉及业务数据（如 AutoCAD、计算器等工具），否则该任务是无法剪裁掉的。

质量主线

任务 15 - 标识关键质量需求

在信息系统需求分析中，非功能需求主线的重点在于标识出最关键的质量需求，以便通过有效的技术手段来保证系统能够达到要求，为业务提供稳定、可靠的支持。质量需求，要从逆向、场景化的角度来思考。

识别重要质量属性：

👀

• 安全性：最大威胁在于存在敏感数据、组织“名气”很大、处于开放网络环境、用早期版本操作系统部署；
• 可靠性：最大威胁在于要求高、环境复杂、使用者手生；
• 易用性：最大威胁在于效率要求高、用户基础弱、与“你”差异大；
• 性能：最大威胁在于高并发访问、复杂的算法与逻辑；
• 可维护性：最大威胁在于变化，包括业务变化、技术变化；
• 可移植性：最大威胁在于系统生命周期长、系统部署范围大。

对重要质量属性排序：

👀

• 威胁影响度：无法承受、重大损失、轻微损失、无关痛痒；
• 出现频率：分为经常出现、偶尔出现、低概率出现。

裁剪说明

质量需求，通常是应对系统运行、应用环境所带来的威胁；因此除非你开发的是过渡性、演示性系统，否则都不宜完全把这个任务剪裁掉，至少应该确定最重要的 3~5 项质量需求。

任务 16 - 质量场景分析

标识出最关键的质量需求之后，就应该针对这些质量需求属性进行细化，找出具体的质量场景，然后和开发团队一起讨论，采取合适的手段来实现这些质量需求。

👀 一个具体的质量场景可以从三个方面进行描述：

（1）目标，说明它属于哪种质量类型；
（2）场景，影响质量要求的具体场景；
（3）策略及风险，通常可由技术人员来写，说明针对该场景将采取的技术措施，以及该措施带来的副作用（风险）。

可以通过下表进行记录和描述：

剪裁说明

如果已经确定出最重要的质量需求列表，那么该任务就不应该被剪裁掉。应该针对列表中每类质量需求识别、整理出一些相应的质量场景。

补充需求

任务 17 - 业务规则分析

对于大部分系统开发时，可以结合流程分析出行为规则、结合领域类图分析出数据规则。但如果规则特别多、系统很复杂，则建议大家专门花时间来处理它。 如果专门对业务规则进行分析，通常可以分三步执行：按规则作用域归类规则、按规则类型二次归类规则、按分析规则后的动机以理解规则。

（1）按作用域归类：

对于一个系统而言，有影响整个问题域、整个系统的宏观规则；也有只影响一个业务流程的中观规则；还有一些只对业务场景产生影响的微观规则。

（2）按规则类型二次归类：

行为类：也就是一些影响业务流程、场景执行的规则，诸如“下单时，用户填入的下单数必须小于库存数”；它们适合放在相应的流程分析、场景分析的描述中。 数据类：也就是用来控制数据格式、内容的规则，诸如“组成一个订单的所有订单项，产品号必须是唯一的”；它们适合放在领域模型的规则描述中。

权限类：也就是用来控制执行和数据查看权利的规则，诸如“分公司经理只能审批自己分公司的、总金额在 100 万元以内的采购申请”；它们应该放在权限需求描述中。

（3）按分析规则后的动机：

在规则分析中，最重要的一点在于理解规则背后的动机，它包括两个方面：一是业务动机，二是可执行性考虑。理解业务动机，可能会发现该规则欠考虑的地方；理解可执行性考虑，则可能会发现通过系统实现后，可以更好地优化规则。

裁剪说明

规则分析通常可以在业务流程分析、领域建模一并完成分析，但如果它特别重要，可以把它当作一个专题。不管采用哪种方法，可以选择的具体思路与方法是类似的。

任务 18 - 约束分析

约束实际属于非功能需求，非功能需求包括质量和约束两类，质量是对我们的要求，约束是对我们的限制。约束又分成两类，一类是项目约束，一类是设计约束。

（1）明确项目约束

项目约束，主要可以从进度、资源、预算三个角度来进行整理。

● 进度要求：建议不仅仅列出最晚交付时间值，还应该理解这个最后期限背后的理由；诸如是为了新业务上线？新法规正式实施？参加新品展示会？以便更好地指导分阶段交付，以及未能完全满足时的预案；

● 资源支持：明确接口人、开发／测试环境支持等；有一个小技巧，可以争取用户为每个业务主题设置相应的业务接口人，以获得更大支持；

● 预算要求：在需求分析中一般不涉及，通常直接参考合同约定。如果真需要考虑。

（2）明确实现约束

实现约束，主要可以从技术选型、部署环境、开发环境角度来进行整理。

技术选型：客户有时会对开发提出具体的技术选型要求。通常原因有以下几种：一是相关政策、法规规定，诸如国产化平台要求；二是内部规范要求；三是接口人的技术偏好。前两者一般是不能改变的，第三种则有协商可能；

部署环境：对实现产生约束的另一个方面将是部署环境的影响，主要包括遗留系统，用户采购的软硬件平台（服务器、终端、网络等），用户所处的国家、文化区域、社会环境（这将涉及用户的相关使用偏好、语言等相关内容），甚至生命周期也会有影响（如果是长生命周期对技术的先进性要求更高）；

开发环境：实现约束还可能受到开发人员的技术能力、开发资源的影响而改变，也就是“开发人员能不能干、有没有资源干”。当然，这是需求分析工作中通常不必明确考虑的。

剪裁说明

这一任务一般不会被完全剪裁掉，要花的时间通常也不多，根据实际项目、产品的情况，决定花费多长时间即可。

快速工作方法

业界流行的一句话：“不要重复造轮子”。车轮子是圆形的，这是大家公认的、最合适的形状，而你非要发明另一种形状的轮子，这种行为就叫「重复发明轮子（Reinventing the wheel）」，即「造轮子」——  明知道你做的不可能比前辈做得更好，却仍然坚持要做。在计算机领域，我们将封装好的组件、库，叫作轮子。因为它可以拿来直接用，就能实现对应的功能。对于产品设计，也有类似的情况。在我们不熟悉的业务领域、产品领域，市面上可能已经有非常成熟的解决方案和产品。在前人经验上进行产品设计，常有事半功倍的效果。

👀 在学习借鉴现有产品/方案时可参考下述思路：

关于模板

excel 模板参考语雀产品组。 ➡️ 传送门