非功能需求如何有效发现：从质量属性到可验收指标

1. 非功能需求不是“功能做完再说”，漏掉它才是风险的真正入口

我见过太多项目的需求文档，把用户能点的按钮、能走的流程、能看的页面画得明明白白，但在“多少人同时用、数据量涨十倍还跑不跑得动、磁盘满了怎么办、接口超时了要不要重试”这些非功能需求上一片空白。后来系统交付上线，出一两次可用性事故，或者客户一压测就穿帮，团队才回头补，可这时候补的每一行代码都在还债。

一句话解释：功能需求回答“系统做什么”，非功能需求回答“系统达到什么程度、在什么边界内成立”。它通常不会以“用户想要”开头，而是以“用户不想要”出现——不想要等太久、不想要数据丢、不想要半夜爬起来处理任务、不想要同一个报表因为浏览器的差异显示错乱。这些“不想要”没有写进需求文档，不代表用户没期待。产品、开发、测试如果只在功能圈里绕，等于把系统真正的生存条件交给运气。

更务实的做法是把非功能需求当成“验收条件”的一等公民，和功能流程并行收集，而不是等架构评审时才提一嘴。你要在需求访谈里追问边界，在设计评审里摆出度量口径，在开发计划里给NFR分配工作量。这个习惯一旦建立，所谓“发现”就不是某个人的灵光一现，而是一套能复用的方法。

1.1 非功能需求不是一张附加清单，而是一组系统约束

非功能需求常见的落点包括这几类：性能与容量、可用性与恢复、安全与隐私、可运维性、兼容性、可访问性、国际化，以及数据保存周期等。它们不像用户故事那样容易被排进迭代，因为它们往往要跨多个功能模块才能验证。比如“报表导出不能拖垮数据库”，听起来是个性能问题，实际牵涉到导出服务、数据库连接池、存储、任务队列和前端感知，如果没有在需求层拆开，开发很难知道资源瓶颈究竟在哪里。

所以发现NFR的第一步，是在拿到任何需求描述时顺手做一次分类。每看到一个功能，就问它背后有没有性能上限、有没有并发用户数、有没有数据增长预期、有没有异常恢复要求、有没有权限边界。分类不是用来写文档交差的，分类的用处是让不同角色能用自己的语言理解：测试知道要去压哪个接口，开发知道要预留哪一层缓存，架构师知道需不需要引入队列或分布式锁。

1.2 迟到的 NFR 会在哪个阶段爆出来

根据我的观察，NFR缺失的爆发点一般有三个阶段。

第一阶段是联调测试。功能测完，进入并发或长时间测试时，线程池满、数据库连接被占光、日志把磁盘写爆，这些问题通常和具体功能无关，而是容量预期缺失。第二阶段是首次上线或首次放量。真实用户的操作节奏和测试脚本不一样，有人反复刷新、有人上传超大文件、有人把筛选条件选得极其宽泛，系统立刻呈现出脆弱的一面。第三阶段是版本持续迭代。为了满足新功能，团队在原有架构上不停叠加，事务越来越大、定时任务越来越多，老系统变得难以维护。

先想清楚这些爆发阶段，后面“如何发现”才有意义。因为不是让你把每一条NFR都做成重量级的性能测试计划，而是根据项目阶段选最关键的几条先落地。

2. 需求挖掘的第一现场：人、文档和工单里全是线索

发现非功能需求不能靠会议室里拍脑袋，真正有效的素材来源有三个：干系人口中的场景、历史文档里的假设、线上事故和客服工单中的抱怨。你可以把它们分别理解成“将来时”“现在时”和“过去时”。过去发生过的故障最诚实，它不会骗你。

2.1 访谈时追着“量”和“异常”问

做需求访谈，我的习惯是不急着问“你要什么功能”，先问“多少人用、一天用几次、峰值是多少”。对方如果说不出具体数字，就让他描述上一次最忙的情况，或者“如果这个功能下周上线，你最担心它什么”。

有个很实用的追问模板：按操作对象、执行时机、异常条件三个维度展开。

• 操作对象：这是一条数据、一批数据，还是全量数据？比如导入功能，用户是一次传十行还是十万行？
• 执行时机：操作在白天高峰期执行，还是凌晨批量执行？如果是用户触发，允许等待多久？
• 异常条件：网络断了、第三方接口超时、服务器重启后，任务应该中断还是恢复？恢复后要不要去重？

很多时候用户不会直接说“我需要系统可用性达到99.9%”，但会说“上次月底统计的时候所有人都在等报表，领导催得急，我只能提前让同事别点其他页面”。这句话背后至少有两条NFR：报表查询在数据量高峰时应有一定性能上限；系统需要对高负载有保护机制，不能让某个重操作拖垮整个应用服务。

2.2 在历史文档里找“不变量”和“默认值”

项目资料里藏着大量隐含假设。比如接口文档里写的“超时时间默认30秒”，就是一个NFR；数据字典里“摘要字段长度限制200字”，本质上也在表达容量约束；部署文档里的“建议8核16G”，是性能与成本之间的取舍。

我见过一个内部系统，早期代码里到处是“假设只有内部几十人使用”的注释，后来业务扩张，同一个接口要对上千个外部商户开放，连接数和鉴权方式全都不匹配。这种事不是因为程序员水平不行，而是当初没人把“使用人数从几十变为上千”写进需求。发现这类NFR的办法是把文档中凡是带数字、上限、单位、超时、重试、默认值的地方标出来，再逐个问一句：这个数字从哪来的？现在还成立吗？

尤其要注意那些以“先这样写，以后再说”出现的默认值。技术债并不只来自潦草代码，更多来自没有写明的假设。“以后”不是没来，只是来的时候没人承认当时的默认值已经失效。

2.3 从客服工单和线上事故里反推

另一个信息源是工单库。用户反馈“页面打不开”“保存失败”“刷新一下就重复提交了两笔订单”，听起来都是个案，但把它们按时间、模块、操作路径聚在一起，往往能形成一张非功能需求画像：

• 大量“慢”的反馈，指向性能与用户体验阈值；
• 大量“超时退出”“会话失效”，指向并发与会话管理策略；
• 大量“重复扣款”“重复创建单据”，指向接口幂等性；
• 大量“换个浏览器样式错乱”，指向兼容性标准。

这类反馈比业务方口头描述的“要可靠”准确得多。它给出了可复现的操作场景，你只需把场景翻译成质量属性需求。如果项目还没上线，没有历史工单可查，那就去看竞品或同类开源系统的 issue 列表，看用户都在哪些非功能点上抱怨最多。

3. 用质量属性场景呈现发现结果，别再说“系统要流畅”

“系统要流畅”“希望体验快一点”这类话说了等于没说，因为不同人对“快”的理解完全不同。产品经理嘴里的快可能是页面转圈别超过一眨眼的功夫，开发手里的快可能是接口耗时小于200毫秒，测试眼里的快可能是500个并发下响应时间保持平稳。这三件事根本不是同一个规格。

想在不建模、不搞形式化方法的前提下把NFR表达清楚，质量属性场景是我最推荐的工具。

3.1 六个要素把模糊预期拆成验收前提

一个完整的质量属性场景包含六个要素：来源、刺激、环境、制品、响应、响应度量。听上去有点学术，其实翻译成大白话很简单：谁、在什么情况下、对系统的什么东西、做了一个动作，系统为此给出什么反应，这个反应怎么测。

以一个典型的搜索功能为例：

• 来源：普通业务用户。
• 刺激：在搜索框中输入关键词并回车。
• 环境：日常上班时段，系统处于正常负载状态。
• 制品：搜索结果页。
• 响应：页面在限定时间内展示结果；如果时间过长，则给出轻量提示而不是一直白屏。
• 响应度量：90%的请求在2秒内完成，95%的请求在4秒内完成；结果超过10万条时不全量加载，只展示前1000条并提示用户追加筛选条件。

看到了吗？原来“搜索要快”拆成六个要素后就变成了可以测试、可以写进验收标准的句子。真正做到这一点，测试就不再问开发“你觉得要多快”，而是直接看“2秒和4秒这两个值能不能接受”。

3.2 用效用树给 NFR 分优先级

当系统提出大量非功能需求时，不可能全部按最高标准实现。我的做法是画一棵简单的效用树，把最高层的质量属性（比如性能、可用性、安全）展开成具体属性，再为每个属性分配场景和优先级。优先级用两个维度看：一是对业务的影响，二是实现成本。

比如“数据备份恢复时间”属于可恢复性，它如果被判定为高影响高成本，就应该尽早拉上运维、开发、业务三方讨论备份策略：是全量每天备份，还是增量备份结合定期全量？恢复目标时间是4小时还是24小时？这些决定直接影响存储成本、中间件选型和工具链投入。不提前讨论，结果很可能是业务以为“随时能恢复”，运维实际只能恢复到昨天凌晨，中间的落差只能用事故来交学费。

效用树不要求画得多漂亮，关键是让所有人看到取舍。没人愿意为所有系统都争取“四个九”的可用性，那就别给每条NFR都套同一个标准。与其在评审会上泛泛说“我们要高可用”，不如直接挑出核心交易链路，只对这条链路定义明确目标，其他环节做到够用即可。

3.3 用负面场景逼出隐藏需求

正面场景回答“系统应该怎样”，负面场景回答“系统出了意外时应该怎么办”。我发现很多NFR是从负面场景里“逼”出来的。

你可以问业务方这样一组问题：如果同一个用户连续点了三遍“提交”按钮，能不能出现两条单据？如果下游接口在第5秒还没返回，系统是继续等、重试还是直接判失败？如果服务器在写入一半时宕机，恢复后数据会不会半新半旧？如果某个操作要跑1个小时，进度条卡到50%不动，用户关掉浏览器重开，任务还能不能接着跑？

这些不是开发故意刁难业务方，而是需求方需要做的风险声明。没想清楚就上线，最后承担后果的是真实用户。哪怕业务方给不出精确数字，只要他们能在几种方案里选一种（比如“宁可失败也不能重复”），系统就有了明确的NFR约束。

4. 四个实战里容易被漏掉的 NFR 类型复盘

理论说多了容易空，下面我复盘四个亲身经历过或者带团队时见过的场景。它们都不是什么冷门技术，但在常规需求评审里确实容易被漏掉。

4.1 并发登录挤爆账号锁定机制

一个后台管理系统最初只有几十个运营在用，登录功能加了账号密码错误5次锁定账户的规则。后来业务扩大到给外包人员开通账号，某天上午几百人同时登录，连续输错密码的比例略高，结果一部分真实用户被误锁，甚至有人因为密码重置接口也依赖登录会话而无法自助解锁。

背后的NFR是：登录接口要有并发承载预期，且安全策略与用户自助恢复流程要配套。发现这类问题，需要在设计登录时问清楚几个边界：系统最多支持多少并发请求？密码重试锁定是按用户维度还是按IP维度？锁定后有没有独立的解锁通道？安全是NFR里最容易被“功能正确”掩盖的部分，因为只要账号能登进去，功能演示就不会出问题，但安全约束一旦和易用性冲突，必须靠明确的策略去平衡。

4.2 报表导出的数据量从一千涨到十万

报表功能在测试环境造的数据量很小，导出一千行顺风顺水。上线三个月后业务方开始导月度明细，一次性导出五万到十万行，结果前端卡死，后端频繁超时，数据库连接池也被长期占住。查下来发现导出逻辑是把所有数据一次性查出来拼成 Excel 再返回，这套实现方式在千行规模下没问题，但没设计大数据量导出的边界。

这里的NFR可以拆成两类：一是单次导出数据量的上限，二是超出上限时的降级策略。正确的处理通常包括异步生成文件、分批查询、限制最大导出行数、完成后通过通知中心给用户下发下载链接。发现这类NFR最简单的时机，是数据建模或接口设计阶段就问一句：“这个操作最多可能处理多少数据？如果数据量达到当前的十倍，这个方案还成立吗？”

4.3 多语言和文本长度引发的界面崩坏

“支持中英文切换”听起来是个功能需求，但很多项目直到开测才发现英文单词比中文长很多，或者某种语言环境下日期格式会让日历组件报错。真正的问题是国际化约束没有被当成NFR。

一个稍微严谨的做法是在需求阶段明确支持哪些语言，并规定每类文本的扩展空间。比如中文按钮显示“确认”，英文菜单显示“Confirm”，但如果你还计划支持德语，就得给UI预留至少30%到50%的文字扩展空间。还有字符编码、时区、货币格式、排序规则、字符串截断规则，都需要独立列出约束。这类需求不会出现在用户故事的正常路径里，但会出现在本地化测试的每一条用例里。

4.4 凌晨定时任务失败后无人接手

很多业务依赖定时任务：对账、结算、数据同步、报表生成。功能正常时大家看不见它，一旦任务凌晨三点跑挂，数据没同步，影响第二天早上所有人的操作。

我复盘过好几次这类事故，根因几乎都不是任务本身的逻辑问题，而是缺少明确的运行期NFR：任务允许的执行窗口是什么、失败后要不要自动重试、重试间隔和最大次数是多少、超过最大次数有没有告警通道、任务是否具备幂等性可不可以安全重跑。如果这些没定义，开发只能凭感觉写一个 try-catch 把错误记进日志，然后祈祷第二天有人看日志。可靠的系统宁可把任务标记为“失败待处理”，也要把状态暴露出来，而不是让数据静默出错。

5. 逼出 NFR 的分类检查表：按类别过一遍，不容易漏项

想靠脑子把NFR全都记住不现实。我在做需求评审和启动会前，会按类别把问题快速过一遍，就像登机前检查行李，不需要每个问题都深挖，但必须确认哪些与你当前项目有关。

5.1 性能与容量

性能类NFR要问清楚的点包括：目标用户总量、同时在线用户数、核心接口每秒请求数、单次操作允许的响应时间、常见数据量级和极端数据量级、批处理任务的执行窗口、系统可承受的峰值流量。

需要特别区分平均值和分位数/长尾。很多系统平均响应时间很好，但存在少量请求慢到让用户放弃。所以尽量用P95或P99来描述，而不是一句“平均100毫秒”给自己定个过高的标准。

5.2 可用性、恢复与容错

这里关注点不是“正常情况下能不能工作”，而是“异常情况下会不会丢”。要问的问题包括：核心链路允许停机多久、数据库故障后多久能恢复、有没有跨机房的冗余、数据备份频率是多少、恢复时间目标是多少、依赖的第三方服务不可用时系统如何降级。

在设定可用性目标时建议先算一笔账：99% 的可用性意味着每年有约3.65天的不可用时间，99.9% 则意味着每年约8.76小时。对大多数业务来说，盲目追求99.99%会让成本成倍抬高，非但没有必要，还会拖慢项目节奏。发现NFR不是把指标定得越高越好，而是定在“业务可接受、成本可承受”的区间。

5.3 安全、权限与隐私

先别一提到安全就想到防火墙和渗透测试，需求阶段的安全NFR更多是规则层面的。用户分为哪些角色，每个角色能看哪些数据、能执行哪些操作；敏感字段在页面和日志里要不要脱敏；登录有几次重试限制，密码策略是什么；关键操作是否需要审批或审计记录；数据保存多久后要清理。

这类问题最好直接对着角色权限矩阵讨论，否则容易出现“所有管理员都能导全部数据”这种默认实现。安全NFR看起来不产生业务价值，但它决定系统是否能经得起真实环境的考验。

5.4 易用性、兼容性与无障碍

不要以为易用性只是想不想交的问题。判断易用性同样需要可测量的指标，比如新用户完成一个核心任务的时长、操作步骤数、错误提示的可理解程度。兼容性则需要明确浏览器版本、操作系统版本、客户端类型。如果做一个面向公众的小程序或H5页面，还要考虑弱网下的降级体验、不同屏幕尺寸的适配。

无障碍经常被忽略，但它是最典型的非功能需求：键盘能不能操作、读屏软件能不能读出按钮含义、颜色对比度够不够、图片有没有替代文本。把它放进验收清单，通常能顺带提升代码语义和结构化程度，对所有人都有用。

5.5 可观测性、可运维性与数据生命周期

可运维性是我近几年觉得最该提前说清的一类NFR。日志保留多久、打印到什么级别、核心接口有没有链路追踪、告警规则是否覆盖关键失败、配置修改是不是需要走变更流程、扩容一台实例需要多长时间。系统“能跑”只是起点，“出了问题能否快速找到原因”才是线上真实体验。

数据生命周期也很容易被漏。业务数据要保留一年还是三年？回收站里的数据要不要彻底删除？日志中的个人信息需不需要匿名化？这些没有在产品阶段定义清楚，最后往往由开发临时拍板，后面运营要恢复某段时间的数据时才追悔莫及。

6. 把每条 NFR 写成可测试的验收指标，而不是一句口号

发现NFR只完成了一半，另一半是把它转换成开发、测试和运维都能执行的语言。这一章给出几个我常用的落地方法。

6.1 指标口径要具体：平均值不如分位数，最好给出百分比例

如果有人和你说“响应时间要小于3秒”，先别急着写成“平均响应时间小于3秒”，因为平均值的欺骗性太大。假设100个请求里有99个耗时100毫秒，只有1个耗时291秒，平均值也会被拉到一个吓人的数。更符合真实体验的方式是以分位数表示：P95小于2秒、P99小于5秒，并限定取样时间为一个自然日的业务高峰时段。

类似地，可用性指标不要只说“高可用”，要给出一段可观察的周期：在一个自然月内，核心写接口的可用时间应达到99.9%，不把计划内维护和不可抗力算入。这样测试和运维才有共同语言。

6.2 负载模型要给场景，不要只给一个数字

性能NFR光是写“支持1000并发”不够，因为1000个用户同时登录和1000个用户同时浏览列表页对系统的压力完全不同。我一般会要求把负载模型写成场景：同时在线用户数、阅读型访问占比、写入型访问占比、平均每个会话产生多少次请求、峰值倍数是多少。

举例：某个查询接口的性能验收标准可以写成“在1000个模拟用户同时在线、每人每分钟触发5次列表查询的负载下，P95响应时间不超过2秒；在发布和业务结算日的2倍峰值流量下，系统不会触发全局降级，只允许局部接口变慢至P95不超过4秒”。这个描述看起来长，但它把“什么时候测、测到多少、什么程度算过”全部锁死了。

6.3 一个完整 NFR 验收条目的写法

我习惯用下面的模板来写条目，各团队可以按自己风格调整：

• 编号：NFR-PERF-001
• 关联功能：订单列表查询
• 场景：用户进行列表页翻页操作，关注按订单时间倒序的前100条订单。
• 环境要求：压测环境使用4核8G单机部署，数据库制造10万条订单且包含最近一年的数据。
• 响应要求：P95 < 2秒，P99 < 4秒；错误率不超过0.1%。
• 验证方法：用压测工具按每秒钟30个用户的速率加压，持续15分钟，统计响应时间分布和错误情况。

测试会喜欢这样的条目，因为可以直接执行；开发也会喜欢，因为不会再出现“测试觉得慢、开发觉得没问题”的口水仗。如果某条NFR连验证方法都写不出来，那说明它还没被发现清楚，需要回头继续拆。

6.4 推到排期里，NFR 才不是理想主义

即使写清楚了，如果NFR没有进入排期，它就仍然是口号。我推动这件事的方法很简单：在迭代计划会议上给NFR也开一个“用户故事”或者“技术任务”卡片，标注它的业务价值是什么、关联风险是什么、预期验证方式是什么。例如“将登录接口的并发上限压到500并设置网关层限流”可以写成一张独立的卡片，和功能需求一起接受估算。

如果老板觉得NFR耗时太多，你可以换一种语言去谈：这一项工作不是为了“性能更好”，而是为了“避免月底报表把数据库拖挂，导致领导看不到数据”。把不可见的NFR翻译成业务方在意的结果，他们就会愿意为之排时间。

7. 把“发现NFR”变成一个团队习惯，而不是一次流程审计

到这里你会发现，发现非功能需求的方法论并不复杂，难的是让每个项目成员都养成条件反射式的追问习惯。我做过的比较有效的小动作有三个。

第一个动作是在需求评审表里始终放一栏“非功能验收条件”，没有填或没有验证方式的需求不能进入开发。哪怕项目节奏紧张，哪怕这一栏只是简单写“支持20人同时使用、浏览器只考虑Chrome最新版”，也比空白好。

第二个动作是让开发、测试、运维在需求阶段就参与“事故预演”。不是真正故障演练，而是带着一张白纸坐到一起，一个模块一个模块地问：这个功能上线后最容易出什么问题？如果半夜告警电话响了，你最先看什么指标？运维说想看到什么日志，开发现场决定打不打印。这个对抗式提问很容易把隐性问题暴露出来。

第三个动作是定期复盘线上故障时，给每条根因补一条NFR。故障解决后不要关闭就完事，而是追问：是功能实现错了吗？还是当初根本就没有对应的性能指标、可用性指标或幂等需求？如果是后者，那就新增一条NFR到下一轮迭代里。这样积累一两年后，团队的NFR库会越来越贴合真实的业务场景，每次新项目也能从中挑出适用的条目。

我个人实际带项目的体会是，成功“发现非功能需求”的标志不是文档里多了一章漂亮的非功能需求列表，而是当你问业务方“系统能接受的最长恢复时间是多少”时，不再是一屋子人面面相觑，而是有人能明确告诉你“核心数据最多容忍半小时，其他要求没有”。这比什么模板都值钱。新项目启动时，也不要一下把所有NFR都塞进一期，你只需要先锁定影响核心业务流程的那三条，把它们的验证方法定下来，再逐版本补全，习惯一旦形成了，后面的事情会自然顺起来。