判定需求提报字段完整性，核心是先把“完整”定义清楚：按需求类型列出必填字段集，对每条需求逐字段判断是否“已填且有效”，全部通过才算完整；再按统计期计算完整率，并说明分母口径、条件必填和缺失值处理方式。本文给出一套可复算的判定规则与统计方法，适用于通过统一入口提交、进入受理环节的需求，帮助受理人和产品负责人定位表单与入口问题。
要点总览（TL;DR）
- 判定完整性先按需求类型定义必填字段集，再对每条需求逐字段判断“已填且有效”，全部通过才算完整。
- 完整率=完整需求数÷纳入统计需求总数×100%，分母剔除草稿、测试数据、重复提报和明确标记为服务请求的单据。
- 条件必填字段只在触发条件成立时参与判定，未触发不计缺失；字段为空记缺失、无法解析记无效，两者都算不通过。
- 结果按入口、需求类型、时间窗分组查看汇总报表与明细清单，并用抽样复核校验判定一致性。
- 完整率只说明字段填齐，不衡量需求价值、信息准确性和实现质量，不宜单独作为提报人考核依据。
评估目标：完整性要回答什么问题
完整性评估回答的是一个具体问题：这条需求提报的信息，是否足够让受理人判断来源、理解诉求并决定分流去向。它服务于受理环节的动作——信息够用就进入评估或排期，信息不足就退回提报人补全。把评估目标锁定在“提报信息是否够用”，后续的字段选择和判定标准才有稳定依据。
完整率作为汇总指标，用途是发现入口和表单设计中的问题。例如某个入口的完整率持续偏低，通常说明该入口的必填项设置过少、提示文案不清，或者提报人对字段含义理解不一致。它适合用来推动表单调整和填写指引优化，不适合用来评价需求本身的价值、优先级，也不反映需求实现后的质量。
评估结论主要有三类使用者：需求受理人依据单条判定决定是否退回补全；产品负责人依据分组完整率判断哪类需求、哪个入口的信息质量需要干预；入口维护者依据高频缺失字段调整表单必填项、字段说明和校验提示。三类使用者的动作不同，但都建立在同一套字段定义和判定口径之上。
指标与范围：纳入哪些需求、统计哪些字段
统计范围先于计算确定。纳入统计的是统计期内通过统一入口提交、并已进入受理环节的需求。这个限定意味着：仍在草稿状态、尚未提交的单据不进入统计；测试环境产生的数据、同一诉求的重复提报需要剔除；明确标记为服务请求的单据按服务请求口径管理，不混入需求完整率。分母口径一旦确定，统计期内不再随结果调整。
必填字段集按需求类型区分。业务需求通常需要提出人、所属业务线、诉求描述、期望时间、影响范围等字段；缺陷类需求更关注复现环境、影响版本、严重程度、复现步骤。两类需求的必填项不同，不能共用一张字段清单，否则会把不适用的字段误判为缺失。
字段内部再分两层：核心必填字段在每条需求上都参与判定；条件必填字段只在触发条件成立时参与判定。例如“影响范围”在涉及数据变更时必填，“关联系统”在跨系统需求时必填。触发条件需要在字段定义中写清楚，判定时先判断条件是否成立，再决定该字段是否计入。
| 字段类别 | 示例字段 | 判定方式 |
|---|---|---|
| 核心必填 | 提出人、诉求描述、期望时间、所属业务线 | 每条需求都判定，缺失即不通过 |
| 条件必填 | 影响范围（涉及数据变更时）、关联系统（跨系统需求时）、复现步骤（缺陷类） | 触发条件成立才判定，未触发不计缺失 |
| 选填参考 | 附件、补充说明、参考链接 | 不参与完整性判定 |
数据口径：字段“已填且有效”怎么认定
单字段判定分“已填”和“有效”两层，两层都通过才算该字段通过。已填指字段非空，且内容不是占位性表述，例如只写“无”“待定”“略”“见附件”而附件为空，都应视为未有效填写。有效指格式和取值符合约定：提出人能对应到具体人员而非一个部门名称，期望时间能解析为具体日期而非“尽快”，诉求描述达到约定的最低信息量，例如包含使用场景和期望结果。
条件必填字段的判定顺序是：先看触发条件是否成立，条件不成立时该字段不参与判定，也不计为缺失；条件成立时，按核心必填字段同样的标准判定。这样处理可以避免把“不适用”误算成“不完整”，例如一条不涉及数据变更的需求，不应因为影响范围为空而被判为不完整。
缺失值处理需要统一约定：字段为空记为缺失，填写了但无法解析或明显不符合格式的取值记为无效，缺失和无效都计为该字段不通过。一条需求只要有一个参与判定的字段不通过，该条需求即判为不完整。判定过程中不改写原始数据，判定结果单独记录，便于后续复核和口径追溯。
| 判定情形 | 示例 | 结论 |
|---|---|---|
| 已填且有效 | 提出人为具体人员，期望时间为可解析日期 | 通过 |
| 已填但无效 | 期望时间填“尽快”，提出人填部门名称 | 不通过（无效） |
| 占位内容 | 诉求描述仅写“待定” | 不通过（缺失） |
| 条件未触发 | 不涉及数据变更，影响范围为空 | 不参与判定 |
计算步骤：从单条判定到完整率
计算按固定步骤执行，保证不同人、不同时间复算结果一致。第一步，按需求类型取出对应的必填字段集，核心必填与条件必填分别标注。第二步，逐条需求逐字段判定，记录每个字段的通过情况，全部参与判定的字段通过，该条需求记为完整需求。第三步，汇总统计期内的完整需求数与纳入统计的需求总数，计算完整率。
完整率公式为：完整率 = 完整需求数 ÷ 纳入统计需求总数 × 100%，结果以百分比表示。分子是完整需求条数，分母是剔除草稿、测试数据、重复提报和服务请求后的需求条数，分子分母使用同一统计期和同一范围。第四步，按入口、需求类型、提交人分组呈现，便于定位问题集中在哪个来源或哪类需求。
时间窗按周或按月固定，统计期内提交的需求归入当期，不跨期混算。跨期补全的需求仍按提交时点计入原统计期，补全后的状态可在明细中标注，但不回改已发布的完整率，避免同一期数据反复变动。统计频率与时间窗在开始统计前确定，中途不调整。
例子：一次月度完整率计算
假设某月通过统一入口提交并进入受理环节的需求共120条，按字段规则逐条判定后，完整需求为96条。完整率 = 96 ÷ 120 × 100% = 80%。进一步查看明细，24条不完整需求中，有14条缺失“期望时间”，6条“诉求描述”为占位内容，4条“提出人”无法对应到具体人员。缺失集中在期望时间，说明该字段的填写提示或格式校验需要调整。
条件必填的处理在这个例子里同样体现。当月涉及数据变更的需求有18条，其中“影响范围”字段缺失5条，这5条计入不完整；其余不涉及数据变更的需求，影响范围为空不影响判定。如果不区分触发条件，把这部分一并算作缺失，完整率会被低估，结论也会偏离真实问题。
分组查看时还会遇到分母为零的情形。例如某个新上线入口当月没有提报，该分组的完整率不计算，标注“无数据”，不用0%代替。0%会被误读为该入口提报全部不完整，与“没有提报”是两种完全不同的情况，报表呈现时需要区分。
结果查看与抽样复核
结果查看以两个视图为主：一是按入口、需求类型、时间窗筛选的完整率汇总报表，用于看趋势和分组差异；二是对应的明细清单，列出每条需求的判定结果和不通过字段，用于定位具体问题。汇总报表回答“哪里低”，明细清单回答“低在哪个字段”，两者配合使用，避免只看比率不看原因。
抽样复核用于验证统计可信度。每月抽取一定比例的需求，由受理人或产品负责人人工核对字段判定，与系统或脚本判定结果比对。抽样应覆盖不同入口和需求类型，对完整率异常偏低或偏高的分组适当增加样本。复核发现差异时，先判断是字段定义存在歧义，还是判定执行有误；属于定义问题的，回到字段定义修订并记录变更时点，不用直接修改已发布的数字来消除差异。
复核结论最终反馈到表单改进：高频缺失字段考虑调整为更醒目的必填项，补充填写示例和格式提示；占位填写集中的字段，检查提示文案是否让提报人误以为可以简写。改进后按同一口径继续统计，观察完整率变化，形成“统计—复核—改表单—再统计”的循环。
在工具层面，需求统一入口和字段配置是这套统计落地的前提。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，可使用工单收集和整理来自各方的反馈，处理工单并快速转化为需求，并支持按实际场景自定义工作流。结合模板、权限和流程配置，团队可以把不同需求类型的提报入口和字段要求固化下来；统一的需求池、工单与任务看板实时同步状态与信息，便于追溯需求与问题。统计完整率时，可从这些入口和需求池中按类型、时间窗取数，再按本文口径逐字段判定。具体表单必填配置和报表能力以实际版本与套餐为准，落地前建议在产品内核实。
解读与限制：完整率不能说明什么
完整率高只说明参与判定的字段都填齐了，不说明填写内容准确，也不说明需求本身合理、有价值或优先级高。一条字段齐全但描述含糊的需求，完整率上是满分，受理时仍可能需要补充沟通。把完整率与需求质量混为一谈，容易让团队误以为提升完整率就等于提升了需求管理水平。
不同需求类型、不同入口的完整率不宜直接横向比较。业务需求和缺陷类需求的必填字段集不同，新入口和老入口的提报人群、填写习惯也不同，直接比较数值高低得不出可靠结论。比较应在同一需求类型、同一入口、同一时间窗内进行，跨组比较只作为发现问题的线索，不作为评价依据。
强制必填会带来占位填写。字段设为必填后，部分提报人可能用“无”“待定”快速通过，完整率上升但信息质量没有改善。因此完整率需要与抽样复核配合使用，复核中占位填写比例上升，说明需要调整字段设计或提示方式，而非继续加严必填。
完整率也不宜单独作为提报人的考核依据。以完整率为唯一考核指标，容易诱导为达标而凑字段，反而削弱提报信息的可用性。更合适的做法是把完整率作为入口和表单设计的改进信号，考核评价结合复核结果和受理反馈综合判断。
常见问题
需求提报时字段都填了，为什么仍可能被判为不完整？
判定分“已填”和“有效”两层。字段非空只满足第一层，如果内容属于占位表述，例如只写“无”“待定”“略”，或者期望时间填“尽快”、提出人填部门名称而无法对应到具体人员，都会判为不通过。诉求描述还需要达到约定的最低信息量，例如包含使用场景和期望结果。填写时按字段说明给出可解析、可追溯的内容，比单纯填满更接近完整。
条件必填字段在统计时怎么处理，会不会把不适用的需求算成缺失？
条件必填字段先判断触发条件是否成立，条件不成立时该字段不参与判定，也不计为缺失；条件成立时按核心必填字段同样的标准判定。例如“影响范围”只在涉及数据变更时必填，一条不涉及数据变更的需求不会因为该字段为空而被判为不完整。前提是字段定义中把触发条件写清楚，判定时按同一份定义执行。
某个入口当月没有提报，完整率应该记0%吗？
不应记0%。分母为零时该分组不计算比率，标注“无数据”。0%会被读成该入口提报全部不完整，与“没有提报”是两种不同情况。报表呈现时需要把这两种状态区分开，否则分组对比会得出错误结论。
抽样复核发现系统判定和人工判定不一致，应该改数字还是改规则？
先判断差异来源：是字段定义存在歧义，还是判定执行有误。属于定义问题的，回到字段定义修订并记录变更时点，后续统计按新定义执行；属于执行问题的，修正判定逻辑。已发布的完整率不直接改数来消除差异，否则同一统计期的数据会反复变动，口径也无法追溯。
在ONES里落地这套统计，需要先确认哪些能力？
ONES 可使用工单收集和整理来自各方的反馈，处理工单并快速转化为需求，并支持按实际场景自定义工作流；统一的需求池、工单与任务看板可实时同步状态与信息，便于追溯需求与问题。落地前建议在产品内核实两件事：提报表单的必填字段配置与校验方式，以及是否支持按入口、需求类型统计字段完整率的报表或自定义度量看板。具体能力以实际版本与套餐为准。
