功能性需求与非功能性需求：性能、安全与可用性
做网站或 SaaS 时，很多人把"需求"等同于"功能列表"，却漏掉了定义"系统做得怎么样"的那部分。IIBA 的 BABOK 指南明确区分了两类需求：功能性需求描述系统必须做什么，而非功能性需求（BABOK 中也称质量需求）描述系统在多大程度上满足这些功能。
两类需求的区别
| 维度 | 功能性需求 | 非功能性需求 |
|---|---|---|
| 回答的问题 | 系统做什么 | 系统做得怎么样 |
| 例子 | 用户能注册、能支付、能导出报表 | 页面 3 秒内加载、数据加密存储、可用性 99.9% |
| 可测性 | 通常可明确验收 | 需要量化指标，如响应时间、并发数 |
| 常见来源 | 用户故事、业务流程 | 性能、安全、合规、可用性约束 |
IEEE 29148 等软件工程标准也采用类似划分：功能需求定义行为，质量需求定义行为应达到的程度。
常见的非功能性需求类型
- 性能：响应时间、吞吐量、并发用户数，例如"API P95 响应 < 200ms"。可参考Core Web Vitals来量化前端体验。
- 安全：认证授权、数据加密、审计日志、合规要求（如 GDPR），可结合网站安全最佳实践落地。
- 可用性：正常运行时长占比（SLA），例如 99.9% 可用性，对应SLO 与错误预算。
"99.9%"听起来只是少一个 9，实际可用时间差别很大：
| 可用性 | 年停机时间 | 月停机时间 | 适合场景 |
|---|---|---|---|
| 99% | 87.6 小时 | 7.3 小时 | 内部工具、非关键系统 |
| 99.9% | 8.76 小时 | 43 分钟 | 大多数商业站点 |
| 99.95% | 4.38 小时 | 21 分钟 | 交易型网站 |
| 99.99% | 52.6 分钟 | 4.3 分钟 | 支付、核心基础设施 |
写 SLA 时，先回答"业务能容忍多久不可用"，再倒推技术方案——99.99% 通常意味着多可用区 + 自动故障转移，成本和复杂度都不是中小站点随手能承担的。
- 可扩展性：流量增长时能否水平扩展，常见于技术栈评估环节。
- 可维护性与可访问性：代码可维护、无障碍（a11y）达标。
为什么非功能性需求总被忽略
非功能性需求没有"按钮"可以点，容易被当成"以后再说"。等上线才发现慢、不安全、撑不住流量，返工成本极高。写PRD时，应给每类非功能性需求写下"可度量的验收标准"，而不是"系统要快、要安全"这类模糊描述。
如何在 PRD 中写清楚
- 量化：把"性能好"改成"首屏 LCP < 2.5s、API P95 < 300ms"。
- 场景化：注明峰值场景，例如"支持 500 并发、单日 10 万请求"。
- 给验收方法：写明用什么工具测、阈值多少，方便 QA 与验收标准对齐。
- 定优先级：并非所有质量属性都同等重要，用需求优先级框架取舍。
举个具体的写法对照：
| 模糊写法 | 可度量写法 |
|---|---|
| 系统要快 | 首页 LCP < 2.5s（移动端中位数） |
| 要撑得住流量 | 促销峰值 1,000 并发、单日 100 万请求，P95 延迟 < 300ms |
| 数据要安全 | 传输 TLS 1.2+，静态加密，敏感字段脱敏 |
| 要可靠 | 月可用性 ≥ 99.9%，每季度做一次故障演练 |
权衡与取舍
性能、安全、成本常常此消彼长：更强的加密与审计会增加延迟，更高的冗余会提高成本。BABOK 的价值在于把"取舍"显性化——每条非功能性需求都记录其约束与折中，让团队在开发前而非上线后做决定。
质量属性要持续验证
非功能性需求应当贯穿整个开发周期，而不是写进 PRD 就结束：性能在联调期就要做压测，安全在编码期就要走查，可用性在上线前就要演练。把这些质量属性纳入持续集成与监控告警，让它们像功能需求一样被持续验证，才不会在发布后才发现问题。对已经上线的产品，还可以用真实流量数据（如响应时间分位、错误率）反向校准最初设定的阈值，让质量目标随业务增长而演进。
一个被"以后再说"拖垮的例子
某电商团队上线前 PRD 只写了功能清单，"并发支撑"一栏写的是"需要稳定"。双 11 当天首页接口 P95 延迟从 300ms 涨到 6 秒，订单页超时率飙升，最终通过限流保住了支付链路，但错过了大量加购转化。复盘时发现：如果当时把"峰值 5,000 并发、P95 < 300ms"写成可度量的验收标准，压测会在联调期就暴露瓶颈，而不是等到大促当天。
非功能性需求的代价在于：它们不会在上线当天"报错"，只会以缓慢、累积的方式变成事故。这也是为什么建议把性能、安全、可用性目标写进 CI 的自动化检查里，而不是只留在 PRD 文档中。
参考：IEEE 29148 软件需求工程标准 https://standards.ieee.org/ieee/29148/6710/；IIBA BABOK 指南 https://www.iiba.org/business-analysis-body-of-knowledge/
16IDC 观察
对中小网站来说，非功能性需求不必一上来就"全都要"。建议先锁定 3-5 条关键质量属性（通常是性能与安全），写成可度量的标准；随着业务增长再补充可扩展性与可用性目标。真正区分成熟团队与草台班子的，往往不是功能多少，而是"做得怎么样"有没有被定义清楚。
原文来源：https://www.iiba.org/business-analysis-body-of-knowledge/