非功能需求往往藏在“要快”“要稳”“要安全”这类日常表达里，直接写进需求文档后难以验收。可执行的做法分两步：先按业务场景和系统边界建立识别清单，把散落的关注点收集成候选；再逐条改写为“对象+指标+目标值+测量条件+验证方式”的可验证要求，并指定负责人、验证时点和证据形式。本文给出识别方法、改写模板、角色分工和评审前检查清单。
要点总览（TL;DR）
- 识别阶段先产出候选清单：按业务场景逐项追问、沿系统边界排查性能/可用性/安全/可维护性等类别，再用干系人访谈和运行事件反推遗漏项。
- 量化阶段用五要素模板改写：对象、指标、目标值、测量条件、验证方式缺一不可；目标值由业务可接受线、现状基线和行业参考交叉确定。
- 每条要求指定负责人和验证责任人，条目按候选→已量化→已评审→验证中→已验证流转，交接时检查五要素与证据归档。
- 评审前用检查清单自查：五要素齐全、目标值有依据、验证方式可执行、证据形式明确、负责人和验证时点落实，未达标条目退回修改。
先建立识别清单：从场景和边界找非功能需求
非功能需求遗漏的常见原因，是团队只围绕功能点讨论，把质量属性留到开发阶段“顺手处理”。识别阶段的目标是产出候选清单，而非定稿指标：先把可能的关注点找全，标注来源，后续再逐条量化。
按业务场景逐项追问
拿每个核心业务场景过一遍三个问题：谁在什么条件下使用；使用过程中最怕出现什么异常；出问题会造成什么后果。例如“财务月末批量对账”场景，追问后会浮现出批量处理时长、月末高峰并发、对账结果不可篡改等关注点。场景越具体，追问出的候选越贴近真实约束。
从系统边界与外部依赖识别类别
沿系统边界走一遍，按类别逐项排查，可以显著降低遗漏率：
- 性能：关键操作的响应时间、批量任务处理时长、峰值并发量。
- 可用性：服务时间窗口、允许的中断时长、故障恢复目标。
- 安全：身份认证与授权、敏感数据保护、操作审计。
- 可维护性：日志与监控覆盖、配置变更方式、版本升级对存量数据的影响。
- 兼容性与可移植性：支持的终端、浏览器、外部系统接口版本。
外部依赖同样是来源：对接的支付、短信、第三方接口，其限流、超时和故障模式会直接转化为本系统的非功能要求。
用干系人访谈和运行事件反推遗漏项
访谈运维和安全人员，问“过去半年出现过哪些影响业务的问题”，把每次故障、告警、投诉反推成一条候选要求。运行事件是已经发生过的事实，比凭空设想更容易暴露被忽略的类别，例如某次数据库连接耗尽暴露出的容量与恢复要求。
输出候选清单
识别阶段的交付物是一张候选清单，每条至少包含来源场景、类别和初步关注点，便于后续分配量化责任：
| 编号 | 来源场景 | 类别 | 初步关注点 |
|---|---|---|---|
| NFR-01 | 财务月末批量对账 | 性能 | 批量任务需在夜间窗口内完成 |
| NFR-02 | 客户自助下单 | 可用性 | 营业时段服务不可中断 |
| NFR-03 | 对接第三方支付 | 安全 | 支付回调需验签并留审计记录 |
| NFR-04 | 历史故障：连接池耗尽 | 可维护性 | 关键资源需有监控与告警 |
把模糊描述改写成可验证要求：五要素模板
候选清单只是起点。一条要求要能被测试或运维判定通过与否，需要同时写清五件事：对象、指标、目标值、测量条件、验证方式。缺任何一项，验收时就容易各说各话。
五要素字段说明
| 要素 | 要回答的问题 | 写法示例 |
|---|---|---|
| 对象 | 对哪个功能、接口或服务提出要求 | 订单提交接口 |
| 指标 | 用哪个可测量的量描述 | 95%请求的响应时间 |
| 目标值 | 达到什么数值算满足 | 不超过800毫秒 |
| 测量条件 | 在什么负载、数据量、环境下测 | 峰值每分钟3000次请求、生产同等配置环境 |
| 验证方式 | 用什么手段、在哪个时点判定 | 上线前压测报告，上线后监控周报 |
各类别的常见指标
- 性能：响应时间分位数（如P95）、吞吐量、批量任务完成时长、资源占用上限。
- 可用性：服务时间窗口、月度允许中断时长、故障恢复时间目标、数据恢复点目标。
- 安全：认证方式与强度、敏感字段加密范围、审计日志保留时长、漏洞修复时限。
- 可维护性：关键指标监控覆盖率、告警响应时限、配置变更是否需要停机、升级回滚时长。
目标值如何取值
目标值不宜拍脑袋。常用三个来源交叉确定：业务可接受线（用户或业务方明确能容忍的上限）、现状基线（当前系统实测水平，作为改进起点）、行业或同类系统参考（作为合理性校验）。三者冲突时，以业务可接受线为约束、基线为现实起点，在需求评审中说明取舍理由。
暂时无法量化时的处理
有些要求短期内拿不到数值，例如新业务尚无用户量参考。此时不要留空，先约定验证方法和判定口径：明确由谁在什么条件下测、以什么结果判定通过，并标注“目标值待基线测量后补充”及补充时点。这样条目仍可进入评审和排期，避免因等待数据而搁置。
角色分工与交付物：谁识别、谁量化、谁验证
非功能要求写完无人认领，是落地失败的主要原因。识别、量化、评审、验证四个环节应各有明确的责任角色和产出。
| 角色 | 主要输入 | 主要输出 |
|---|---|---|
| 业务方 | 业务场景、可接受底线、故障后果 | 场景描述与业务可接受线 |
| 需求分析 | 场景、干系人访谈、运行事件 | 非功能需求候选清单、可验证条目 |
| 架构/开发 | 候选条目、系统现状 | 技术可行性判断、现状基线数据 |
| 测试 | 可验证条目 | 验证方案、测试用例与验证证据 |
| 运维 | 可用性、监控相关条目 | 监控指标配置、运行期证据 |
| 安全 | 安全类条目 | 安全验证结论与整改意见 |
每条要求需指定两类责任人：负责人对条目内容和目标值负责，通常由需求分析或对应领域角色担任；验证责任人对判定结果和证据负责，通常由测试、运维或安全承担。两者可以是同一人，但必须在条目上写明。
条目在需求库中应有清晰的状态流转：候选→已量化→已评审→验证中→已验证。每次状态变更对应一次交接，交接时检查五要素是否齐全、证据是否已归档。评审环节由业务方、需求分析、架构和测试共同参与，重点确认目标值依据和验证方式是否可执行。
当团队使用 ONES 管理需求时，候选清单和可验证条目可以进入统一的需求池，与任务、测试用例和缺陷关联，形成需求—任务—测试—缺陷的闭环；验证阶段的测试计划、用例执行结果和缺陷记录留在同一体系中，便于在条目上追溯证据。ONES Assistant 可在需求澄清阶段提炼待澄清问题与拆解建议，辅助把场景讨论整理成条目初稿，具体能力以实际产品配置为准。
示例：一条可用性要求从描述到可验证
以“客户自助下单”场景中的可用性要求为例，演示完整改写过程。
原始描述与问题点
原始描述：“下单系统要保证高可用，不能老是宕机。”问题在于：没有对象边界（是整个系统还是下单链路）、没有指标（可用率还是中断次数）、没有目标值、没有测量条件、没有验证方式，验收时无法判定是否达标。
改写后的完整条目
| 要素 | 内容 |
|---|---|
| 对象 | 客户自助下单链路（下单页、提交接口、订单查询） |
| 指标 | 月度服务可用率，按每分钟健康检查成功率计算 |
| 目标值 | 不低于99.9%，即月度累计不可用不超过约43分钟 |
| 测量条件 | 营业时段7×24，生产环境，排除计划内维护窗口（需提前公告） |
| 验证方式 | 上线前通过故障演练验证切换与恢复；上线后以监控平台月度可用率报表判定，报表作为证据归档 |
验证时点与证据形式
该条目的验证分两个时点：上线前做故障演练，证据是演练记录与恢复耗时数据；上线后按月出可用率报表，证据是监控平台导出的报表及异常事件说明。证据统一关联到需求条目，评审时可直接调取。
迁移到其他类别的改写规律
同一套方法可平移到其他类别：性能条目把“指标”换成响应时间分位数、“测量条件”写明负载与数据量；安全条目把“指标”换成加密范围或审计保留时长、“验证方式”换成渗透测试或配置核查；可维护性条目把“指标”换成监控覆盖率或回滚时长、“验证方式”换成演练或巡检记录。规律一致：先锁定对象，再选可测指标，最后把测量条件和证据形式写死。
完成检查：判断非功能要求是否可验证
评审前用以下清单逐条自查，任何一项不通过就先退回修改，避免把不可验证的要求带入开发和验收。
- 五要素齐全：对象、指标、目标值、测量条件、验证方式均已在条目中写明。
- 目标值有依据：能说明取值来自业务可接受线、现状基线或行业参考，冲突取舍有记录。
- 验证方式可执行：明确了测试手段或监控来源，验证责任人有能力取得证据。
- 证据形式明确：写清证据是压测报告、监控报表、演练记录还是审计日志，以及归档位置。
- 负责人和验证时点落实：条目上有负责人、验证责任人，并标注验证发生在上线前、上线后或运行期。
- 测量条件无歧义：负载、数据量、环境、是否含维护窗口等口径已约定。
未达标的条目按情况处理：缺目标值的，标注待补时点并指定补数责任人；缺验证方式的，由测试或运维在评审前补充方案；对象边界不清的，退回识别阶段重新拆分。检查通过后，条目方可进入已评审状态并纳入验证计划。
常见问题
业务方给不出具体数值，非功能需求还能进入评审和排期吗？
可以。暂时拿不到数值时，先约定验证方法和判定口径：明确由谁在什么条件下测、以什么结果判定通过，并在条目上标注“目标值待基线测量后补充”及补充时点、补数责任人。这样条目仍可进入评审和排期，避免因等待数据而整体搁置。等基线数据出来后，再回填目标值并更新条目状态。
目标值定得过高或过低，分别会带来什么问题？
目标值过高会推高架构复杂度和成本，甚至让团队在验收时无法达成；过低则无法覆盖业务真实风险。建议用三个来源交叉校验：业务可接受线是硬约束，现状基线是现实起点，行业或同类系统参考用于合理性判断。三者冲突时，在需求评审中记录取舍理由，并说明后续复评的时点，避免目标值一次定死、长期不校准。
非功能要求分散在多个系统或团队时，如何避免边界不清？
关键是先锁定对象边界再谈指标。把要求落到具体链路、接口或服务上，例如“下单页、提交接口、订单查询”作为一条可用性要求的对象，而不是笼统写“整个系统”。跨团队协作时，在条目上写明本团队负责的部分和依赖方提供的保障，接口限流、超时、故障模式等外部约束单独成条。对象边界不清的条目，退回识别阶段重新拆分后再量化。
验证证据应该由谁归档，评审时怎么调取？
验证责任人负责取得并归档证据，通常是测试、运维或安全角色。证据形式在条目中提前写死，例如压测报告、监控月度报表、故障演练记录或审计日志，并注明归档位置。证据统一关联到需求条目，评审和验收时直接调取，避免事后补材料。团队使用 ONES 管理需求时，测试计划、用例执行结果和缺陷记录可与需求条目关联，形成需求—任务—测试—缺陷的闭环，便于追溯验证证据（具体能力以实际产品配置为准）。
已经上线的系统，补做非功能需求识别还有意义吗？
有意义，而且运行期数据正是最好的识别来源。可以从过去半年的故障、告警和投诉反推候选要求，把已经发生的事件转成条目，再按五要素补齐目标值和验证方式。补做时优先处理影响业务连续性、数据安全和合规的类别，其余条目按风险排序分批量化。这样既能为后续迭代建立基线，也能让运维和安全的日常监控指标与需求条目对应起来。
