需求分析报告的价值在于把“大家以为说清楚了”的内容变成可核对、可追踪的文字。本文提供一份可直接复制使用的空白模板，覆盖业务问题、角色场景、功能与非功能需求、规则约束、冲突澄清和可行性判断，并配套字段说明、必填规则与完整填写示例。模板可放入文档工具使用，也可以在ONES Wiki中通过页面模板库创建制式化文档，让需求条目与澄清记录和项目互相对应。
要点总览（TL;DR）
- 模板按“基本信息—业务问题—角色场景—需求清单—规则约束—边界—可行性—冲突澄清”九个区块组织，可整表复制到文档或表格工具使用。
- 填写顺序从业务问题与衡量指标开始，再确定角色场景，逐条登记功能需求并写清验收口径，最后汇总可行性判断与待澄清项。
- 功能需求的编号、描述、优先级、验收口径，以及业务问题、角色场景、范围边界属于必填项；缺失时报告停留在草稿，不进入评审。
- 新建、变更、优化三类需求的字段取舍不同：新建类最全，变更类突出差异与回归范围，优化类可简化角色场景但保留验收口径。
- 模板本身需要版本记录和季度回顾，新增字段以评审中反复被追问的信息为依据，旧版本报告保留原样。
可复制空白需求分析报告模板
下面这张表是全文的主交付物，可直接复制到文档或表格工具中填写。建议按“基本信息—业务问题—角色场景—需求清单—规则约束—边界—可行性—冲突澄清”的顺序填写，前一区块未写清时不要急着展开后一区块。
一、报告基本信息
| 字段 | 填写内容 |
|---|---|
| 项目/产品名称 | |
| 需求名称 | |
| 报告版本 | V0.1（初稿）/ V1.0（评审通过） |
| 编写人 | |
| 参与澄清人 | |
| 编写日期 | |
| 评审状态 | 草稿 / 待评审 / 评审中 / 已通过 / 已驳回 |
| 关联需求编号 |
二、业务问题与目标
| 字段 | 填写内容 |
|---|---|
| 业务背景 | |
| 当前问题 | |
| 问题影响 | 影响对象、影响范围、发生频率 |
| 期望目标 | |
| 衡量指标 | 指标名称、当前值、目标值、统计口径 |
| 不解决的后果 |
三、角色与使用场景
| 角色 | 角色说明 | 使用场景 | 触发条件 | 期望结果 | 使用频率 |
|---|---|---|---|---|---|
四、功能需求清单
| 需求编号 | 需求描述 | 对应角色/场景 | 优先级 | 验收口径 | 需求来源 | 备注 |
|---|---|---|---|---|---|---|
| FR-01 | 高/中/低 | |||||
| FR-02 |
五、非功能需求
| 编号 | 类别 | 需求描述 | 指标与口径 | 验证方式 | 优先级 |
|---|---|---|---|---|---|
| NFR-01 | 性能 | ||||
| NFR-02 | 安全 | ||||
| NFR-03 | 可用性 | ||||
| NFR-04 | 兼容性 |
六、业务规则与约束
| 编号 | 类型 | 规则/约束内容 | 适用范围 | 来源 | 例外情况 |
|---|---|---|---|---|---|
| BR-01 | 业务规则 | ||||
| CT-01 | 约束 |
七、范围边界与不做事项
| 字段 | 填写内容 |
|---|---|
| 本期范围 | |
| 明确不做 | |
| 后续可能纳入 | |
| 依赖的外部系统/团队 |
八、可行性判断
| 维度 | 判断结论 | 依据 | 风险与前提 |
|---|---|---|---|
| 业务可行性 | 可行/有条件可行/不可行 | ||
| 技术可行性 | |||
| 成本可行性 | |||
| 时间可行性 |
九、需求冲突与待澄清问题
| 编号 | 问题/冲突描述 | 涉及需求编号 | 澄清责任人 | 期望澄清时间 | 当前状态 | 结论 |
|---|---|---|---|---|---|---|
| Q-01 | 待澄清/澄清中/已关闭 |
模板字段说明：每个字段填什么、怎么判断填对了
同一份模板被产品、开发、测试和业务方共同使用时，字段口径不一致会让报告失去核对价值。下表按模板区块逐项说明填写要求，判断标准统一为“另一位同事只看这一格能否理解并复核”。
| 区块 | 字段 | 填写口径 | 填对的判断标准 |
|---|---|---|---|
| 基本信息 | 报告版本 | 初稿用V0.x，评审通过后升为V1.0，之后每次实质修改递增 | 版本号与变更记录能对应，评审时能说清当前是哪一版 |
| 基本信息 | 评审状态 | 按草稿、待评审、评审中、已通过、已驳回五档填写 | 状态与最近一次评审结论一致，不出现“已通过”但仍有未关闭澄清项 |
| 业务问题 | 当前问题 | 描述现状与期望之间的差距，写清发生在谁身上、什么环节 | 不出现“体验不好”“效率低”这类无法核对的表述 |
| 业务问题 | 衡量指标 | 写指标名称、当前值、目标值和统计口径 | 指标可在上线后取数验证，口径不依赖个人理解 |
| 角色场景 | 使用场景 | 按“谁在什么条件下做什么、期望得到什么”描述 | 一个场景对应一类角色和一个明确触发条件 |
| 功能需求 | 需求编号 | 按FR-序号编排，同一需求在全文引用时沿用同一编号 | 编号唯一，冲突项和澄清项能通过编号回指 |
| 功能需求 | 需求描述 | 写系统应提供的行为和结果，一条需求只表达一件事 | 描述中不混入实现方案，可被拆成验收条件 |
| 功能需求 | 优先级 | 按高、中、低三档，高表示本期必须交付 | 优先级与范围边界中的“本期范围”一致 |
| 功能需求 | 验收口径 | 写可观察的通过条件，包括输入、操作和预期结果 | 测试人员据此能写出测试用例，无需再追问 |
| 功能需求 | 需求来源 | 记录提出人、访谈、反馈渠道或关联单据 | 后续追溯时能找到原始提出记录 |
| 非功能需求 | 类别 | 按性能、安全、可用性、兼容性等类别归类，一类一行 | 类别与指标口径匹配，不把业务规则写进非功能表 |
| 非功能需求 | 指标与口径 | 写清数值、单位、统计时段和测量条件 | 指标可测量，条件明确，例如并发量与响应时间的对应关系 |
| 规则约束 | 规则/约束内容 | 业务规则写“在什么条件下必须/禁止怎样”，约束写外部限制 | 规则可判定真假，约束注明来源方 |
| 规则约束 | 例外情况 | 写明规则不适用的场景及审批方式 | 例外有明确边界，不形成“视情况而定”的模糊地带 |
| 范围边界 | 明确不做 | 逐条列出本期不实现的内容 | 与功能需求清单无重叠，评审时各方无异议 |
| 可行性 | 判断结论 | 按可行、有条件可行、不可行三档，并写依据 | 结论有依据支撑，有条件可行的写清前提条件 |
| 冲突澄清 | 问题描述 | 写清冲突双方各自的主张和分歧点 | 不看上下文也能理解争的是什么 |
| 冲突澄清 | 责任人与期限 | 指定一名澄清责任人和期望澄清时间 | 责任人为具体个人，期限为具体日期 |
字段说明与空白模板保持一一对应：模板中出现的每一列，在上表中都能找到填写口径；上表没有解释的字段，说明该字段暂不需要，可从模板中删去。需求条目较多时，功能需求表可按模块拆成多张子表，编号规则保持不变。
必填与选填：哪些字段缺失就不能进入评审
必填字段的作用是保证报告具备被评审的最低条件。缺失必填字段时，报告停留在草稿状态，不进入评审排期；选填字段按需求类型和风险程度取舍，缺失不影响评审，但需要在报告中注明“未填原因”。
| 字段 | 必填/选填 | 理由 | 缺失时的处理 |
|---|---|---|---|
| 项目/需求名称、版本、编写人、日期 | 必填 | 缺少基本信息无法确认报告归属和时效 | 补齐后重新提交 |
| 评审状态 | 必填 | 决定报告处于哪个环节 | 默认填“草稿” |
| 业务背景、当前问题、期望目标 | 必填 | 没有业务问题，需求无法判断价值 | 退回补充，不进入评审 |
| 衡量指标 | 必填（新建类需求） | 用于上线后验证目标是否达成 | 确实无法量化时，写明替代验证方式并经评审确认 |
| 角色与使用场景 | 必填 | 需求描述缺少使用主体时无法验收 | 至少填写一个主要角色和一个核心场景 |
| 功能需求编号、描述、优先级、验收口径 | 必填 | 这四项构成可执行的需求条目 | 任一缺失则该条需求不纳入本期范围 |
| 需求来源 | 选填 | 便于追溯，不影响需求本身成立 | 可后补 |
| 非功能需求 | 必填（涉及性能、安全、合规时） | 遗漏会导致上线后返工 | 由技术负责人确认无相关要求后可注明“不涉及” |
| 业务规则与约束 | 必填（存在规则判断时） | 规则缺失会造成实现偏差 | 在澄清项中登记并指定责任人 |
| 范围边界与不做事项 | 必填 | 防止范围蔓延，统一各方预期 | 未填写视为范围未确认，不进入评审 |
| 可行性判断 | 必填（进入排期前） | 不可行或有条件可行的需求需要提前决策 | 由技术、业务共同补充结论 |
| 冲突与待澄清项 | 必填（存在未决问题时） | 未决问题带入开发会放大返工成本 | 无未决问题时填“无” |
| 参与澄清人、使用频率、后续可能纳入 | 选填 | 辅助信息，按团队习惯填写 | 可空缺 |
不同需求类型的字段取舍可以按以下方式处理：新建类需求字段最全，业务问题、衡量指标、范围边界和可行性判断都需要填写；变更类需求重点填写变更前后的差异、受影响的需求编号和回归范围，业务背景可引用原报告；优化类需求可以简化角色场景，但验收口径和衡量指标仍需保留，用来说明优化前后的对比。三类需求共用同一套编号规则，便于在需求清单中统一检索。
填写示例：一份完整的需求分析报告怎么填
以下示例为演示情景，用于说明各字段的填写方式，不代表真实项目数据。示例背景：某企业服务团队的客户成功经理需要在续约前集中查看客户近半年的工单情况，目前需要逐个系统查询并手工汇总。
业务问题与目标
| 字段 | 示例内容 |
|---|---|
| 业务背景 | 客户成功团队在续约季集中处理客户健康度评估，工单数据分散在服务系统中 |
| 当前问题 | 客户成功经理需逐个客户查询工单并手工整理，单个客户平均耗时约20分钟 |
| 问题影响 | 影响续约季约60家重点客户，评估启动时间被推迟，数据口径不一致 |
| 期望目标 | 在客户详情页集中展示近半年工单汇总，支持按状态和紧急程度筛选 |
| 衡量指标 | 单个客户评估准备时间从约20分钟降至5分钟以内，统计口径统一为工单创建时间 |
角色场景与功能需求
| 角色 | 使用场景 | 触发条件 | 期望结果 |
|---|---|---|---|
| 客户成功经理 | 续约前评估客户健康度 | 客户进入续约窗口期 | 一屏看到工单数量、未关闭工单和紧急工单 |
| 需求编号 | 需求描述 | 优先级 | 验收口径 | 需求来源 |
|---|---|---|---|---|
| FR-01 | 客户详情页展示近半年工单汇总，含总数、未关闭数和紧急数 | 高 | 选择任一客户，页面在3秒内展示三项统计，数值与工单列表筛选结果一致 | 客户成功团队访谈 |
| FR-02 | 支持按工单状态和紧急程度筛选汇总数据 | 中 | 切换筛选条件后统计数值同步更新，清空筛选恢复默认 | 客户成功团队访谈 |
非功能需求、规则与边界
| 编号 | 类别 | 需求描述 | 指标与口径 |
|---|---|---|---|
| NFR-01 | 性能 | 汇总数据加载速度 | 在50家客户并发查看时，页面首屏加载不超过3秒 |
| NFR-02 | 安全 | 数据可见范围 | 仅客户负责人及其上级可查看该客户工单汇总 |
| BR-01 | 业务规则 | 统计范围 | 仅统计工单创建时间在近180天内的记录，已删除工单不计入 |
| CT-01 | 约束 | 数据来源 | 工单数据以服务系统为准，本期不新建工单存储 |
| 字段 | 示例内容 |
|---|---|
| 本期范围 | 客户详情页工单汇总展示与筛选 |
| 明确不做 | 工单详情页改造、工单导出、跨客户对比报表 |
| 后续可能纳入 | 按产品线维度的工单趋势图 |
| 依赖的外部系统/团队 | 服务系统提供查询接口，需服务系统团队配合联调 |
可行性判断与待澄清项
| 维度 | 判断结论 | 依据 | 风险与前提 |
|---|---|---|---|
| 业务可行性 | 可行 | 客户成功团队已确认使用方式 | 需在续约季前上线 |
| 技术可行性 | 有条件可行 | 服务系统已有查询接口 | 接口需支持按客户和时间范围批量查询 |
| 成本可行性 | 可行 | 复用现有页面与接口 | 联调工作量需技术负责人评估 |
| 时间可行性 | 有条件可行 | 依赖服务系统排期 | 接口联调时间未确认 |
| 编号 | 问题/冲突描述 | 涉及需求 | 澄清责任人 | 期望澄清时间 | 状态 |
|---|---|---|---|---|---|
| Q-01 | “紧急工单”的判定标准尚未统一，服务系统与客户成功团队口径不同 | FR-01 | 服务系统产品负责人 | 示例日期 | 待澄清 |
| Q-02 | 上级查看下属客户数据是否需要额外授权 | NFR-02 | 安全负责人 | 示例日期 | 澄清中 |
这份示例的填写顺序是：先写业务问题与衡量指标，再确定角色场景，然后逐条登记功能需求并给出验收口径，接着补充非功能需求、规则约束和范围边界，最后汇总可行性判断和待澄清项。实际填写时，待澄清项往往在写需求的过程中不断出现，及时登记比事后回忆更可靠。
模板的调整与维护方法
模板用上一两个需求周期后，会出现字段冗余或缺失的信号。调整的原则是：字段服务于判断，新增字段必须对应一个具体的填写动作或决策点，合并字段必须保证信息不丢失。
新增或合并字段的判断标准
- 连续两个以上需求在评审中被追问同一类信息，而模板中没有对应字段，考虑新增。
- 某字段连续多个需求都填“无”或空白，且不影响评审结论，考虑合并或删除。
- 两个字段的填写内容高度重复，保留信息更完整的一个，另一个并入说明列。
- 新增字段前先确认由谁填写、在哪个环节填写，无人负责的字段不进入模板。
版本管理与变更记录
模板本身也需要版本记录。建议在模板文档末尾附一张变更记录表，每次调整记录变更内容、原因、影响范围和生效日期，旧版本报告保留原样，不追溯改写。
| 模板版本 | 变更内容 | 变更原因 | 生效日期 | 影响范围 |
|---|---|---|---|---|
| V1.0 | 初始版本 | — | 全部需求 | |
| V1.1 |
与评审、建模环节的衔接边界
需求分析报告解决的是“需求是什么、为什么做、做到什么程度”，结构化建模（如流程建模、数据建模）和正式评审的质量检查分别由对应环节承担。模板中的验收口径和待澄清项可以作为评审输入，评审结论回写到报告的评审状态和澄清结论中，形成闭环。在ONES中，需求条目可以在需求管理中跟踪状态，分析报告通过ONES Wiki的页面模板库一键创建，页面组关联项目后需求与文档互相对应；文档实时同步并记录页面版本，支持随时查看与回滚，便于在多次澄清后对照历史版本。涉及音视频访谈记录或大量用户反馈时，ONES Assistant可提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入，具体可用范围以实际开通情况为准。
定期回顾的简单做法
每个季度抽取3到5份已完成的报告，检查三件事：必填字段是否在评审前填齐、待澄清项是否在开发启动前关闭、验收口径是否被测试直接使用。三项都达标说明模板运行良好；某一项反复出问题，就针对对应字段调整说明或必填规则。回顾结论记入变更记录表，避免模板在无人维护中逐渐失效。
常见问题
需求分析报告和需求规格说明书有什么区别，模板能通用吗？
需求分析报告侧重说明需求从哪里来、解决什么业务问题、做到什么程度，以及还有哪些未决问题；需求规格说明书更侧重对已确认需求的完整、结构化描述。本文模板覆盖前者，功能需求清单部分可以迁移到规格说明书中使用。如果团队两者都写，建议分析报告在前、规格说明在后，分析报告中的需求编号在规格说明书中沿用，避免同一需求出现两套编号。
需求条目很多时，一张功能需求表放不下怎么办？
可以按模块或业务域拆成多张子表，编号规则保持不变，例如按“订单-FR-01”“结算-FR-01”的方式加前缀区分。拆表后需要在报告开头补一张需求索引，列出各子表对应的模块和编号区间，方便评审时按编号回指。非功能需求和业务规则表通常不需要拆，保持一张表更便于整体核对。
待澄清问题一直没结论，报告能先进入评审吗？
可以进入评审，但需要在报告中如实标注状态，并保证每条未决问题都有具体责任人和期望澄清时间。评审时把未决问题作为单独议题讨论，明确是本期解决还是移出范围。需要避免的是评审状态填“已通过”而澄清项仍处于待澄清，这会让后续开发按各自理解推进。若未决问题涉及核心业务规则或验收口径，建议先澄清再排期。
小团队需求简单，也要填满整张模板吗？
不必。必填字段保证报告可被核对，选填字段按需填写。需求简单时，角色场景可以只写一个主要角色和一个核心场景，可行性判断可以合并成一段结论，但业务问题、功能需求的编号与验收口径、范围边界仍建议保留，这几项直接决定开发和测试能否对齐。模板调整后把删减的字段和原因记入变更记录，后续需求变复杂时可以恢复。
用ONES承载这份模板时，报告和需求条目怎么对应？
可以在ONES Wiki的页面模板库中把这份模板做成制式化文档，通过页面组关联项目，让分析报告与项目内的需求互相对应；文档实时同步并记录页面版本，多次澄清后可以对照历史版本查看与回滚。需求条目的状态跟踪放在需求管理中，报告中的需求编号与系统中的条目编号保持一致即可。涉及访谈录音或大量用户反馈时，ONES Assistant可提炼要点、待澄清问题与拆解建议，具体可用范围以实际开通情况为准。
