需求分析的依据由五类材料构成：业务目标与问题背景、干系人诉求与使用场景、业务规则与约束条件、现有系统与数据现状、可验证的边界与可行性判断。缺少任何一类，需求条目都容易停留在转述层面。本文按“列清单—转条目—定角色—做检查”的顺序给出可执行步骤，并说明依据采集、条目登记和待确认问题跟踪如何在ONES需求管理中承载。
要点总览（TL;DR）
- 需求分析的依据分为五类：业务目标与问题背景、干系人诉求与使用场景、业务规则与约束、现有系统与数据现状、边界与可行性判断，每类回答不同的问题。
- 操作上按五步推进：先定范围，再按类别采集并登记来源，把依据拆成可判断真假的需求条目，识别冲突与缺口，最后确认并固定版本。
- 依据的提供人和确认人可以不同，但每类依据至少有一个明确责任人，待确认问题只指派一个责任人。
- 依据是否足够，用五项检查判断：来源与责任人、条目可追溯、冲突缺口已分派、边界与可行性有结论、确认记录与基线已形成。
- 依据清单、需求条目和待确认问题在ONES需求管理中保持关联，追溯关系不依赖个人记忆，检查时可按工作项状态核对。
需求分析要收集哪几类依据
依据分类的作用是让分析人员知道该找什么、每类材料回答什么问题。建议在项目启动时就按下面五类建立清单，每类下预留“来源、责任人、采集时间、状态”四列，后续步骤都在这份清单上推进。
| 依据类别 | 回答的问题 | 典型材料 |
|---|---|---|
| 业务目标与问题背景 | 为什么要做、做成什么样算成功 | 业务目标说明、问题现象记录、经营或运营数据、上级决策文件 |
| 干系人诉求与使用场景 | 谁在用、在什么情况下用、期望得到什么结果 | 访谈记录、现场观察笔记、工单与反馈汇总、角色清单 |
| 业务规则与约束 | 哪些规则必须遵守、哪些条件不能突破 | 制度文件、审批规则、计费或结算口径、合规要求、时间与预算约束 |
| 现有系统、数据与流程现状 | 现在怎么运转、数据在哪里、改动会影响什么 | 流程说明、系统清单与接口说明、数据字典、历史数据质量情况 |
| 边界与可行性判断 | 这次做到哪里、哪些先不做、技术上能否实现 | 范围说明、分期计划、技术预研结论、依赖方排期 |
五类依据之间存在依赖：业务目标决定范围边界，现状材料决定可行性结论，规则约束决定需求条目的验收口径。采集时不必严格按顺序，但整理时必须交叉核对，避免出现“目标写了、现状没查”的悬空条目。
按步骤把依据整理成可确认的需求输入
从零散材料到可确认的需求输入，可以按五步推进。每一步都明确输入、动作、输出和完成标志，便于判断进度。
第一步：明确分析范围与目标，输出范围说明
输入是业务目标材料和本次任务的委托说明。动作是与需求提出人确认本次分析覆盖的业务环节、涉及的组织与系统、明确不做的部分。输出是一页范围说明，包含目标、覆盖范围、排除项和关键时间点。完成标志是需求提出人对范围说明书面确认。
第二步：按类别采集依据并登记来源、时间、责任人
输入是范围说明和第一步建立的依据清单框架。动作是逐类走访或收集材料，每份材料登记提供人、提供时间和对应的责任角色；口头信息当场整理成记录并请提供人回看。输出是填满来源信息的依据清单和附件材料。完成标志是五类依据均有至少一条有效来源，且没有来源不明的条目。
第三步：把依据转成需求条目并标注依据出处
输入是依据清单。动作是把每条依据拆成可判断真假的陈述句，例如把“客户希望改地址方便些”转成“已支付未发货订单支持修改收货地址”。每条需求条目后标注依据编号，一条需求可以引用多条依据。输出是带来源标注的需求条目清单。完成标志是每条需求都能回溯到具体依据，且没有无出处的条目。
第四步：识别冲突、缺口与待确认问题
输入是需求条目清单。动作是横向比对：不同干系人的诉求是否矛盾、规则之间是否打架、现状材料是否支撑目标、边界是否覆盖了所有条目。发现的矛盾登记为冲突项，缺失的材料登记为缺口，需要对方决策的登记为待确认问题，并逐条分派责任人和期望回复时间。输出是冲突清单与待确认问题表。完成标志是所有冲突和缺口都有责任人和处理状态。
第五步：与干系人确认并形成基线输入
输入是需求条目清单和待确认问题表。动作是组织一次确认会，逐条过需求条目，对未决问题给出结论或明确挂起原因。输出是确认后的需求条目版本和确认记录。完成标志是关键干系人对条目内容无异议，挂起项有明确处理计划，版本号固定下来作为后续建模与评审的输入。
这五步中的登记、分派和版本固定属于管理动作，可以在ONES需求管理中用工作项承载：依据清单作为需求条目的关联记录，待确认问题建为独立工作项并指派责任人，确认后的条目版本作为基线保留。这样依据与需求条目之间的追溯关系不依赖个人记忆。
谁提供依据、谁确认依据：角色与交付物分工
依据无人负责是需求分析返工的主要原因。下表按角色列出主要职责、交付物和确认方式，实际项目中一人可兼多个角色，但每类依据至少要有一个明确的责任人。
| 角色 | 主要职责 | 交付物 | 确认方式 |
|---|---|---|---|
| 业务方与需求提出人 | 说明业务目标与问题背景，确认范围与优先级 | 目标说明、范围确认、优先级排序 | 范围说明与需求条目书面确认 |
| 需求分析人员 | 组织采集、拆分条目、维护追溯关系、跟踪待确认问题 | 依据清单、需求条目清单、冲突与问题表 | 提交确认会评审，版本归档 |
| 领域专家与一线使用者 | 提供业务规则细节和真实使用场景，指出例外情况 | 规则说明、场景描述、例外清单 | 回看访谈记录并签字或回复确认 |
| 技术与合规相关角色 | 提供系统与数据现状、技术可行性判断、合规约束 | 现状说明、接口与数据情况、可行性结论 | 技术评审意见或书面回复 |
分工落地时有两个细节值得注意：一是依据的提供人和确认人可以不同，例如一线使用者提供场景，业务负责人确认该场景是否属于本期范围；二是每条待确认问题只指派一个责任人，避免多方回复导致结论互相覆盖。
示例：一次订单改址需求如何补齐依据
以下为演示情景，用于说明依据清单如何转成需求条目和待确认问题。
业务目标与问题背景：客服反馈每月约有若干客户在支付后要求修改收货地址，当前只能取消重下，影响成交。业务方给出的目标是降低此类订单的取消率。
场景与干系人诉求：客户希望在发货前自行修改地址；客服希望能代客户修改并留痕；仓储希望修改信息能及时同步到待发货清单。
业务规则与约束：已发货订单不允许改址；改址涉及运费差额时需要重新计费；跨境订单受目的地限制。这些规则来自运营制度文件，由运营负责人提供。
系统与数据现状：订单系统记录了收货地址快照，仓储系统按固定周期拉取待发货订单；两系统之间没有地址变更的同步接口。该情况由技术负责人确认。
由依据推导出的需求条目与待确认问题：
- 需求条目：已支付未发货订单支持客户自助修改收货地址，依据为场景诉求与运营规则。
- 需求条目：客服可代客户改址，操作记录保留操作人与时间，依据为客服诉求与留痕要求。
- 需求条目：改址导致运费变化时触发补收或退还流程，依据为计费规则。
- 待确认问题：仓储同步采用接口实时推送还是缩短拉取周期，需技术负责人评估后回复。
- 待确认问题：跨境订单是否纳入本期范围，需业务方决策。
这个例子说明，依据补齐后需求条目自然带有出处，未决事项也能被单独识别和分派，而不是混在需求描述里等到开发阶段才暴露。
完成检查：依据是否足够支撑需求分析
进入建模与评审前，可用下面这份清单逐项核对。每项给出通过标准，全部通过即可认为依据足以支撑当前阶段的分析。
| 检查项 | 通过标准 |
|---|---|
| 每类依据是否有来源与责任人 | 五类依据均有至少一条有效来源，每条来源登记提供人与时间，每类有明确责任人 |
| 需求条目是否可追溯到依据 | 每条需求条目至少引用一条依据编号，抽查无出处条目为零 |
| 冲突与缺口是否已登记并分派 | 冲突清单和待确认问题表中每条都有责任人和处理状态，无长期未分派项 |
| 边界与可行性是否已有结论或明确待验证项 | 范围说明中的排除项有确认记录；技术可行性结论或待验证项已列明验证方式与时间 |
| 确认记录与基线是否形成 | 关键干系人确认记录可查，需求条目版本号固定，后续变更走版本管理 |
检查中发现某类依据薄弱时，回到第二步补充采集，而不是在条目层面猜测填补。依据清单、需求条目和待确认问题在ONES中保持关联后，这份检查可以直接按工作项状态核对，减少会前临时汇总的工作量。
常见问题
依据采集到一半，业务方又提出新的目标，应该怎么处理？
先把新目标登记为一条依据，注明提出人、时间和与原目标的关系，再判断它是否改变本次分析范围。如果改变范围，回到第一步更新范围说明并请需求提出人重新确认；如果不改变范围，把它列入后续分期或待确认问题，避免在条目层面临时扩大范围。关键是让目标变化有记录、有决策人，而不是直接混入现有需求条目。
口头访谈得到的信息能不能直接作为需求依据？
可以，但需要先整理成书面记录并请提供人回看确认。记录中写明提供人、时间、场景和原话要点，确认后再登记进依据清单。未经回看的口头信息容易在转成需求条目时失真，尤其是涉及规则例外和边界条件的内容，建议当场复述关键点或会后当天发出确认。
冲突项和待确认问题有什么区别，需要分开管理吗？
冲突项是两条或多条依据、需求条目之间已经出现矛盾，例如两个部门对同一规则的表述不一致；待确认问题是依据尚缺或需要对方决策才能继续。两者都需要责任人和处理状态，但冲突项通常需要协调后给出统一结论，待确认问题更偏向补充材料或等待决策。分开登记便于在确认会上分别处理，也方便检查时判断卡点类型。
依据已经比较充分，但技术可行性还没有结论，能否先进入建模？
可以带着明确的待验证项进入建模，但要在范围说明和需求条目中标注该条目的可行性状态、验证方式和预计完成时间。涉及可行性未定的条目，建模时宜保留备选方案或标注条件，避免把未验证的假设写成确定结论。检查清单中“边界与可行性是否已有结论或明确待验证项”这一项，允许待验证项存在，前提是验证安排已经明确。
小团队人手少，五类依据和角色分工要不要简化？
可以合并角色，例如需求分析人员同时承担部分领域专家的采集工作，但依据类别不建议省略。简化的是人和流程形式，例如用一份共享清单代替多份文档、用一次会议完成范围确认和条目确认；保留的是每类依据有来源、每条需求可追溯、每个未决问题有责任人。团队规模越小，越需要把依据和结论写下来，减少口头传递造成的返工。
