非功能需求常以“要快、要稳、要安全”这类描述出现，直接进入开发会让验收缺少依据。可执行的做法是：先从业务场景、用户角色、运行环境和合规约束中排查候选，再为每条候选补齐度量对象、指标、目标值、测量条件与验证方式，最后逐条检查能否被测试或观测。本文按识别、量化、验证三个动作展开，并给出角色分工、完整示例和完成检查清单。
要点总览（TL;DR）
- 识别非功能需求时，从业务场景、用户角色、运行环境、合规约束四类来源逐项排查，再按性能、可用性、安全、可维护性等类别归并，形成带来源和待澄清点的候选清单。
- 量化的关键是让每条要求包含度量对象、指标、目标值及单位、测量条件和验证方式；缺少任一要素，条目就仍停留在描述层面。
- 可验证性检查围绕三点：能否设计测试或演练触发场景、能否通过监控或日志持续观测、判定标准能否让不同人员得出一致结论。
- 需求提出方、分析人员、架构或技术负责人、测试人员分别对场景说明、条目整理、指标可行性和验证执行负责，交接以交付物为准。
- 整批转化完成后，用类别覆盖、量化要素完整性、验证方式可执行性和遗留待澄清项四项检查逐条核对，未通过项回到对应环节处理。
先按场景和约束识别非功能需求
非功能需求的识别入口来自功能之外的约束条件。功能需求描述系统“做什么”，非功能需求描述系统在什么条件下、以什么质量水平完成。只读功能列表容易遗漏，建议从四类来源逐项排查，把每条来源可能带来的质量要求记录下来，形成候选清单。
四类来源的排查重点如下：
- 业务场景：高峰时段集中下单、月末批量对账、跨区域访问、离线补录等场景，会带出吞吐量、响应时间、数据一致性方面的要求。
- 用户角色：一线操作人员关注操作响应，管理人员关注报表生成时长，外部合作方关注接口可用性与权限隔离。不同角色的使用频率和操作量不同，对应的指标目标值也不同。
- 运行环境：部署方式、网络条件、终端类型、数据规模增长预期，会带出兼容性、容量、可扩展性方面的要求。
- 合规约束：行业监管、数据分级分类、审计留痕、个人信息保护等外部要求，会带出安全、隐私、日志留存方面的要求。
按来源排查后，再按类别归并，形成候选清单。常用类别包括性能、可用性、安全、可维护性，也可根据系统特点补充兼容性、可移植性、易用性等类别。类别的作用是检查覆盖面，避免只关注性能而忽略安全或可维护性。
候选清单建议包含五个字段：来源、类别、初步描述、提出人、待澄清点。初步描述允许保留模糊表述，例如“报表导出不能太慢”，但要在待澄清点中写明需要确认的内容，例如“导出数据量上限是多少、可接受时长是多少、在什么环境下测量”。同时标注该条属于已明确要求还是待澄清假设：已明确要求指有制度文件、合同条款或业务方明确口径支撑；待澄清假设指目前只有倾向性描述，需要进一步确认。两类条目在后续量化阶段的处理优先级不同，假设类条目应先澄清再量化。
把模糊描述改写成可量化指标
量化的核心是让每条要求具备可测量的结构。一条可量化的非功能需求至少包含五个要素：度量对象、指标、目标值及单位、测量条件、验证方式。缺少任一要素，条目就还停留在描述层面。
度量对象指被测量的具体事物，例如“订单查询接口”“报表导出任务”“登录认证服务”。指标指测量维度，例如响应时间、成功率、恢复时间、缺陷修复时长。目标值要带单位和比较方向，例如“95%的请求在2秒内返回”。测量条件说明在什么负载、数据量、时段和环境下测量，同一指标在不同条件下结果差异很大，条件缺失会让目标值失去意义。验证方式在下一节展开，量化阶段先预留字段。
四类常见非功能需求的量化示例如下：
| 类别 | 模糊描述 | 量化后的条目 |
|---|---|---|
| 性能 | 订单查询要快 | 在日均10万订单、峰值每秒50次查询的负载下，订单列表查询接口95%的响应时间不超过2秒，测量环境为生产同配置环境 |
| 可用性 | 系统要稳定 | 核心交易服务在计划维护窗口之外，月度可用性不低于99.9%，按每分钟探测一次、连续三次失败计为不可用的口径统计 |
| 安全 | 要保证数据安全 | 所有涉及客户手机号的接口须经身份认证与权限校验，越权访问尝试须被拒绝并记录审计日志，日志保留不少于180天 |
| 可维护性 | 系统要便于维护 | 线上缺陷从确认到修复上线的中位时长不超过3个工作日，紧急缺陷不超过8小时，按工单系统记录时间统计 |
改写时有两个常见问题需要处理。一是目标值缺少依据，例如直接写“99.99%可用性”却未考虑成本与业务影响，这类目标值应与业务方确认可接受水平，并说明该水平对应的业务损失容忍度。二是指标选错对象，例如用平均值描述响应时间，平均值会掩盖长尾请求，面向用户体验的场景更适合用分位数。测量条件要写清负载水平、数据规模、时段和环境，条件变化时目标值应重新确认。
量化完成后，每条条目应能回答：测什么、在什么条件下测、达到什么数值算通过。回答不了其中任何一项，说明该条还需要继续澄清或拆分。
用可验证性检查确认每条要求
可量化不等于可验证。可验证性检查判断的是：团队能否设计出执行手段，并给出明确的通过或不通过判定。检查围绕三个问题展开：能否设计测试或演练来触发该场景；能否通过监控或日志持续观测；判定标准是否明确到不同人员执行能得出一致结论。
常用验证方式及适用场景：
- 测试：适用于性能、兼容性、安全校验等可在受控环境复现的条目，需明确测试数据规模、并发水平和环境配置。
- 监控：适用于可用性、响应时间分布等需要长期观测的条目，需明确采集口径、统计周期和告警阈值。
- 审查：适用于权限设计、日志留存策略等难以动态触发的条目，需明确审查依据和检查项。
- 演练：适用于故障恢复、容灾切换等条目，需明确演练场景、参与角色和成功判定。
可测性检查清单可按以下条目逐项核对：
- 度量对象是否指向具体的服务、接口、任务或流程。
- 指标是否有公认的统计口径，例如响应时间按服务端处理时间还是端到端时间计算。
- 目标值是否带单位和比较方向，是否存在歧义。
- 测量条件是否写明负载、数据量、时段和环境。
- 验证方式是否已指定，执行所需的环境、数据和工具是否可获得。
- 判定标准是否明确，通过与否能否由他人复核。
检查不通过的条目按原因处理。指标口径不清的，回到业务方确认统计方式；测量条件缺失的，补充场景参数；目标值无法判定的，拆分为多个可分别测量的子条目，例如把“系统要稳定”拆成核心服务可用性、故障恢复时间、数据不丢失三条；当前技术手段无法观测的，先确认是否存在替代观测方式，仍无法观测的标记为待澄清，不直接视为已完成。
在需求条目管理和验证跟踪环节，团队可以把量化条目、测量条件和验证状态记录在需求工作项中，并与测试用例建立关联。ONES 的需求管理与测试管理能力可承载这类条目化记录和状态跟踪，ONES Assistant 可围绕 PRD 质量检查提炼待澄清问题与拆解建议，帮助团队在澄清阶段发现缺失的量化要素；具体功能范围以实际部署和套餐为准。
角色分工与交付物
识别、量化、验证三个环节涉及不同角色，职责不清会导致条目停留在模糊状态。下表给出常见分工，团队可根据规模调整兼任方式，但每项交付物应有明确责任人。
| 环节 | 主要负责角色 | 配合角色 | 交付物 | 交接点 |
|---|---|---|---|---|
| 识别 | 需求提出方（业务方） | 需求分析人员 | 非功能需求候选清单，含来源、类别、初步描述、待澄清点 | 候选清单经分析人员整理后提交量化 |
| 量化 | 需求分析人员 | 架构或技术负责人、业务方 | 可量化非功能需求条目表，含度量对象、指标、目标值、测量条件 | 技术负责人确认指标可行性后进入验证设计 |
| 验证设计 | 测试人员 | 需求分析人员、架构或技术负责人 | 可验证要求清单及验证方式说明 | 验证方式确认后纳入测试计划或监控方案 |
| 跟踪与关闭 | 需求分析人员 | 测试人员、业务方 | 验证结果记录与遗留待澄清项清单 | 验证通过后关闭条目，未通过项回到量化或澄清 |
需求提出方负责说明业务场景和约束背景，对目标值的业务合理性负责。分析人员负责把分散描述整理成结构化条目，推动待澄清点闭环。架构或技术负责人确认指标在当前架构和成本条件下可实现，并对测量条件的设定给出技术判断。测试人员确认验证方式可执行，包括测试环境、数据准备和判定口径。交接时以交付物为准，口头确认的结论应回写到条目中。
示例：一条可用性要求的完整转化
以下示例演示一条可用性要求从模糊描述到可验证要求的完整过程。
原始描述：业务方提出“结算系统在月底不能出问题，出问题要能马上恢复”。
识别来源与类别：该描述来自业务场景中的月末结算高峰，同时涉及运行环境中的故障恢复能力。归入可用性类别，附带一条可维护性关联项（故障定位效率）。待澄清点包括：月底高峰的具体时段和交易量、可接受的停机时长、恢复的责任边界。
量化后的条目：
- 结算核心服务在每月最后两个工作日8:00至22:00期间，月度可用性不低于99.95%，按每分钟探测一次、连续两次失败计为不可用的口径统计。
- 发生服务中断时，从告警触发到服务恢复的中位时长不超过15分钟，单次最长不超过30分钟，按监控系统告警与恢复时间戳统计。
- 结算数据在故障恢复后须与故障前账务记录一致，差异笔数为零，按恢复后对账结果判定。
验证方式与判定标准：可用性指标通过监控系统持续采集，按月生成报表，低于目标值即判定不通过；恢复时长通过故障演练验证，演练场景设定为主节点宕机，记录告警到恢复的时间，超过30分钟判定不通过；数据一致性在演练后执行对账脚本，存在差异即判定不通过。三项全部通过，该条要求才算验证完成。
这个示例体现了转化的完整链条：模糊描述先落到来源和类别，再补齐度量对象、指标、目标值和测量条件，最后为每条指定验证方式和判定标准。实际工作中，一条原始描述往往拆成多条可分别验证的条目，拆分依据是测量对象和验证手段是否不同。
完成检查
整批非功能需求转化完成后，用以下清单逐项核对，确认没有遗漏和悬空条目。
类别覆盖检查
- 性能、可用性、安全、可维护性四类是否均已排查，未涉及的类别是否有明确理由。
- 四类识别来源（业务场景、用户角色、运行环境、合规约束）是否都经过排查并留有记录。
- 是否存在只有功能描述、没有任何质量约束的模块。
量化要素完整性检查
- 每条条目是否包含度量对象、指标、目标值及单位、测量条件。
- 目标值是否可比较，是否存在“尽量快”“较高”等无法判定的表述。
- 测量条件是否写明负载、数据量、时段和环境。
- 指标口径是否存在多种解释，例如响应时间的起止点是否统一。
验证方式可执行性检查
- 每条条目是否指定了验证方式（测试、监控、审查或演练）。
- 验证所需的环境、数据和工具是否可获得。
- 判定标准是否明确到他人可复核。
- 验证责任人和计划时间是否已落实。
遗留待澄清项处理
- 候选清单中标记为假设的条目是否已澄清或明确关闭。
- 无法量化的条目是否已拆分，拆分后的子条目是否重新通过上述检查。
- 遗留项是否有责任人和处理时限，是否在需求条目中可见。
四项检查全部通过，说明这批非功能需求已完成从识别到可验证要求的转化，可以进入后续的设计与测试计划环节。存在未通过项时，按检查结果回到对应环节处理，不将未验证条目直接标记为完成。
常见问题
非功能需求的目标值由谁拍板，业务方和技术团队意见不一致时怎么处理？
目标值的业务合理性由需求提出方确认，技术可行性由架构或技术负责人判断，两者职责不同。出现分歧时，建议把分歧落到具体数值和代价上：业务方说明该质量水平对应的业务损失容忍度，技术方给出达到不同目标值所需的架构调整和成本估算，再由双方在可接受水平上达成一致。目标值确认后回写到条目中，避免只停留在会议结论。
一条非功能需求同时涉及多个类别，应该拆开还是合并？
判断依据是测量对象和验证手段是否相同。例如“结算系统月底不能出问题”同时涉及可用性和数据一致性，两者的测量对象、统计口径和验证方式都不同，应拆成可用性条目和数据一致性条目分别验证。如果多个类别指向同一测量对象、可用同一验证手段判定，可以合并为一条并在描述中注明覆盖的类别。拆分后的子条目需要分别通过可测性检查。
当前技术手段观测不到的指标，能否先标记为已完成？
不能。可验证性检查不通过的条目应按原因处理：指标口径不清的回到业务方确认统计方式，测量条件缺失的补充场景参数，目标值无法判定的拆分为可分别测量的子条目。确实缺少观测手段的，先确认是否存在替代观测方式，例如用日志抽样代替实时监控；仍无法观测的标记为待澄清，写明责任人和处理时限，在需求条目中保持可见，不直接视为完成。
非功能需求量化后，在开发和测试阶段如何保持可追踪？
量化条目应作为独立的需求工作项管理，记录度量对象、指标、目标值、测量条件和验证方式，并与对应的测试用例或监控方案建立关联。验证结果回写到条目中，未通过项回到量化或澄清环节。团队可以把这类条目和验证状态记录在需求工作项中，并与测试用例建立关联。ONES 的需求管理与测试管理能力可承载条目化记录和状态跟踪，ONES Assistant 可围绕 PRD 质量检查提炼待澄清问题与拆解建议；具体功能范围以实际部署和套餐为准。
小团队没有专职的需求分析人员和测试人员，角色分工怎么落地？
角色可以兼任，但每项交付物仍需有明确责任人。小团队常见的做法是产品经理承担识别和量化整理，技术负责人确认指标可行性，开发或测试人员确认验证方式可执行。关键是保留交接物：候选清单、量化条目表、验证方式说明，即使由同一人完成，也应分别留存，便于后续复核和追溯。团队规模扩大后再按环节拆分职责。
