需求提报人需要提供三类信息：背景、需求描述和验收信息。背景说明问题从哪里来、影响谁；需求描述说明要达成什么、边界在哪；验收信息说明怎样算完成、由谁确认。判断标准只有一条：受理人和其他协作角色能否据此复现问题、判断完成与否。信息不足时，提报人应标注待补项并指定补充责任人，让需求先进入受理流程，再逐步补齐。
要点总览（TL;DR）
- 需求提报人需要提供背景、需求描述和验收信息三类内容，判断标准是受理人和其他协作角色能否据此复现问题、判断完成与否。
- 背景段写业务场景、当前做法、问题表现和影响范围，写到未参与业务的人能看懂问题如何发生即可用。
- 需求描述段写目标、边界和不做的部分，让研发或实施人员能判断本次范围与工作量边界。
- 验收信息段写验收标准、验收方式、验收人和确认时点，每条标准要能让验收人直接给出通过或不通过的结论。
- 提报人标注待补项并指定补充责任人，受理人做完整性检查，验收人在评审前确认验收标准可判定。
提报信息清单：背景、需求与验收三段怎么填
提报内容按背景、需求描述、验收信息三段组织，每段承担不同的回答任务。三段分开写，避免把现状、目标和验收条件混在同一段里，受理人核对时也更容易定位缺口。
背景段：说明问题从哪里来
背景段回答“为什么现在要提这个需求”。填写时覆盖四项内容：业务场景、当前做法、问题表现、影响范围。业务场景写清在什么业务环节、什么角色执行什么任务时遇到问题；当前做法描述现在如何完成这件事，包括使用的系统、表单或人工步骤；问题表现写可观察的事实，例如耗时、出错频率、重复录入次数、信息缺失导致返工；影响范围说明涉及哪些部门、岗位、业务量或时间窗口。
背景段写到“未参与该业务的人能看懂问题如何发生”即可用。判断方法很简单：把背景段交给一位不熟悉该业务的同事，对方能否说出问题发生在哪一步、影响哪些人。如果只能读出“效率低”“体验不好”这类结论，说明事实还不够。
需求描述段：说明要达成什么、不做什么
需求描述段包含目标、边界和不做的部分。目标写期望达成的业务结果，尽量落到可观察的状态，例如“巡检异常在发现后当班内完成上报并生成处理记录”。边界说明本次需求覆盖的业务环节、角色和使用范围，例如只覆盖某类设备的日常巡检，还是同时覆盖临时巡检。不做的部分同样要写，例如本次不改变审批层级、不接入外部设备数据、不调整现有报表口径。
边界和不做的部分常被省略，却是后续减少争议的关键。需求进入评审时，团队需要知道哪些内容属于本次范围，哪些留待后续处理。需求描述写到“研发或实施人员能据此判断工作量边界”即可用；如果读完仍不清楚哪些场景在范围内，说明边界还需要补充。
验收信息段：说明怎样算完成
验收信息包含四项：验收标准、验收方式、验收人、确认时点。验收标准写成可判定的条件，避免“操作更方便”“响应更及时”这类无法核对的表述。可用的写法包括具体结果、数据口径和异常处理要求，例如“巡检记录提交后生成唯一编号”“异常项在列表中按设备与时间可筛选”“断网情况下可暂存，恢复后自动提交”。验收方式说明如何验证，例如按场景逐条演示、用一批历史数据试跑、由业务人员在测试环境完成一轮真实操作。验收人写明具体角色或姓名，确认时点写明在哪个节点确认，例如提测后几个工作日内完成验收、上线前完成最终确认。
验收标准写到“验收人自己按条目就能给出通过或不通过”即可用。若一条标准需要验收人临场解释才能判断，应拆成更具体的条件，或补充判定口径。
| 信息段 | 必填内容 | 可用标准 |
|---|---|---|
| 背景 | 业务场景、当前做法、问题表现、影响范围 | 未参与业务的人能复现问题发生过程并识别影响对象 |
| 需求描述 | 目标、边界、不做的部分 | 研发或实施人员能判断本次范围与工作量边界 |
| 验收信息 | 验收标准、验收方式、验收人、确认时点 | 验收人按条目即可给出通过或不通过的结论 |
从提报到受理：提报人、受理人与验收人的分工
需求从提报到进入后续环节，至少涉及三个角色。分工清楚，信息缺口才能在受理环节被拦住，避免带着模糊的验收条件进入评审和开发。
提报人负责提供背景、需求描述和验收信息，并对暂时无法确定的内容标注“待补”，写明补充责任人和预计补充时间。提报人的交付物是一份三段完整或待补项明确的提报记录。提报人不必独自解决所有信息，但需要把缺口显性化，而不是用模糊表述掩盖。
受理人负责完整性检查。受理人按信息清单逐项核对：背景是否有可观察的问题事实，需求描述是否写明边界和不做的部分，验收信息是否包含四项内容。发现缺口时退回提报人补充，并说明缺的是哪一项、补充到什么程度可以再次提交。受理人的交付物是受理结论：进入下一环节，或退回补充并附缺口清单。退回时只列缺口，不替提报人改写业务事实。
验收人负责确认验收标准可判定。验收人通常是业务侧对结果负责的角色，需要在需求进入评审前确认：验收标准是否覆盖关键业务结果，验收方式是否可执行，确认时点是否与业务节奏匹配。验收人的交付物是对验收信息的确认意见，包括认可、要求修改或补充判定口径。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 提报人 | 提供背景、需求描述与验收信息，标注待补项及责任人 | 三段式提报记录 | 提交提报时 |
| 受理人 | 完整性检查，退回补充或确认受理 | 受理结论与缺口清单 | 收到提报后的受理环节 |
| 验收人 | 确认验收标准可判定、验收方式可执行 | 验收信息确认意见 | 需求进入评审前 |
这套分工可以在工具中落地。以 ONES 为例，业务团队可通过工单收集和整理来自各方的反馈，处理工单并转化为需求，整理出产品 Backlog；团队也可根据实际场景自定义工作流，让提报、受理、补充、确认按状态流转。提报信息作为工作项字段或描述承载，受理人依据状态和字段判断是否退回，验收人则在评审前对验收标准给出确认意见。具体字段配置以团队实际设置为准。
一份填写示例：设备巡检需求如何写清背景与验收
以下示例为演示情景，用于说明三段信息的写法，不代表真实项目数据。
背景段示例
“设备巡检由各班组按周执行，目前巡检人员在纸质表单上记录设备编号、巡检项和异常情况，回到班组后由班长录入 Excel 汇总。近两个月出现三类问题：纸质表单字迹不清导致录入返工；异常项从发现到汇总平均延迟一个班次；同一设备在不同班组的巡检记录分散，查询历史情况需要翻多份表格。影响范围为三个班组、约 120 台设备，每周产生约 40 份巡检记录。”
这样写的理由是：业务场景、当前做法、问题表现和影响范围都有具体对象和数量。受理人不需要追问“哪些班组”“多少设备”，就能判断问题规模和后续验证范围。
需求描述与边界示例
“目标：巡检人员在现场用移动端完成巡检记录提交，异常项提交后当班内可见并生成待处理记录；班长可按设备、班组、时间查询历史巡检记录。边界：覆盖日常巡检和临时巡检两类场景，覆盖三个班组和现有 120 台设备。不做的部分：本次不改变巡检项模板内容，不接入设备传感器数据，不调整现有异常处理审批层级。”
这样写的理由是：目标落到可观察的业务状态，边界明确了场景、角色和范围，不做的部分提前排除了容易在评审时被追加的内容。研发人员据此可以判断本次需要改动哪些环节，验收人也能据此确认验收范围。
验收标准与验收方式示例
“验收标准：一，巡检人员提交记录后生成唯一编号，编号可按班组和时间检索；二，异常项提交后当班内出现在待处理列表，列表可按设备和时间筛选；三，断网时记录可暂存，恢复网络后自动提交且不重复生成记录；四，班长查询某台设备近三个月记录，结果包含巡检时间、巡检人和异常项。验收方式：由三个班组各选一名巡检人员，在测试环境完成一轮真实巡检并提交记录，验收人按上述四条逐项核对。验收人：业务侧巡检负责人。确认时点：提测后三个工作日内完成验收，上线前完成最终确认。”
这样写的理由是：每条验收标准都有可观察的结果或可执行的操作，验收方式说明了用什么场景、哪些人参与，验收人和确认时点明确。验收人不需要再解释“怎样算通过”，测试人员也可以据此设计用例。
提报前的完成检查
提报人提交前按以下清单逐项核对。全部通过即可提交进入受理；存在未通过项时，先补充或标注待补，再提交。
背景信息检查项
- 业务场景写明了具体环节、执行角色和触发条件。
- 当前做法描述了现有步骤和使用的表单、系统或人工方式。
- 问题表现是可观察的事实，包含发生频率、耗时、返工或差错等具体描述。
- 影响范围写明了涉及部门、岗位、设备或业务量。
验收信息检查项
- 每条验收标准都能由验收人直接判断通过或不通过。
- 验收标准覆盖了需求目标中的关键业务结果。
- 验收方式写明了验证场景、参与角色和环境。
- 验收人和确认时点均已明确。
待补项与责任人检查
- 暂时无法确定的信息已标注“待补”，未用模糊表述替代。
- 每个待补项都指定了补充责任人和预计补充时间。
- 待补项不影响受理人理解问题背景和验收方向。
不通过时的处理方式
检查未通过时，按缺口类型处理：背景事实不足的，提报人补充现场信息或找业务当事人确认；验收标准无法判定的，提报人与验收人沟通判定口径，拆成更具体的条件；边界不清的，提报人写明本次覆盖范围和不做的部分。受理人退回时附缺口清单，提报人按清单补充后再次提交。待补项在受理后按约定时间补齐，补齐前需求可停留在待补充状态，不进入评审。
常见问题
提报时有些信息确实拿不到，需求还能提交吗？
可以提交，前提是把缺口显性化。提报人对暂时无法确定的内容标注“待补”，写明补充责任人和预计补充时间，再提交进入受理环节。受理人核对时，只要待补项不影响理解问题背景和验收方向，就可以先受理，需求停留在待补充状态，按约定时间补齐后再进入评审。
需要避免的是用模糊表述掩盖缺口，例如把验收标准写成“操作更方便”，这类表述在受理环节无法核对，后续评审和测试也缺少判定依据。
验收标准由提报人写还是验收人写？
通常由提报人起草，验收人确认。提报人更了解业务场景和期望结果，先写出初步的验收标准和验收方式；验收人作为对结果负责的角色，在需求进入评审前确认这些标准是否覆盖关键业务结果、是否可判定、确认时点是否与业务节奏匹配。
如果验收人认为标准无法判定，应要求提报人拆成更具体的条件或补充判定口径，而不是等到测试阶段再解释“怎样算通过”。
背景信息写多详细才算够？
判断方法不是看字数，而是看一位不熟悉该业务的同事能否读出问题发生在哪一步、影响哪些人。背景段覆盖业务场景、当前做法、问题表现和影响范围四项，问题表现尽量写可观察的事实，例如耗时、出错频率、重复录入次数或返工情况。
如果背景段只能读出“效率低”“体验不好”这类结论，说明事实还不够，需要补充现场信息或找业务当事人确认。
受理人退回补充时应该提供什么？
受理人退回时附缺口清单，逐项说明缺的是背景、需求描述还是验收信息，以及补充到什么程度可以再次提交。退回意见只列缺口，不替提报人改写业务事实，因为业务事实需要提报人或业务当事人确认。
提报人按清单补充后再次提交，受理人重新核对。这样缺口在受理环节被拦住，不会带着模糊的验收条件进入评审和开发。
提报和受理的交接在工具里怎么承载？
可以把提报信息作为工作项的描述或字段承载，用状态区分待受理、待补充、已受理等环节。以 ONES 为例，业务团队可通过工单收集和整理来自各方的反馈，处理工单并转化为需求，整理出产品 Backlog；团队也可根据实际场景自定义工作流，让提报、受理、补充、确认按状态流转。受理人依据状态和字段判断是否退回，验收人在评审前对验收标准给出确认意见。具体字段配置以团队实际设置为准。
