非功能需求描述系统在什么条件下达到怎样的质量水平，例如响应速度、可靠性、兼容性和数据保护。“支持导出报表”是功能需求；“在约定数据规模下，用户多久能拿到报表，失败后如何处理”则属于需要进一步明确的质量要求。
写好它的关键，是把“快、稳定、安全”换成具体场景、测量口径和处理规则。在整理需求、原型与评审材料时，把这些条件放在对应业务任务旁，产品、研发和测试才能讨论同一件事，而不是各自理解一个形容词。
“越快越好”不是可执行的需求
不同任务对质量的要求不同。用户在门店收银时等待，与财务发起月度离线报表后稍后下载，不能共用同一条“响应不超过几秒”。先问用户什么时候需要结果、等待会阻断什么、允许什么替代方式，再与研发讨论实现成本。
非功能需求也不是全部由产品单方面定数值。产品说明业务后果和容忍范围，研发提出架构与成本约束，测试确认测量方式，相关负责人接受最终取舍。指标看起来精确，不代表有依据；从别的系统复制一个数字，可能比没有数字更容易误导排期。
Microsoft 的以业务需要驱动架构的原则将恢复目标与业务容忍度联系起来，并指出更严格目标可能带来额外成本。这说明质量要求必须有业务理由，而不是越高越专业。
一条质量要求至少回答六个问题
可以用“谁在什么环境下，对多大范围做什么，达到何种结果，怎样测量，未达标如何处理”组织条目。以费用报表导出为例，不先写“高速导出”，而是先确定月份跨度、记录数、导出字段、并发任务以及用户是否需要同步等待。
| 字段 | 需要写清 | 报表导出的填写方向 |
|---|---|---|
| 业务场景 | 谁在完成什么任务 | 财务导出已结算月份的费用明细 |
| 负载条件 | 数据规模、并发与环境 | 约定记录规模、字段数和同时发起任务数 |
| 目标 | 可观察的质量水平 | 从提交任务到文件可下载的耗时目标 |
| 测量 | 起止点、样本与统计口径 | 排除人工操作时间，记录全部请求结果 |
| 异常处理 | 超时、失败、降级如何反馈 | 任务状态、重试与结果查询 |
| 责任与依据 | 谁确认，为什么需要 | 财务关账时间要求及技术评审结论 |
不确定的阈值先写待评估，但同时写出如何确定它：使用什么样本、谁来评估、何时确认。不要为了让PRD显得完整，先填一个没人同意的承诺。
质量目标之间也可能冲突。更长的文件保留期方便追溯，却增加存储和权限管理负担；允许一次导出更多记录减少操作次数，却可能让等待更长。把冲突写成选项：是限制单次范围、改成后台任务，还是提供更快的摘要报表，并分别说明对用户工作的影响。这样讨论的是方案取舍，而不是要求研发同时实现几个没有边界的形容词。
性能：先统一测量起点和数据条件
“响应时间”可能指接口返回、页面主要内容可用，也可能指报表文件生成完毕。如果产品关注的是拿到文件，却只测服务器收到请求后返回“处理中”的时间，指标再漂亮也没有回答用户问题。
一条可讨论的练习目标可以写成：“在约定测试环境和固定数据集下，连续发起100次不重叠导出任务，从服务端接受任务到文件可下载，至少95次在30秒内完成；失败请求单独统计并记录原因。”这里的100次和30秒只是条目格式示例，项目中必须根据业务与测试计划重新商定。
平均值容易掩盖少数很慢的请求。若使用P95等分位数，须统一统计方式、样本规模和失败请求处理，不能把失败样本丢掉后宣称“全部表现良好”。并发数也需要说明是同时在线人数、正在操作的人数，还是同时执行的导出任务。
可靠性：写清失败后用户还能做什么
对报表导出来说，除了成功率，还要讨论任务失败能否重试、重复点击是否产生重复工作、服务恢复后任务是否继续，以及用户在哪里找到结果。把“系统稳定”变成这些可检查的行为，设计和研发才知道需要哪些状态。
恢复时间目标RTO关注服务中断后希望多快恢复；恢复点目标RPO关注可接受的数据回退范围。它们是业务和技术共同约定的目标，不是本文替所有产品推荐的固定值。对只读报表、支付流水和临时草稿，容忍范围可能不同。
如果采用异步导出，原型中应出现排队、处理中、成功、失败及过期等需要的状态，并说明哪些可重新执行。不要只给一个旋转图标，然后在需求文档里写“异常情况研发处理”。
安全与兼容：把范围写出来
“数据安全”需要进一步说明谁能查看和导出哪些记录，文件链接是否有有效期，权限变化后已生成的文件如何处理，以及哪些操作需要记录。这里先定义业务规则，再由安全与技术人员确认实现；不要把“使用加密”当作所有风险已经解决。
兼容性也应有范围。桌面和手机分别支持哪些操作，目标浏览器及版本如何维护，窗口缩小时表格和下载入口能否使用，都需要在验收计划中明确。列出未经测试的所有系统并不能让兼容性更完整。
可访问性要求可以从任务出发补充：键盘能否发起导出、处理完成的消息能否被感知、错误是否只靠颜色表达。不是给一行“支持无障碍”就结束，而是把对应状态与操作列出来。
评审时检查指标是否真的可以被证伪
一条要求是否有用，可以反问：出现什么结果时，我们会承认它没有达到？如果大家只能回答“感觉还是有点慢”，说明目标或测量方式仍不清楚。若无法负担约定测试，也需要在排期前讨论替代方法和结论的适用范围。
验收记录最好与需求使用同一个编号。例如NFR-EXPORT-01连接负载条件、原型状态、测试记录和确认人；需求阈值调整时保留原因和生效版本。这样下一次报表字段增加，团队能找到需要重测的条件，而不必从一份已经与实际系统脱节的文档重新猜测。
- 场景是不是业务真正在意的任务，而不只是容易测的技术动作。
- 数据规模、环境、负载和时间窗口是否可复现。
- 失败、超时和异常样本是否有独立记录。
- 目标与成本、交付周期之间的取舍是否得到确认。
- 页面状态、接口行为与验收条目是否表达同一条规则。
完整文档结构可以继续参考PRD的功能、约束与验收章节。质量要求不必单独堆成一章难以追踪的大词清单；把每一项放回真实任务，读者才知道它保护的是谁的工作。
