非功能需求出问题，常见两种表现：整类维度在文档里找不到，或者写了“响应要快”“系统要稳定”这类无法判定通过与否的口号。排查时不必全量重写，可以先圈定范围，把现有需求逐条对照非功能维度清单，找出缺失类别和口号条目；再判断每条口号缺的是度量对象、判定阈值还是测量条件；补全后回到评审场景验证能否直接执行判定，并把检查口径固化到模板和评审检查项中。
要点总览（TL;DR）
- 先圈定排查范围：优先检查本次交付、核心链路和历史上出过问题的需求，按非功能维度清单标记整类缺失和口号条目。
- 把口号拆成三类缺陷再补：缺度量对象、缺阈值、缺测量条件，三类可以同时存在，逐项判定后再改写。
- 补全阈值要写明来源和统计口径，来源不明时标注待确认及责任人，不把假设写成结论。
- 补全完成的标志是测试或验收人员只看条目就能写出判定步骤，做不到就回到判定环节继续拆解。
- 把维度清单、可验证性检查和责任时点固化到需求模板与评审检查项，用历史需求抽样回看确认缺口已覆盖。
遗漏和口号化通常出现在哪些需求里
先界定症状范围，目的是把待排查的需求集缩小到可操作的数量，避免一发现问题就推翻整份需求文档。判断标准可以落在两个可观察的现象上：文档中某类非功能维度完全没有对应条目；或者有条目，但读完无法回答“怎么算通过”。
两类异常表现
遗漏的典型表现是整类维度缺席。例如一份订单履约系统的需求文档，功能条目写了几十条，却找不到任何关于并发处理能力、故障恢复时间、数据保留期限的描述。这类缺口往往在评审时也不容易被发现，因为没有人会为不存在的内容提问。
口号化的典型表现是有描述但无法判定。常见句式包括“响应要快”“系统要稳定”“界面要友好”“要保证数据安全”。这些描述指向了正确的关注方向，但缺少度量对象、阈值和测量条件，测试人员无法据此设计用例，验收人员也无法给出通过或驳回的结论。
圈定排查范围
建议按需求类型和业务场景圈定范围，优先排查三类需求：本次迭代或本季度要交付的需求；涉及外部用户、资金、敏感数据的核心链路需求；历史上线后出现过性能、稳定性或安全问题的模块。范围之外的存量需求可以抽样，不必一次性全量处理。
同时要明确本文的处理边界。本文聚焦非功能需求的缺口识别与条目改写，需求的结构化表示与建模方法、正式评审的组织流程与确认规则属于其他主题，不在本文展开。排查阶段只需要产出待排查清单和异常标记，不需要同步启动评审流程改造。
症状自查范围说明
排查开始前，可以先填写一份简单的范围说明，作为后续判定和补全的工作底稿：
| 项目 | 填写内容 |
|---|---|
| 待排查需求清单 | 需求编号、名称、所属模块、计划交付时间 |
| 排查优先级 | 核心链路 / 一般功能 / 存量抽样 |
| 整类缺失标记 | 按维度列出文档中找不到条目的类别 |
| 口号条目标记 | 列出有描述但无法判定通过与否的条目及原文 |
| 排查人与时点 | 谁在什么时间完成初筛 |
逐条判定：是遗漏、缺指标还是缺验证条件
判定阶段要回答的问题是：这条需求的缺陷到底属于哪一类。把“口号化”当成一个笼统结论，后续改写就会无从下手；拆成具体缺陷类型，每条需求都能对应到一个明确的补全动作。
按维度清单逐项比对
准备一份非功能维度清单作为比对基准，常用维度包括性能、可靠性、安全、易用性、可维护性、兼容性、可移植性和合规性。对每条需求，逐项检查文档中是否存在对应描述，并记录三种状态：有明确条目、有条目但不可判定、整类缺失。比对结果直接形成缺失类别清单，这是后续补全遗漏维度的输入。
比对时要注意一种容易误判的情况：需求可能写在别处但没有关联。例如安全要求写在架构设计文档或运维规范里，需求条目本身没有引用。这类情况应先确认是否存在，存在则补上关联关系，按“未关联”处理，不计入“确实遗漏”。区分两者的证据是能否在项目资料中找到对应描述及其适用范围。
三类缺陷的判定与排除证据
对已有描述做可验证性判定，可以拆成三个问题，每个问题对应一类缺陷假设：
| 缺陷类型 | 判定问题 | 成立证据 | 排除证据 |
|---|---|---|---|
| 缺度量对象 | 描述指向的是什么被测量？ | 只能读出方向，读不出测量对象，如“要快” | 文中明确了对象，如“订单查询接口” |
| 缺阈值 | 达到什么数值算通过？ | 没有数值或判定标准，如“尽量缩短” | 给出了可比较的数值或等级，如“P95 小于 2 秒” |
| 缺测量条件 | 在什么环境、负载、时点下测量？ | 未说明测量前提，不同条件下结果差异大 | 写明了环境、数据量、并发或统计窗口 |
三类缺陷可以同时存在。一条“系统要稳定”的描述，既缺度量对象（稳定指可用率、故障恢复时间还是错误率），也缺阈值，还缺测量条件。判定时逐项打勾，不要因为找到一个缺陷就停止。
逐条判定表
把判定结论落到表格里，每条需求一行，作为补全阶段的输入：
| 需求编号 | 原文描述 | 缺陷类型 | 判定依据 | 处理建议 |
|---|---|---|---|---|
| REQ-012 | 订单查询要快 | 缺度量对象、缺阈值、缺测量条件 | 未说明测量哪个接口、目标数值和测试负载 | 补全为可测条目 |
| REQ-035 | 系统要稳定 | 缺度量对象、缺阈值 | 未定义稳定性的计量口径 | 补全为可用率或恢复时间指标 |
| REQ-041 | （无相关条目） | 整类缺失：安全 | 全文未出现认证、授权、数据保护相关描述 | 结合业务场景补充 |
| REQ-058 | 接口响应时间不超过 2 秒 | 缺测量条件 | 未说明并发量、数据规模和统计分位 | 补充测量前提 |
按缺陷类型补全非功能需求
补全动作与判定结果一一对应：整类缺失的补维度，缺度量对象的补指标，缺阈值的补通过标准，缺测量条件的补验证前提。改写后的每条需求应当让测试或验收人员读完就能设计判定方法。
补全遗漏维度
遗漏维度的补全要结合业务场景选择，不追求清单全覆盖。判断某个维度是否相关，可以问三个问题：该维度失效会造成什么业务后果；这个后果是否在本次交付范围内需要防范；团队是否有手段验证。三个问题都有明确答案的维度优先补，其余维度可以记录为“本次不适用”并说明理由，留待后续版本评估。
例如面向内部员工的报表工具，性能维度可以聚焦在月末集中查询的响应时间；面向外部用户的支付链路，安全与可靠性维度的优先级更高。维度选择本身也是需求决策，应当留下选择依据。
补指标、补阈值、补验证条件
补指标是明确度量对象和计量单位。把“要快”落到具体对象上，例如“订单列表查询接口的响应时间”，单位明确为毫秒或秒。度量对象要具体到接口、页面、任务或数据对象，避免停留在系统整体层面。
补阈值是给出可判定的通过标准，并说明依据来源。阈值来源通常有三类：业务目标（如用户可接受的最长等待时间）、历史数据（如过去三个月的实际水平加合理余量）、行业基准或合同约定。来源不明的阈值应标注“待确认”，并写明需要谁在什么时间确认，不编造数值。阈值还要说明统计口径，例如取平均值、P95 还是最大值，不同口径对应的通过标准差异很大。
补验证条件是说明在什么环境、什么负载、什么时点测量。同一接口在测试环境和生产环境、在空载和高峰负载下结果不同，验证条件决定了结论是否可复现。需要写清的内容包括：测试环境与生产环境的一致性程度、并发用户数或请求量、测试数据规模、统计时间窗口，以及由谁在哪个阶段执行测量。
改写前后对照
| 改写前 | 改写后 | 补全内容 |
|---|---|---|
| 订单查询要快 | 订单列表查询接口在 200 并发用户、单用户订单量 500 条以内的条件下，P95 响应时间不超过 2 秒；在生产同等配置环境、业务高峰时段测量 | 度量对象、阈值、统计口径、测量条件 |
| 系统要稳定 | 核心交易链路月度可用率不低于 99.9%，单次故障恢复时间不超过 30 分钟；按生产环境监控数据统计，故障定义与计时起点见运维规范 | 度量对象、阈值、统计窗口、判定依据 |
| 要保证数据安全 | 用户手机号在列表页与导出文件中脱敏展示；接口访问需通过身份认证与角色授权；验收时由安全测试人员按检查项逐条验证 | 具体控制措施、验证方式 |
改写时保留风险边界：阈值来源不明、业务方尚未确认的条目，在需求中明确标注“待确认”及确认责任人，不把假设写成结论。补全后的条目如果仍然无法让测试人员写出判定步骤，说明还缺信息，应回到判定环节继续拆解。
当需求条目数量较多、分散在文档和讨论记录中时，可以把补全后的条目统一沉淀到需求管理工具里，让度量对象、阈值和验证条件作为条目属性随需求流转。ONES 支持围绕 PRD 做质量检查并提炼待澄清问题，ONES Assistant 可以基于项目、工作项和 Wiki 页面等上下文回答问题，并把结果保存为工作项或 Wiki 页面，便于把补全结论直接落到可追踪的条目上；具体字段与模板约束需结合团队实际配置确认。
补全后如何验证并防止再次遗漏
补全完成的标志是条目可执行，而非文档看起来更完整。验证阶段要确认测试或验收人员能直接依据条目做出通过与否的判定，然后再把这次排查中形成的口径固化为常规动作。
验证补全条目是否可执行
可以组织一次小范围的可执行性验证：请测试或验收人员只看需求条目，写出对应的验证步骤和判定结论，不额外询问需求作者。如果对方能写出明确的测量方法、预期结果和通过标准，条目视为可执行；如果仍需口头补充信息，说明条目还缺内容，记录缺口并回到补全环节。
验证时重点检查三类问题：阈值是否有明确来源和统计口径；测量条件是否足以复现；判定结论是否只有“通过/不通过”两种，避免出现“基本满足”这类模糊结论。对核心链路需求建议全部验证，一般需求可以抽样。
抽样回看历史需求
用同一份维度清单和判定表，抽取一批已上线或已验收的历史需求做回看，确认同类缺口是否已经覆盖。回看的目的有两个：检验清单本身是否够用，发现清单未覆盖的维度或场景；确认本次补全的口径能否套用到存量需求上。回看结果中反复出现的缺口类型，应优先加入预防机制。
固化到模板与评审检查项
复发预防的关键是把这次排查用的工具变成日常流程的一部分：
- 在需求模板中加入非功能维度提示项，每个维度留出度量对象、阈值、测量条件三个填写位，不适用时要求写明理由。
- 在评审检查项中加入可验证性检查：每条非功能描述能否被测试人员直接判定，阈值来源是否标注。
- 明确责任角色与检查时点：需求作者负责填写完整，评审主持人在评审前按检查项核对，测试负责人在用例设计阶段反馈不可判定条目。
- 把判定表和改写示例作为团队参考材料，新成员入职或新项目启动时复用。
这些检查项可以承载在需求管理工具的模板和评审流程中，让缺口在需求录入和评审环节就被拦截，而不是等到测试阶段才暴露。ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合把检查记录与需求条目关联留存；具体模板字段和检查项配置需按团队流程设定。
完成一轮排查补全后，建议记录本次发现的缺口类型分布和补全条目数量，作为下一轮抽样的对照基线。当连续几个迭代中新增需求不再出现整类缺失、口号条目比例明显下降时，可以判断预防机制开始生效，后续转为定期抽样检查即可。
常见问题
非功能需求写在架构文档或运维规范里，需求条目没有引用，算遗漏吗？
先按“未关联”处理，不计入“确实遗漏”。判定依据是能否在项目资料中找到对应描述及其适用范围：找得到，就在需求条目上补关联关系并注明出处；找不到，才按整类缺失补全。这样区分可以避免重复补写，也能让需求条目成为可追溯的入口。
阈值一时定不下来，需求还能先进入开发吗？
可以先把条目写成“待确认”状态，但要把三件事写清楚：需要确认的度量对象、拟采用的统计口径、由谁在什么时间点给出数值。开发可以按功能逻辑推进，验收前必须补齐阈值，否则测试无法判定通过与否。把待确认项列入评审检查项，可以防止它在流转中被遗忘。
非功能维度清单要不要每个维度都填？
不需要追求全覆盖。判断某个维度是否相关，可以看三点：该维度失效会造成什么业务后果、这个后果是否在本次交付范围内需要防范、团队是否有手段验证。三点都有明确答案的优先补；其余维度记录为“本次不适用”并写明理由，留待后续版本评估。维度选择本身也是需求决策，应保留依据。
补全后的条目怎么确认真的可验证？
做一次小范围可执行性验证：请测试或验收人员只看需求条目，写出验证步骤、预期结果和通过标准，不额外询问需求作者。能独立写出，条目视为可执行；仍需口头补充信息，说明还缺内容，记录缺口后回到补全环节。核心链路需求建议全部验证，一般需求可以抽样。
补全后的非功能条目分散在文档和讨论记录里，怎么统一管理？
可以把度量对象、阈值和验证条件作为需求条目的属性统一沉淀，让它们随需求流转到评审和测试环节。ONES 支持围绕 PRD 做质量检查并提炼待澄清问题，ONES Assistant 可以基于项目、工作项和 Wiki 页面等上下文回答问题，并把结果保存为工作项或 Wiki 页面，便于把补全结论落到可追踪的条目上；具体字段与模板约束需结合团队实际配置确认。
