非功能需求

1 功能需求写清「做什么」，非功能写清「做到什么程度」

P2 需求调研把角色、证据和可测试的功能需求连了起来。现在继续使用连锁零售的订单场景：店员扫描商品，系统计算金额，顾客付款，订单保存，库存扣减。这些动作回答「系统做什么」，属于功能需求，简称 FR。可是，能够完成动作还不足以说明系统适合营业。高峰时顾客等多久、故障后多久恢复、订单最多丢失多少、谁能修改库存，都需要另写约束。这类要求叫非功能需求，简称 NFR。

比较同样的下单动作。FR 可以写成「店员提交合法订单后，系统生成订单号并返回金额」。NFR 可以写成「在约定负载和观测窗口内，成功订单请求的 P95 响应时间不超过 800 ms」。前者用输入与输出检验行为，后者用条件与指标检验行为的质量。付款失败后不得扣减库存是业务规则，不能因为带有「不得」就归入 NFR；限制店员只能操作所属门店，则体现访问控制要求，也需要功能机制支撑。分类的目的在于补齐验收证据，不必为了标签争论。

NFR 至少应有指标、窗口和责任人。指标说明量什么，窗口说明在哪段时间、哪些样本中量，责任人说明谁提供证据、谁推动修复。再补上适用场景、数据来源、依赖和排除条件，才能避免同样的数字得到相反结论。「接口必须快」没有测量入口；「平均响应低于 800 ms」可能掩盖少量特别慢的交易；「上线当天很快」也无法代表促销时段。清楚的约定应当允许另 1 位工程师按同样方法复测。

P2 的调研材料正好提供这些输入。店长说收银队伍超过 5 人会影响营业，可以继续调查高峰到店率与可接受等待时间；财务说每天要对账，可以追问可接受的数据缺口；运维提供历史故障记录，可以帮助估算恢复步骤。访谈表达的是风险与期望，还不是已经批准的指标。方案作者需要把证据、候选目标、实现成本和业务取舍交给负责人确认，保留来源，避免把个人猜测写成合同。

本课采用 20 家门店的 MVP 作为贯穿案例。MVP 表示先交付必要业务能力，并不意味着可以省掉恢复、权限或观测要求。我们会把宽泛口号逐步改成能执行的约定，再把约定接到云服务选型。先写清业务需要承受的边界，后面比较产品时才知道哪些能力值得付费。

2 可用性与恢复：SLA、RTO、RPO 怎么写才可测

「订单服务要高可用」无法直接验收。先问营业受影响的具体形式：是页面打不开，还是提交后没有收到有效订单号？本案例把用户可见的可用性定义为：营业时段内，符合约定的合法下单请求能够在 3 s 内返回可识别的业务结果，技术错误和超时计为失败。库存不足等正确的业务拒绝不算技术失败，但应单独统计。请求样本、营业时间、重试去重规则和监控覆盖范围必须固定，否则可用率会随统计口径变化。

SLA 是服务等级协议，通常含适用范围、计算方式、免责条款与补偿条件。云厂商承诺的虚拟机或数据库 SLA，覆盖的是对应服务边界。你向门店提供的用户可见服务，还经过网络、应用、数据库和支付网关。SLO 是你为服务设定的目标，本例采用「自然月营业时段合法订单请求可用率至少 99.9%」。SLO 可以用于内部管理，也可以作为业务协议的输入；不能直接把某个组件的 SLA 当成完整订单链路的实际表现。

恢复要求要把服务恢复和数据恢复分开。RTO 是恢复时间目标，本例约定订单 API 的 RTO≤30 min。为了让它可测，演练记录从故障导致有效下单不可用的时刻 t0 开始，到恢复后连续 5 min 探测与抽样下单均通过的时刻 t1 结束，要求 t1−t0≤30 min。这样故障发现、通知、切换和恢复验证都消耗预算。若团队选择从宣告事故时计时，必须明确写出，并另约定故障发现时限，不能悄悄删去无人发现的停机时间。

订单数据库的 RPO≤5 min，表示恢复后允许丢失的数据时间跨度最多为 5 min，不表示允许丢失 5 条订单。演练可以持续写入带有提交时间与递增序号的测试订单，记录故障前已确认提交的集合，再恢复数据库并核对。以故障时刻与恢复后最近连续完整的可恢复提交点之间的差验证 RPO，同时检查中间是否缺号、是否重复。单看「备份每 5 min 执行」不够，备份失败、日志未传完、恢复不可用都可能扩大损失。

把口号改写为可验收条目，可以得到：「模拟订单主库不可用，采用批准的恢复流程；API 从业务中断到恢复验证完成不超过 30 min；恢复数据与故障前提交记录相比，连续可恢复提交点落后不超过 5 min；由运维负责人执行，业务负责人核对订单差异。」演练必须在隔离环境或批准的演练范围内进行，并保留时间线、恢复记录和订单核对结果。对已经支付但订单待确认的记录，应通过幂等处理与对账补偿，不能把恢复目标当成任意删除账目的许可。

RTO 与可用率互相关联，却不是同个指标。每次故障都在 30 min 内恢复，仍可能因为故障频繁而达不到月度 SLO；整月没有事故，也不能证明恢复流程已经可用。因此既要持续监测，也要定期演练。支付网关若需要 2 h 恢复，你的 30 min 目标必须说明是否包含支付；若仅保证创建待支付订单，应明确提示用户和门店，不能声称完整交易已经恢复。

3 性能与容量：延迟、吞吐、峰值与观测窗口

性能条目需要同时写响应时间、负载和测量窗口。延迟描述请求经历的时间，吞吐描述单位时间完成的工作量，并发描述同个时刻尚未完成的工作数量。200 单/小时是订单到达率，不能直接替换成 200 个并发用户。每单可能调用多个接口，顾客也可能停留在页面上很久。容量讨论若混用这些概念，压测结果看似准确，实际测试的却是另个业务场景。

本例先写成：「20 家门店合计以 200 单/小时到达率持续提交订单，预热 5 min 后进入连续 15 min 测量窗口，成功下单请求的 P95≤800 ms。」P95 表示排序后约 95% 的样本不超过该值，具体分位数算法由报告注明。200 单/小时持续 15 min 只有约 50 次下单，适合作为此处的基本验收负载，统计稳定性有限。需要比较小幅优化时，应增加独立重复窗口或延长测试，分别报告结果，不能用很少的样本宣称尾部延迟已经稳定。

负载还要包含数据与行为。测试库放入与预计上线相当的商品、订单和索引数据；请求来自 20 家门店，使用合法账号与不同商品组合；支付使用延迟分布明确的测试替身，另做真实网关联调。预热期间建立连接、加载必要缓存，预热样本不进入正式窗口，但单独保留。冷启动体验若对营业重要，应另设冷启动场景，不能永远用预热把它隐藏。

正式测量从负载发生器发送请求前计时，到读完响应体结束。记录每次请求的时间、耗时、状态、门店和关联标识。报告成功请求 P95 的同时，还要报告技术失败率、超时数、实际发送量和完成量。否则系统只需快速拒绝请求就可能得到漂亮的延迟数字。本例要求正式窗口技术失败率≤1%，超时按失败计算，并在 3 s 截止时间内终止等待。低样本窗口中，失败数还应直接列出，避免百分比掩盖实际事件。

峰值另开场景：以 600 单/小时持续 5 min，保持同样的数据与业务比例，检查是否触发扩容、排队和限流，并记录恢复到基线所需时间。峰值测试的通过条件须单独批准，不能将基线的 800 ms 自动套上去。本例为该场景暂定 P95≤1200 ms、技术失败率≤1%，上线前由店长确认体验可接受。若按固定并发施压，服务变慢时到达率可能下降；使用按计划时间发送的到达率模型，并记录未能按时发送的请求，才能看出压力是否真的达到要求。

错误预算是目标允许的失败空间。月度可用率目标为 99.9%，对应合格请求中最多 0.1% 的不可用比例；它不是「可以随意制造故障」的额度。15 min 性能窗口的 1% 技术失败阈值与月度目标属于不同统计窗口，必须分别通过。短时测试通过不代表月度可用性达标。预算消耗过快时，应暂停高风险发布、排查原因，再决定是否继续扩大流量。

4 安全与合规：最小权限、审计、数据分级入门

「系统安全可靠」同样不能作为验收条件。先从业务角色开始：店员需要创建所属门店订单、查看当班必要信息，以及提交库存调整申请；不需要导出全部顾客电话，也不需要修改其他门店库存。最小权限要求只授予完成工作所必需的操作和数据范围。账号属于店员并不足够，接口还必须根据可信身份检查门店范围，不能只依赖前端隐藏按钮或请求中自报的门店编号。

可测条目可以写成：「店员账号访问其他门店的库存读写接口时返回拒绝，不返回敏感字段；对请求中的门店编号与订单编号分别做越权测试。」测试既覆盖正常操作，也覆盖修改 URL、请求体和批量接口的情况。离职账号停用时限也要约定，例如人事确认离职后 30 min 内禁用登录并撤销有效会话，由门店管理员执行、平台负责人抽查。共享账号会削弱追责能力，应使用个人账号并保留角色授予记录。

库存调整需要回答「谁在何时把什么改成什么」。审计记录至少包含操作者标识、角色、门店、对象标识、调整前后值、原因、时间、结果和关联请求标识。普通店员不能修改或删除审计记录；负责排障的人只能按授权读取。此处约定审计保留 180 天，抽取测试调整核对记录完整性，并验证普通账号的删除请求被拒绝。保留时间需要结合实际法务与业务要求确认，不能把教材示例当成所有行业的法定期限。

数据分级从字段清单开始。本例的个人信息包括顾客姓名、手机号、收货地址、会员标识，以及能关联到个人的订单记录；员工账号与操作记录也可能关联个人。商品公开名称可以按公开信息处理，采购价格、经营报表按内部敏感信息处理。字段级别要映射到收集目的、可见角色、保存期限与删除方式。若门店自提不需要收货地址，就不要为了「以后可能有用」默认采集。

验收时检查手机号在普通列表中是否按规则掩码，日志是否避免记录完整地址、访问令牌和支付敏感信息，导出是否需要授权并留下记录。传输和存储保护应列为方案约束，但具体加密算法、密钥轮换机制留给后续专题展开。当前必须明确责任边界：谁维护字段清单，谁批准访问，谁核查留存与删除。仅勾选云产品的加密开关，无法替代应用权限、日志脱敏和合规判断。

5 成本与弹性：账单上限、突发流量、关停策略

成本也是质量约束。20 家门店 MVP 在 Q1 运营期采用「每个自然月云资源总支出≤8000 CNY」的目标，范围包括计算、数据库、存储、备份、网络流量、日志和监控，税费按账单约定口径计入。支付通道手续费若由另份业务预算承担，应明确列出，不能在月末才解释遗漏项。Q1 指项目批准的第 1 季度运营期，落地文档需要补充准确起止日期。

8000 CNY 是目标，不是设置预算告警后平台就会自动保证的硬上限。按日更新账单预测，当预测月末支出达到 6400 CNY 时通知成本负责人，达到 7200 CNY 时启动人工复核和非必要资源收缩。告警有延迟，流量计费也可能滞后，因此仍需资源配额、扩容上限和关停预案。每次动作都记录预计节省额与业务影响，不能为了账单达标破坏已承诺的订单安全。

弹性策略应表达触发条件、执行动作和停止边界。本例先设候选策略：应用层 CPU 持续 3 min 高于 65%，且请求队列持续增加时，从 2 个实例逐步扩到最多 6 个；每次扩容后观察 3 min 再决定是否继续。正式阈值要由压测校准，因为数据库锁等待或外部支付变慢时，增加应用实例可能无效，甚至放大下游压力。实例上限与数据库连接配额需要配合设计。

账单异常时，可以先关闭非 Must 功能，例如实时经营大屏、推荐刷新、批量历史导出；必须保留下单、支付结果确认、库存一致性处理和审计。关停开关需要有负责人、适用条件、回退方式和演练记录。关闭导出时，前端要显示稍后重试与任务状态，后台要停止继续产生费用，不能只隐藏入口而让任务持续运行。Must 的边界来自 P2 的优先级判断，任何调整都要让业务负责人知道影响。

验收成本策略时，可以用模拟账单事件触发告警，在测试环境切换非必要功能，并观察核心订单链路是否仍通过。用峰值测试验证扩容速度和资源上限，依据资源时长与单价估算支出，再以真实账单校正。节流目标与性能目标发生冲突时，应留下取舍记录：降低非必要功能的新鲜度、预约高成本任务，或者申请更高预算。不能同时承诺无限峰值、固定低价与完全不降级。

6 把 NFR 写进验收：场景、负载、通过条件

合格的验收协议应让另 1 位工程师不依赖作者口头解释就能执行。文档首先固定版本、环境配置、数据规模、依赖模式和时间同步方式，再列场景、负载、指标、窗口、阈值、责任人与证据位置。每项要求有稳定编号，例如 NFR-PERF-01；测试报告引用编号，失败工单也引用编号。这样修改阈值时可以追踪依据，避免每次评审换种措辞却无法比较。

性能协议可以写成可移植的脚本轮廓：准备 20 家门店测试身份；生成不重复的业务请求号；按计划发送时刻以 200 单/小时产生订单；预热 5 min；正式采样 15 min；为每次请求设置 3 s 截止时间；输出逐请求记录及汇总报告。脚本参数包含接口地址、凭证来源、商品数据、速率和随机种子，凭证从运行环境注入，报告不得输出密钥。接口遵守标准 HTTP 即可，工具选择不应成为需求的隐含条件。

执行人员要先检查实际发送量是否达到计划、负载机是否自身饱和、系统时钟是否同步，再判断服务表现。失败请求保留在记录中，重试作为新尝试关联原始业务请求号，分别报告尝试次数与最终业务结果。幂等性测试要检查重复提交没有生成重复订单。若依赖使用测试替身，报告明确写出响应延迟与错误注入比例；这份结果只证明该依赖条件下的能力。

通过条件是组合判断：数据无重复扣减等业务不变量通过，负载达标，P95 和技术失败率均达标，证据齐全，才判定该场景通过。数据库恢复场景另附提交记录与恢复核对表；安全场景附权限矩阵和拒绝样本；成本场景附告警与开关事件。仅截图某个监控面板不能证明所有要求满足，尤其无法证明已丢弃请求或未记录的错误。

验收结果可为通过、失败或证据不足。负载机中途掉线导致样本缺失，应判证据不足并重跑；观察到超阈值则先保留失败，再分析原因。修复后使用同样的协议复测，记录版本变化。上线后的持续监控沿用这些定义，但生产窗口与验收窗口分开报告，避免把实验室的短时结果包装成长期运营承诺。

7 常见坑：复制厂商 SLA、只写 99.99%、忽略依赖

常见错误是把产品宣传页上的 99.99% 粘进方案，却没有写分母、时间范围与业务入口。按 30 天全天时间口径计算，99.99% 约允许 4.32 min 不可用；换成营业时间或请求成功率，解释就变了。这个换算只能帮助理解目标严格程度，不能替代协议。只有写明什么叫失败、哪些请求纳入统计、探测是否覆盖真实链路，数字才有意义。

再看依赖链：门店网络、入口服务、订单应用、数据库、支付网关都可能阻断交易。若组件彼此独立且必须同时成功，整体成功概率可以用乘积作粗略估算；现实中还可能共享网络或机房，不能拿独立假设作保证。需要画出同步依赖，标出谁控制、失败时怎样表现、是否有超时和补偿，再验证业务结果。缓存命中率很高也无法证明支付确认链路可用。

忽略支付网关 RTO 会让恢复目标无法兑现。自有 API 在 20 min 内恢复，而网关仍中断 2 h，顾客仍然无法完成在线付款。可以约定恢复范围仅覆盖待支付订单创建，并让门店采用经过批准的替代流程；也可以提高完整交易链路的恢复能力并承担成本。选哪种由业务风险决定，文档必须直接说明，不得在事故后临时缩小目标。

没有责任人的 NFR 也容易失效。「每月检查恢复能力」若无人安排演练，就只是愿望。条目需要执行负责人、批准人和证据位置；负责人离岗时有交接。另个陷阱是只约定平均值，或者把所有请求放在整月大窗口中，掩盖门店开门时持续 10 min 的异常。应保留门店、接口、时间段等必要维度，在总体 SLO 外配置短窗口告警，并说明告警用于排障，不会擅自改变正式验收口径。

最后，指标过多也会拖垮执行。先保留能对应营业损失、数据风险、合规责任和预算约束的关键条目，明确可采集的证据。尚未确认的目标标成待批准，并指定验证方法。不能把所有候选数字都写成正式承诺，也不能因为尚无精确数据就退回「稳定、安全、快速」这样的口号。

8 案例：订单 API 的一页 NFR

下面把 20 家门店 MVP 的讨论压缩为可评审的记录。适用边界为门店员工通过订单 API 创建并查询订单，覆盖订单应用与订单数据库；支付网关属于外部依赖，完整支付另有联调与故障场景。业务负责人批准目标，平台负责人维护证据索引。表格是摘要，每个编号都必须链接到前述详细协议，不能让压缩版吞掉计量口径。

评审时先查矛盾。例如峰值能否在 6 个实例上限内达标，180 天审计存储是否已计入预算，30 min 恢复是否有足够自动化与值班支持。若测试证明 8000 CNY 无法同时满足所有条件，应把差额、风险和替代方案交给负责人决策。降低目标需要批准与版本记录，不能通过删去失败样本实现「达标」。

这份摘要还应标记状态。已批准目标进入验收基线；像峰值体验和合规留存期限这样的待确认项，应在上线前关闭。实际评审使用明确姓名或岗位值班表，避免「相关同事」这样的模糊归属。每次修改记录日期、原因、证据与批准人，让后续云产品比较能够引用同份需求基线。

9 排查案例：上线后「感觉慢」如何对照 NFR 取证

上线后收到 3 次投诉：「早上点单一直转圈」「下午提交等了很久」「傍晚付款结果迟迟不出现」。不能直接回答「监控正常」，也不能仅凭投诉就宣布所有 NFR 失守。先为每次反馈补齐门店、时间范围、业务请求号、具体操作和用户观察到的等待时长；不要求店员收集完整个人信息。再用关联标识串起客户端、入口、应用和依赖日志，保留当时版本与发布记录。

早间反馈发生在 09:00—09:15。入口记录显示约定负载下有 50 次正式可比请求，49 次成功，其中 3 次超过 800 ms；按协议约定的最近秩算法，P95 为 1100 ms，另有 1 次技术失败，失败率为 2%。负载与样本条件满足时，这个窗口违反了性能阈值。追踪发现数据库连接池等待增加，可以据此提出修复假设。月度可用率是否失守仍需看完整月统计，不能用这 15 min 的结果替代。

下午反馈对应 1 次 2.4 s 的成功请求。同窗口 50 次请求中，其余 49 次均低于 700 ms，无技术失败，P95 仍达标；2.4 s 也未超过可用性定义的 3 s 截止时间。因此现有这组指标没有违约证据，但顾客确实遇到慢请求。应记录尾部个案、检查锁等待或冷缓存，并评估是否需要增加 P99、单请求超时告警或交互反馈。改进体验与追认违约是不同决定，不能倒推修改原有阈值。

傍晚反馈中，订单 API 在 420 ms 内返回待支付订单，页面继续等待支付网关 8 s。这不违反限定为创建订单的 800 ms 指标，却暴露完整付款体验缺少约束。检查网关状态、超时配置、回调和订单状态迁移，确认没有重复扣款。若业务曾承诺「付款确认在 3 s 内完成」，应按那条端到端要求判断；如果根本没有该要求，补充依赖窗口和超时后的用户提示，不能把现有 API 结果当成整个体验合格的证明。

排查报告应分开写事实、判断与行动：事实引用日志和样本，判断引用具体 NFR 编号，行动指定负责人和复测时间。日志缺失时写证据不足，并补充采集，不凭印象宣称达标。修复连接池问题后重跑对应协议，再观察生产窗口；补充付款体验要求则进入需求变更，重新讨论成本与依赖。这样，「感觉慢」既能成为真实问题的入口，也能转化为可复核的改进记录。

放进方案里

方案中的 NFR 页应紧接 P2 形成的业务范围与功能清单。开头说明服务对象、门店规模、营业时间、上线阶段和依赖边界，再列出已批准目标。每项使用固定编号，让评审意见、测试报告和上线监控能引用同条要求。不要把「高可用、低延迟、安全合规、成本可控」单独做成结论页；这些词只有关联到测量协议与负责人，才具备决策价值。

逐项检查以下字段是否齐全：指标写清单位与成功、失败定义；来源写清访谈证据、业务损失或历史记录；窗口写清自然月、正式采样时段与预热排除；责任人写清执行、批准和证据维护角色；依赖写清支付、网络、数据库等条件与降级范围。再补上负载、数据规模、阈值、原始记录位置和复测方法。任意字段为空，都要标明待确认事项与解决时间，不得用默认理解补齐。

把订单案例改成方案语言，可以写：「20 家门店合计 200 单/小时，预热 5 min 后连续采样 15 min，成功下单请求 P95≤800 ms，技术失败率≤1%；测试负责人提供逐请求记录；支付替身延迟参数随报告归档。」恢复条目另列 API RTO≤30 min、订单库 RPO≤5 min，并引用演练协议。安全与成本条目也按同样结构写，避免只给性能留下证据。

评审时用依赖链检查承诺是否完整，再用预算检查实现是否可承担。若目标冲突，列出提高预算、调整范围或降低目标的选择，记录业务批准结果。厂商 SLA 放在服务选型依据中，并说明覆盖边界；用户可见 SLO 保留在需求页。拒绝只有口号的幻灯片，也拒绝只有数字却没有来源、窗口和责任人的表格。方案交付时，目标、协议、证据索引与未关闭风险应能够相互追溯。

10 小结：NFR 清单接到云服务选型

功能需求说明行为，NFR 给行为划定可测的质量边界。使用指标、窗口、负载、依赖和责任人，把可用性、恢复、性能、安全与成本连接到验收证据。能解释失败，也能让另 1 位工程师复测，才算写到位。

自查：备份每 5 min 执行能否证明 RPO≤5 min？单次请求耗时 2 s 是否必然违反 P95≤800 ms？支付网关故障时，订单 API 恢复是否代表完整交易恢复？回答都需要回到测量口径与服务边界。

沿 S3 路径继续学习时，可用这些负载和等待证据理解系统如何安排工作；云课程并行推进时，则把 NFR 清单作为服务选型输入，比较恢复能力、容量边界、权限机制和总成本，并用验收协议验证选择。

下一课转向 P4 容量估算：把本章验收过的结论带进后续主题，写成可检查的方案约束。