非功能需求出问题，往往同时存在两种症状：该写的性能、安全、可用性等约束没有进入需求清单；写了的又停留在“快速”“稳定”“友好”这类口号上，无法测量也无法验收。排查时先把两类问题分开，用维度清单扫描遗漏，用“指标+阈值+测量条件+验证方式”四要素检验已有表述，再逐条改写补全，最后通过评审和测试用例反向确认缺口闭合。
要点总览（TL;DR）
- 先分类再排查：遗漏是覆盖面问题，不可验证是表达质量问题，两类症状要分开处置，避免补了口号仍漏维度。
- 用非功能维度清单逐场景扫描，留空记为待确认缺口，不适用必须写明理由；再对已有表述做指标、阈值、测量条件、验证方式四要素检验。
- 补全按先覆盖后质量的顺序：先补整体缺位维度，再用“在什么条件下、达到什么指标阈值、通过什么方式验证”的句式改写口号，阈值来源与业务方确认。
- 验证以测试用例能否独立设计为准，无法设计用例的条目退回改写；把维度清单和四要素检查项固化进需求模板与评审清单，防止下个版本重演。
- 遗留缺口要明确责任人和闭合时间并纳入版本风险跟踪，发布前未闭合的需在发布评审中说明影响和应对措施。
遗漏与不可验证口号分别有哪些表现
两类症状的成因不同，处置动作也不同。遗漏是覆盖面的问题，不可验证是表达质量的问题。混在一起排查，容易出现“补了几条口号、漏掉的维度仍然没人提”的情况。先建立识别基线，再确定本次排查涉及哪些文档、版本和业务场景。
遗漏型症状的识别特征
最典型的信号是需求清单几乎只有功能描述：用户能做什么、系统返回什么、流程怎么走，而性能、安全、可靠性、可用性、兼容性、可维护性、合规等维度整体缺位。具体表现包括：
- 整份需求文档检索不到响应时间、并发量、可用性比例、数据保留期限等量化表述。
- 涉及登录、支付、个人信息的功能，没有配套的权限、加密、审计要求。
- 需求只描述正常流程，异常恢复、降级、数据一致性没有对应条目。
- 对接外部系统时，只写“完成对接”，没有接口超时、重试、兼容版本的要求。
- 非功能要求散落在会议纪要、聊天记录或口头约定中，没有进入受控的需求条目。
不可验证型症状的识别特征
这类需求“看起来写了”，但无法判断是否达成。“系统响应要快速”“界面要友好”“保证高可用”“运行要稳定”“支持大数据量”都是典型口号。它们的共同点是：没有指标、没有阈值、没有测量条件、没有验证方式，测试人员无法设计用例，验收时只能靠主观感受争论。
两类问题造成的后果不同但都落在下游：遗漏会让开发和测试在缺少约束的情况下自行假设，上线后由运维和用户承担风险；不可验证口号则在评审时看似通过，到测试和验收阶段才暴露分歧，返工成本更高。排查范围建议按“文档+版本+业务场景”三要素界定，例如本次覆盖某版本需求规格说明书及其中涉及交易、登录、报表三类场景的条目，范围外的历史需求另行登记。
按维度扫描与四要素检验定位缺口
排查分两步走：先用维度清单做覆盖面扫描，找出整体缺位的方向；再对已有表述逐条做四要素检验，判断写了的条目是否可验证。两步的产出合并进同一张缺口登记表，每条缺口都附判定依据，避免把猜测当成结论。
维度扫描的操作方式
准备一份非功能维度清单，至少覆盖性能、安全、可靠性、可用性、兼容性、可维护性、合规与数据。对每个业务场景逐项提问：这个场景有没有对应的非功能约束？约束写在哪条需求里？如果某维度判定不适用，要写明理由，例如“内部离线工具，无对外服务，可用性指标不适用”，而不是留空。留空和“不适用”是两种状态，前者是待确认的缺口，后者是有依据的排除。
四要素检验
对每条已写出的非功能表述，检查四个要素是否齐全：
| 要素 | 检验问题 | 不合格示例 | 合格示例 |
|---|---|---|---|
| 指标 | 衡量的是什么量？ | 系统要快 | 订单查询接口响应时间 |
| 阈值 | 达到多少算达标？ | 响应要快 | 95%请求在500毫秒内 |
| 测量条件 | 在什么负载、数据量、环境下测？ | 未说明 | 在100并发、订单表1000万行条件下 |
| 验证方式 | 用什么手段证明？ | 未说明 | 性能测试报告，压测脚本随版本归档 |
四要素缺任何一项，该条目就归入“不可验证”类缺口。缺指标和阈值属于严重缺口，缺测量条件和验证方式属于可补全缺口，但同样要登记。
常见误判
排查中容易把三类内容误当成非功能需求。一是技术方案描述，例如“采用Redis缓存提升性能”，这是实现手段，不是约束，约束应写成可观测的结果指标。二是测试关注点，例如测试计划里的“验证登录安全性”，它说明要测什么，没有给出需求侧的阈值。三是运维规范，例如“每日备份”，属于运维制度，只有当业务方对数据恢复提出可验证要求（如恢复时间目标）时才转化为需求条目。遇到这三类内容，登记为“表述错位”，改写而非直接采纳。
缺口登记表
建议每条缺口记录以下字段：编号、所属文档与版本、业务场景、维度、现状表述（原文摘录）、缺失要素、判定依据（为什么不适用或为什么不合格）、影响范围（涉及哪些功能、测试或验收环节）、初步定级。判定依据一栏是区分“已确认缺口”和“待确认假设”的关键，评审时优先核对这一栏。
把口号改写成可验证约束的补全步骤
补全按先覆盖、后质量的顺序推进：先处理整体缺位的维度，把该有的约束补进清单；再逐条改写不可验证表述。顺序反过来做，容易在少数口号上反复打磨，而遗漏的维度始终没人负责。
改写模板
统一采用一个句式：在【测量条件】下，【指标】达到【阈值】，通过【验证方式】确认。以“系统要快速”为例，改写为“在100并发用户、订单表1000万行的条件下，订单查询接口95%请求响应时间不超过500毫秒，通过性能测试报告验证”。以“保证高可用”为例，改写为“核心交易服务月度可用性不低于99.9%，统计口径为排除计划内维护窗口，通过监控平台月度报表验证”。每个条目同时标注验证阶段（如集成测试、验收测试、上线后观察期）和责任人。
阈值来源与风险边界
阈值不能由需求分析人员单方面拍定。与业务方确认时要问清依据：来自合同或服务水平协议、来自历史运行数据、来自同类系统基准，还是来自成本可接受范围内的估算。来源不同，阈值的刚性也不同，合同类必须满足，估算类可在评审中调整。涉及架构选型或明显成本增加的约束，例如要求跨地域容灾、要求全链路加密，先做影响评估再写入正式条目，评估结论作为条目附件，避免需求写入后无法落地。
分工与确认
需求提出方负责确认业务阈值和优先级；需求分析人员负责按模板改写、补齐四要素并登记缺口状态；测试人员负责判断每条约束能否设计出对应用例，不能设计的退回改写。三方确认记录随需求条目保存，作为后续变更的基线。在需求条目数量多、跨版本迭代的场景下，可以把缺口登记表转为受控的需求条目，用状态字段区分“待补全、已改写、已验证”，并在评审时按状态筛选。ONES 的需求管理支持工作项自定义字段与状态流转，可以把维度、缺失要素、验证阶段作为字段挂在条目上，让补全进度和责任人可见，减少靠表格线下传递造成的遗漏。
验证补全结果并防止再次遗漏
改写完成不等于缺口闭合。验证要做两件事：确认每条非功能需求都能被测试或验收动作覆盖；确认同类遗漏不会在下一个版本重演。
用测试用例反向验证
逐条检查改写后的需求是否都有对应的测试用例或验收标准。判定标准可以归纳为三条：测试人员能根据条目独立设计用例，不需要再向需求方追问指标；用例的执行结果能给出明确的通过或不通过结论；不通过时能定位到具体阈值和测量条件。三条同时满足，该条目才算验证通过。无法设计用例的条目退回补全环节，不允许以“测试时再看”的方式放行。
评审检查点与复发预防
把非功能维度清单和四要素检查项固化进需求模板与评审清单：模板中为每个维度预留填写位置，不适用的必须填写理由；评审清单增加“四要素是否齐全”“验证方式是否明确”两项必检项。评审记录中保留检查结果，作为需求基线的一部分。这样下一次需求编写时，遗漏和口号会在模板层面被拦截，而不是等到测试阶段才发现。
遗留缺口的上报与跟踪
本次排查无法闭合的条目，例如阈值依赖外部系统确认、架构评估尚未完成，要单独列出并上报给需求负责人和项目负责人，明确责任人和计划闭合时间，纳入版本风险清单跟踪。遗留缺口在版本发布前仍未闭合的，需要在发布评审中说明影响和应对措施，不能默认降级处理。
验证通过的判定标准建议统一为：本次排查范围内所有维度均有明确结论（已补全或已说明不适用），所有非功能条目通过四要素检验，每条条目均有对应验证方式，遗留缺口均有责任人和闭合计划。四项同时满足，方可认为本轮排查补全工作完成。
常见问题
某个非功能维度判定为“不适用”，需要留下什么记录才算数？
不适用要有可核查的理由，不能靠留空默认排除。记录至少写清三件事：该维度对应的业务场景是什么、为什么不构成约束、由谁确认。例如内部离线工具没有对外服务，可用性指标不适用，理由要落到“无对外服务、使用方为内部固定人员”这类具体事实，而不是“暂时用不上”。判定依据写入缺口登记表后，在评审时作为结论核对；后续业务场景变化（如工具对外开放）时，这条记录要重新审视。
阈值一时确认不下来，补全工作要不要停下来等？
不必整体停摆。可以把该条目登记为“待确认缺口”，先完成其余维度的扫描和改写，同时明确阈值确认的责任人和计划闭合时间，纳入版本风险清单跟踪。需要区分的是：阈值来源属于合同或服务水平协议的，刚性高，必须确认后才能定稿；属于历史数据或估算的，可以先给出暂定值并标注来源，在评审中调整。发布前仍未闭合的条目，要在发布评审中说明影响和应对措施。
技术方案里已经写了“采用缓存提升性能”，还需要单独写非功能需求吗？
需要。技术方案描述的是实现手段，非功能需求要写的是可观测的结果约束。两者可以并存，但不能互相替代：方案说明怎么做，需求条目说明做到什么程度算达标。排查时把这类内容登记为“表述错位”，从方案描述中提炼出指标、阈值、测量条件和验证方式，形成独立的需求条目，再与方案建立关联。这样测试和验收才有依据，方案调整时也能判断约束是否仍然满足。
补全后的非功能需求，怎么判断已经可以结束排查？
建议用四条标准同时判断：排查范围内每个维度都有明确结论，要么已补全，要么有依据地说明不适用；所有非功能条目通过四要素检验；每条条目都有对应的验证方式，测试人员能据此独立设计用例；遗留缺口都有责任人和闭合计划。四条同时满足，本轮排查补全才算完成。只满足前两条说明写得清楚但未必可测，需要回到验证环节补用例或退回改写。
需求条目多、跨版本迭代时，缺口登记表怎么管理才不容易丢？
线下表格在条目多、迭代快时容易失联。可以把缺口登记表转为受控的需求条目，用状态字段区分“待补全、已改写、已验证”，把维度、缺失要素、验证阶段作为字段挂在条目上，评审时按状态筛选核对。ONES 的需求管理支持工作项自定义字段与状态流转，可用于承载这类字段和状态，让补全进度和责任人保持可见。工具只是承载方式，判定依据和确认记录仍要随条目保存，作为后续变更的基线。
