非功能需求
性能、安全、可靠性目标——直到漏掉才可见。
为什么
功能需求说系统做什么；非功能需求说它做得多好。NFR 是"演示好看"和"扛得住生产"的区别：10 秒响应在演示里"能用"，在真实世界失败。显式写 NFR——p99 延迟 < 200ms、99.9% 可用、PII 静态加密——让它们可测，防止"以后再优化"陷阱造出又慢又没安全的 MVP。NFR 也是容量规划和成本估算的基础。
何时使用
在 PRD 里与功能需求并列。一个特性 1-2 小时。仅对无 SLA 期望的内部工具可跳过。
如何做
1. 为每个 NFR 类别写具体可测目标： - 性能："1000 RPS 下 p99 API 延迟 < 200ms" - 可靠性："月度 99.9% 可用，RTO < 5 分钟，RPO < 1 分钟" - 安全："PII 静态加密（AES-256），传输 TLS 1.3" - 可扩展："无需改代码扛 10 倍当前负载" - 可观测："所有用户动作 1 秒内带 trace_id 记日志" 2. 每个目标注明如何验证（压测、混沌测试、审计） 3. 标哪些 NFR 是上线阻断 vs. 上线后加固 4. 让值班团队签字——他们拥有可靠性 NFR 5. 若 NFR 驱动架构选择，加进 ADR
示例
发票导出特性的 NFR： - 性能：1 万张发票 CSV 生成 < 5 秒（p99） - 可靠性：导出永不阻塞主计费流（异步队列） - 安全：导出 URL 签名、10 分钟过期、记审计日志 - 可扩展：队列深度在仪表盘可见；1000 待处理告警 - 可观测：每次导出发 trace 含 user_id、行数、耗时 验证： - 性能：k6 在 50 并发导出下压测 - 可靠性：混 沌测试——杀导出 worker，确认计费不受影响
常见问题
- ⚠把 NFR 写成愿景（"应当快"）而非可测目标——"快"无法测试或告警。
- ⚠把所有 NFR 当上线阻断——这会拖住上线；分清哪些真阻断、哪些可上线后加固。
最佳实践
- ✓性能用百分位（p99、p99.9）而非平均——平均藏住了用户实际体验的尾部。
- ✓把每个 NFR 绑到手册或告警，让值班团队能在违反时行动，而非只在仪表盘看到。