需求分析报告要能支撑后续设计与评审，关键在于把业务问题、功能需求、非功能需求、规则约束、范围边界和待澄清项写清楚，并标明来源与确认状态。本文用一个假设的“员工差旅报销”情景，给出一份可直接参照填写的完整范例，再逐项解释填写依据和迁移方法。示例中的需求条目与待澄清项，也可以放在ONES中承载和流转。
要点总览（TL;DR）
- 一份可用的需求分析报告示例，应围绕具体业务场景写清业务问题、功能需求、非功能需求、业务规则与约束、范围边界、可行性初判和待澄清项。
- 功能需求按“一个可独立验收的动作”编号，标注优先级、来源和确认状态；非功能需求写成可验证表述并配验证方式。
- 业务规则是业务上必须遵守的判断逻辑，约束是方案必须服从的外部条件，两者分开记录，便于方案设计时分别处理。
- 待澄清项单独编号，写明影响的需求、确认人和状态；换场景时按“现象—目标—角色—需求—规则—边界—待定项”的顺序推导。
- 示例为假设情景，具体数值、规则和结论仅作写法参考，迁移时需按行业合规、组织规模和现有系统条件调整。
示例目标：这份需求分析报告要回答什么
这份示例要回答四个问题：业务上要解决什么问题、系统需要提供哪些能力、本期范围到哪里为止、哪些内容尚未确定。报告写完后，产品、业务、开发和测试应能据此判断需求是否具备进入方案设计的条件，而不是停留在“大概知道要做什么”。
示例情景设定如下，全文均标注为假设情景，不对应任何真实客户、实测结果或量化成效。
| 项目 | 示例设定 |
|---|---|
| 场景 | 某公司内部员工差旅报销流程线上化（示例） |
| 主要角色 | 报销申请人、直属主管、财务审核人员、系统管理员 |
| 业务目标 | 让员工提交报销更省事，让审批与审核有据可查，让报销进度对申请人可见 |
| 假设声明 | 本情景为演示用虚构设定，组织规模、现有系统、合规要求均为示例假设，不代表任何真实企业情况 |
需要区分示例与真实案例：真实项目的报告需要引用访谈记录、现有流程数据、制度文件等来源，并标注确认人；本文示例中的来源一律写为“示例假设”，用于演示字段写法，不能作为事实依据引用。
完整示例：员工差旅报销需求分析报告
以下为一份字段齐全、前后自洽的已填写报告范例。各条目编号在后续章节中会被引用。
一、业务问题与目标
现状（示例假设）：员工出差结束后，通过邮件提交票据照片和手工填写的报销单，主管在邮件中回复同意或退回，财务再逐单核对金额与制度。问题表现为：申请人无法查看当前处理到哪一步；票据缺失时往返沟通次数多；财务核对制度条款依赖个人经验。
目标写成可判断的表述：
- G1：申请人提交后能查看报销单当前所处环节与处理人。
- G2：提交时系统按制度校验必填票据与金额上限，缺项当场提示。
- G3：每笔审核动作留下处理人、时间与意见记录。
二、干系人与角色
| 角色 | 关注点 | 在报告中的参与方式 |
|---|---|---|
| 报销申请人 | 提交便捷、进度可见、退回原因清楚 | 需求来源，参与确认 |
| 直属主管 | 审批依据充分、批量处理 | 需求来源，参与确认 |
| 财务审核人员 | 制度校验准确、留痕完整 | 规则提供方，参与确认 |
| 系统管理员 | 组织架构与权限维护 | 约束提供方 |
三、功能需求清单
| 编号 | 需求描述 | 优先级 | 来源 | 确认状态 |
|---|---|---|---|---|
| FR-01 | 申请人可创建报销单，填写出差事由、起止日期、费用明细，并上传票据附件 | 高 | 示例假设：申请人访谈 | 已确认（示例） |
| FR-02 | 提交时按费用类型校验必填票据，缺失时阻止提交并提示具体缺项 | 高 | 示例假设：财务制度 | 已确认（示例） |
| FR-03 | 报销单按申请人所属部门路由至直属主管审批，主管可同意、退回并填写意见 | 高 | 示例假设：主管访谈 | 已确认（示例） |
| FR-04 | 主管审批通过后流转至财务审核，财务可核对金额并记录审核结论 | 高 | 示例假设：财务访谈 | 已确认（示例） |
| FR-05 | 申请人可查看报销单当前环节、处理人与历史处理记录 | 中 | 示例假设：申请人访谈 | 已确认（示例） |
| FR-06 | 支持按时间段、部门、状态筛选报销单列表 | 中 | 示例假设：财务访谈 | 待确认（示例） |
| FR-07 | 报销完成后向申请人发送站内通知 | 低 | 示例假设：团队讨论 | 待确认（示例） |
四、非功能需求
| 编号 | 类别 | 可验证表述 | 验证方式 |
|---|---|---|---|
| NFR-01 | 性能 | 在示例假设的日常并发下，报销单列表查询响应时间不超过3秒 | 测试环境压测（示例口径，需按实际规模调整） |
| NFR-02 | 安全 | 申请人只能查看本人报销单，主管只能查看本部门单据，越权访问被拒绝并记录 | 权限用例测试 |
| NFR-03 | 可用性 | 工作时间内系统可用，故障恢复后未完成单据状态不丢失 | 故障演练检查 |
| NFR-04 | 可追溯 | 每次审批与审核动作记录处理人、时间与意见，记录不可被普通用户修改 | 抽查操作日志 |
五、业务规则与约束
- BR-01：住宿费按城市类别设上限，超标需附说明并经上级审批（示例规则，具体标准以企业制度为准）。
- BR-02：票据缺失的报销单不能进入审批环节。
- BR-03：报销单退回后由申请人修改再提交，原审批记录保留。
- C-01：需对接现有组织架构数据，作为审批路由依据。
- C-02：本期不改变现行财务制度，系统只做校验与留痕。
六、范围边界
| 本期做 | 本期不做 |
|---|---|
| 报销单创建、提交、审批、财务审核、进度查看 | 与银行或支付系统对接打款 |
| 按制度做票据与金额校验 | 发票真伪自动查验 |
| 操作留痕与基础筛选 | 多维度报销统计分析报表 |
七、可行性初判
业务可行性：流程环节与现有审批习惯一致，改动集中在线上化与校验，业务方接受度预期较高（示例判断）。技术可行性：组织架构对接与附件存储属于常规能力，无特殊技术障碍（示例判断）。风险：制度上限规则若频繁调整，需要把规则配置化，否则每次调整都要改代码，这一点列入待澄清项。
八、待澄清问题与冲突记录
| 编号 | 问题或冲突 | 影响 | 待确认人 | 状态 |
|---|---|---|---|---|
| Q-01 | 住宿费上限规则由谁维护，是否需要配置界面 | 影响FR-02实现方式 | 财务审核人员 | 待澄清（示例） |
| Q-02 | FR-06筛选维度是否包含费用类型 | 影响列表设计 | 财务审核人员 | 待澄清（示例） |
| Q-03 | 跨部门借调人员的审批路由归属 | 影响FR-03路由规则 | 系统管理员 | 待澄清（示例） |
逐项解释：每个字段为什么这样填
业务问题部分先写现象，再写目标。现象描述“申请人看不到进度、往返沟通多、核对依赖个人经验”，这些是可以被访谈和观察证实的事实；目标G1至G3则写成能被检查的状态，例如“能查看当前环节”“缺项当场提示”“留下处理记录”。把目标写成“提升报销体验”这类判断，后续无法验证是否达成，也无法据此划分优先级。
功能需求的编号与粒度按“一个可独立验收的动作”来切分。FR-01到FR-05各自对应一个可测试的行为，编号稳定，便于在评审、设计和测试用例中引用。粒度太粗会把多个动作塞进一条，验收时说不清做到哪算完成；粒度太细则会把界面元素写成需求。优先级用高、中、低三档，并说明判断依据：高对应流程主干，缺了流程走不通；中对应效率改善；低对应体验补充。
非功能需求写成可验证的表述，并配验证方式。NFR-01给出响应时间与并发前提，同时注明这是示例口径、需按实际规模调整；NFR-02把权限写成“谁能看什么、越权如何处理”；NFR-04把可追溯写成“记录哪些字段、谁能修改”。只写“性能良好”“安全可靠”无法在测试阶段判定通过与否。
业务规则与约束的区别在于：业务规则是业务上必须遵守的判断逻辑，如BR-01的金额上限、BR-02的票据前置条件；约束是方案必须服从的外部条件，如C-01的组织架构对接、C-02的不改变现行制度。把两者混在一起，容易在方案设计时把制度问题当成技术问题处理。
范围边界用“本期做/本期不做”两列对照，每一项都写具体对象，例如“与银行或支付系统对接打款”而不是笼统的“外部集成”。待澄清项单独编号，写明影响哪个需求、找谁确认、当前状态，避免在正文里用模糊措辞掩盖未定事项。示例中Q-01直接影响FR-02的实现方式，因此必须与需求条目建立引用关系。
当报告中的需求条目、待澄清问题和确认状态需要多人协作维护时，可以把它们放入ONES的工作项与Wiki页面中流转：需求条目对应可追踪的工作项，待澄清项记录负责人和状态，确认结论回写到文档，评审时按同一份内容核对。ONES Assistant可围绕PRD质量检查和需求智能生成提炼要点、待澄清问题与拆解建议，帮助团队加快需求澄清和录入；具体入口与配置以实际产品为准。
可迁移规律：换一个业务场景怎么套用
换场景时，填写顺序比字段名称更重要。建议按以下顺序推导，每一步都产出可检查的内容：
- 先写现状现象，每条现象注明来源（访谈、制度文件、系统日志或示例假设）。
- 把现象转成目标，每个目标写成可观察的状态，并对应至少一条功能需求。
- 按角色列出关注点，确定谁提供规则、谁参与确认。
- 按“一个可独立验收的动作”拆分功能需求，编号并标优先级。
- 为非功能需求补上验证方式，为业务规则标注适用条件。
- 用两列对照划定本期范围，把范围外事项写具体。
- 把所有未定事项编号，写明影响、确认人和状态。
假设与待确认项要有统一的标注习惯。本文示例统一使用“示例假设”“待确认（示例）”字样，真实项目可改为“来源：某次访谈记录”“状态：待业务确认”，关键是让读者一眼分辨哪些是已确认事实、哪些是推断。推断内容不要与确认内容混排在同一句里。
需求冲突的记录与升级路径要提前约定。示例中Q-01涉及规则维护方式，属于业务与技术的交叉问题，记录时写明影响的需求编号，由财务审核人员确认；若确认人之间意见不一致，升级到能对范围和制度拍板的角色，并在报告中保留冲突双方的意见，而不是只写最终结论。
报告完成后与后续工作的衔接边界要清楚：本报告回答“做什么、做到哪、还有什么没定”，结构化建模（如用例、流程模型、数据模型）和正式评审流程属于后续环节，报告中的需求编号可作为它们的输入。报告本身不替代评审记录，评审结论应回写到待澄清项的状态中。
适用边界：示例能用到什么程度
本文的差旅报销情景为假设设定，其中的组织规模、制度标准、并发口径、确认状态均为演示用内容，不代表任何真实客户、调查结果或实测成效。读者可以参照字段结构和写法，但不能把示例中的具体数值、规则或结论当作行业标准引用。
迁移到不同项目时需要调整的地方包括：行业合规要求（如票据与审计规定）、组织规模带来的审批层级与性能口径、现有系统的对接条件、制度变更频率决定的规则配置方式。涉及个人信息或财务数据的场景，安全与权限要求应按所在组织的制度重新确认，示例中的NFR-02只提供写法参考。
本文聚焦需求分析报告的填写示例，需求的结构化建模与表达方式、正式的需求评审与确认流程不在本文范围内，仅在衔接处简要提示。报告完成后的下一步动作是：把待澄清项逐条确认并更新状态，将已确认需求交给方案设计与评审，并把评审结论回写到报告中，形成可追溯的版本。
常见问题
示例中的需求条目和待澄清项，如何在实际项目中保持同步更新？
建议把需求条目和待澄清项分开维护，但建立引用关系：每条待澄清项写明影响哪个需求编号，需求条目上标注当前确认状态。确认结论产生后，先更新待澄清项状态，再回写需求描述，避免两处内容不一致。多人协作时，可以指定一名需求负责人统一维护编号和状态，评审前按同一份内容核对。需求条目和待澄清项也可以放入ONES的工作项与Wiki页面中流转，需求条目对应可追踪的工作项，待澄清项记录负责人和状态，确认结论回写到文档。
如果业务方无法给出明确的非功能指标，报告里应该怎么写？
先写清指标缺失这一事实，再给出待确认的假设口径。例如性能需求可以写成“在示例假设的日常并发下，列表查询响应时间不超过3秒”，并注明该口径需按实际规模调整；权限需求可以写成“申请人只能查看本人单据，越权访问被拒绝并记录”，这类表述不依赖具体数值也能验证。把无法确定的指标列入待澄清项，写明需要谁提供依据、影响哪些需求，比在正文里写“性能良好”更便于后续推进。
需求分析报告写完后，什么时候可以进入方案设计和评审？
判断标准是报告能否支撑后续决策：业务问题和目标可判断、功能需求有编号和优先级、非功能需求可验证、范围边界明确、待澄清项都有负责人和状态。主干流程相关的待澄清项如果仍未确认，通常需要先澄清再进入设计，否则方案可能建立在错误假设上。范围外事项和低优先级需求可以带着待定状态进入下一阶段，但要在报告中保留记录。结构化建模和正式评审属于后续环节，报告中的需求编号可作为它们的输入。
跨部门或跨团队的需求冲突，在报告中如何记录才不容易被忽略？
冲突单独编号，写明冲突双方各自的主张、影响的需求编号、需要谁拍板以及当前状态。记录时保留双方意见，不只写最终结论，这样后续复盘时能看清取舍依据。若确认人之间意见不一致，升级到能对范围和制度拍板的角色，并把升级过程写进状态更新。冲突未解决前，相关需求条目的确认状态保持待确认，避免被默认当作已定事项进入设计。
这份示例可以直接当作公司内部的需求分析报告模板使用吗？
可以把字段结构作为起点，具体内容需要按组织情况调整。示例中的组织规模、制度标准、并发口径和确认状态都是演示用假设，不对应任何真实客户或实测结果。迁移时要补充行业合规要求、现有系统对接条件、审批层级和制度变更频率等实际约束，涉及个人信息或财务数据的场景，安全与权限要求应按所在组织制度重新确认。示例提供的是写法参考，不构成行业标准或产品内置模板。
