web

功能性需求与非功能性需求

第 5 章 · 软件工程

先看两条需求。 第一条：「系统要快。」开发问：「多快算快？」产品说：「反正要快。」上线后客户抱怨慢，开发说「我们觉得挺快的」——谁也说不清到底有没有达标。第二条：「列表页在正常网络下 2 秒内完成加载，支持 50 人同时查询不降级。」开发按这个写性能测试、做压测，验收时测一把，过了就是过了、没过就是没过。同是「快」这件事，虚着说没法验收，量化成可测条件才能验收。功能需求也一样：「用户能登录」比「系统要好用」清晰得多。本章专门讲功能性需求（FR）与非功能性需求（NFR）：各自说什么、怎么写、以及NFR 的表述与可验证性，让你写出的每一条需求都能「做得到、验得收」。

一、功能性需求（FR）：系统「做什么」

功能性需求描述的是系统应当提供的功能、行为、输入与输出——即「系统做什么、用户能完成什么操作」。例如：用户能注册与登录、能创建和查询订单、能导出报表、管理员能审核申请。每一条 FR 应当对应可执行、可验证的行为：做完后能通过操作、用例或测试来确认「做到了」。

功能性需求（FR）
  • 系统「做什么」：功能、行为、输入输出
  • 典型表述：「用户应能…」「系统应能…」「在 X 条件下系统应…」
  • 验收：通过操作、用例或自动化测试验证
非功能性需求（NFR）
  • 系统「做到什么程度」：性能、安全、可用性等
  • 典型表述：指标、约束、质量属性（需量化）
  • 验收：通过测试、监控或检查清单验证
FR 说「做什么」，NFR 说「做到什么程度」；两者都要可验证

写好 FR 的要点：主语明确（谁：用户、管理员、系统）；行为具体（能登录、能按条件筛选、能导出），避免「能方便地…」「能更好地…」这类模糊词；条件与例外可写清（例如「在已登录状态下，用户能…」）。一条 FR 对应一个可测试的 capability，不要一条里塞进多个功能。这样设计、开发、测试才能对齐，验收时也有据可查。

二、非功能性需求（NFR）：做到什么程度

非功能性需求描述的是质量属性、约束或程度——不直接说「做什么」，而是说「做到什么程度、满足什么限制」。常见类别包括：性能、安全、可用性、可扩展性、兼容性、可维护性、可用性（易用性）等。下面用一张图概括几类 NFR，并各给一句示例。

性能
响应时间、吞吐量、并发数。例：接口 P99 < 500ms，支持 200 QPS。
安全
认证、授权、加密、审计。例：密码加密存储，敏感接口需 Token。
可用性
系统可用率、恢复时间。例：可用性 99.9%，故障恢复 RTO < 30min。
可扩展性
容量与负载增长时的表现。例：支持水平扩展至 10 节点。
兼容性
浏览器、设备、接口版本。例：支持 Chrome/Edge 最近两版。
可维护性
可观测、可配置、可部署。例：关键路径有日志与指标、配置外置。
常见 NFR 类别：性能、安全、可用性、可扩展性、兼容性、可维护性等

这些类别在实际项目中往往同时存在：一个系统既要「能查订单」（FR），也要「查的时候 2 秒内出结果、100 人同时查不挂」（NFR）。NFR 写不好，最容易出现的就是「感觉没问题」但验收时扯皮——所以下一节专门讲 NFR 怎么表述才能可验证。

三、NFR 的表述与可验证性

NFR 最大的坑是写得太虚：「系统要快」「要安全」「要稳定」——快多少？安全到什么程度？稳定如何衡量？无法验收。解决办法是：尽量量化、可测、可观测。

从模糊到可验证

把模糊表述转成可度量、可测试的表述。例如：「要快」→「列表页首屏加载时间 < 2 秒（正常网络）」「接口 P99 延迟 < 500ms」；「要安全」→「密码 bcrypt 存储」「传输 TLS 1.2+」「敏感操作留审计日志」；「要稳定」→「可用性 99.9%」「单点故障后 30 分钟内恢复」。每条 NFR 最好能回答：用什么指标、在什么条件下、达到什么阈值、如何测量。

模糊（难验收） 可验证表述
系统要快 列表页 2 秒内加载；接口 P99 < 500ms
要安全 密码加密存储；HTTPS；敏感操作有审计日志
能撑住大流量 支持 500 并发用户不降级；可水平扩展至 N 节点
好用、体验好 关键操作 3 步内完成；支持键盘快捷键；错误有明确提示
NFR 从模糊到可验证：给出指标、条件与阈值

SMART 与验收方式

写 NFR 时可以借鉴 SMART 思路：Specific（具体）、Measurable（可度量）、Achievable（可实现）、Relevant（相关）、Time-bound（有时限或条件）。核心是可度量：要么有数字（时间、比例、并发数），要么有检查项（「是否 TLS」「是否有日志」），这样验收时才能客观判断。

验收方式大致有三种：测试（性能测试、安全扫描、兼容性测试）；监控与指标（上线后看延迟、错误率、可用率是否在约定范围内）；检查清单（部署前检查配置、证书、日志是否到位）。在需求里写清「如何验收」，能避免交付时「你觉得达标、我觉得没达标」的争执。

NFR 可验证性：量化表述 → 选定验收方式 → 达标/不达标可判定

一句话： FR 写「谁在什么条件下能做什么」，行为具体、可测；NFR 写「做到什么程度」，用指标、条件、阈值量化，并写明如何验收（测试、监控或检查清单）。两者都做到无歧义、可验证，设计和验收才有据可依。

小贴士： 若干系人只说「要快」「要安全」，你可以主动追问：「快的话，有没有参考？比如 2 秒内能接受吗？」「安全方面，最担心的是账号被盗还是数据泄露？有没有合规要求？」把抽象期望转成可写进需求文档的条款，是需求分析的重要一步。

四、小结

功能性需求（FR）描述系统「做什么」——功能、行为、输入输出；表述要主语明确、行为具体，一条一能力、可测试。非功能性需求（NFR）描述「做到什么程度」——性能、安全、可用性、可扩展性、兼容性、可维护性等质量属性与约束。NFR 最容易出的问题是写得太虚、无法验收；解决办法是量化：给出指标、条件、阈值，并写明验收方式（测试、监控、检查清单）。借鉴 SMART 中的「可度量」，让每条 NFR 都能客观判定达标与否。下一章我们讲需求规格说明与验收标准：如何把需求整理成规格说明书、如何定义验收标准与 Definition of Done、以及需求变更与基线管理。