专业的短链接生成工具
链接域名
短网址有效期
常见的非功能性需求和应对方式
更新时间：2025-6-1 11:29:51 作者：爱短链
非功能性需求是指隐藏在功能需求背后，开发需要考虑的需求，又称跨功能需求。
在过去的几年里，最常见的场景是 QA 小伙伴满办公室追开发报告 bug，有时候开发会不开心，当时没说 XXX，要做 XXX。
” 好像 QA 即使单元测试覆盖率达到，小伙伴也总是比开发多一点心眼。
80%，QA 或者改变方法可以发现问题。
很大一部分原因来自需求背后的需求，BA、QA 小伙伴认为你考虑过，或者默认开发需要考虑过。
比如 CMS 系统中对新文章的需求不太可能写出需要防止表格二次提交的东西 AC（Acceptance Criteria，但是，如果没有人提出，谁会知道呢？ (最近流行的冰山图) 最终 QA 或者在线用户会通过报告 bug 告诉我们。
我们在功能需求背后隐藏这些东西 BA 默认情况下，开发需要考虑的需求被称为非功能需求，有时也被称为跨功能需求。
以下是工作中常见的非功能需求和应对方式。
一、互动体验相关 Loading 加载状态是最容易被忽视的需求之一，特别是在当前丰富的客户端开发模式下，数据访问是异步加载。
如果你忘记考虑这个需求，当网络条件更好时，它会闪烁，而在网络条件差的情况下，它似乎会卡住，没有响应。
实现统一的 Loading 拦截器可以添加到前端的网络请求库中，但需要注意多次网络请求中间使用计数器 Loading 图标不会中断，否则会出现闪烁问题。
1. 二次提交表格 有一些 QA 将使用极端的测试方法，如多次快速点击按钮，如果页面不处理，将触发多次提交表单的问题。
即使是后端 API 成功和失败的提示可能示成功和失败，这会让用户感到更加困惑。
有几种方法可以解决这个问题： 使用蒙层的 Loading 阻塞用户操作的效果会自带 点击禁止表单事件或在程序中添加请求状态 依靠后端配置一次性表单令牌(通常用于防止 CRSF） 2. 输出格式化 需求通常会告诉开发如何显示数据，但往往会忘记如何格式化数据。
例如，我们希望数字使用千分位分离或其他显示方法，使数字阅读不那么困难；字符串溢出处理截取方法；时间格式化方法，部分项目将使用一小时前、一天前或具体日期等更人性化的显示方法；如果封面图需要非拉伸截取面图需要非拉伸截取等。
3. 请求用户确认和提示 这两项专业 BA 一般会考虑通知 UX 设计相应的风格。
但细节值得讨论。
如果在一系列操作中提示用户确认，则需要明确用户点击取消后应返回用户的操作状态。
APP 用户编辑数据后，点击提交系统提示是否继续。
如果用户点击取消，页面上的数据将被删除。
开发需要和 BA 确认具体的互动和提示文案。
除了文案，还有成功和错误的提示 BA 需要确认的是：是独立的提示页面还是返回到源页面？提示需要自动关闭还是等待页面刷新？用户能主动点击关闭吗？ 互动体验的另一个坏消息是保持统一！！！我认为这是互动体验中最致命的，不会写在需求中，但 QA 通常可以从中找到 bug。
二、安全相关 1. 身份验证和权限 URL 可以列举和要求的资源不验证用户权限，这是一个致命而低级的安全问题。
BA 默认情况下，开发需要这样做。
但现实是，在一些遗留项目中有太多的例子，比如修改 URL 上的资源 ID 甚至 userID 然后修改其他用户的数据。
几年前，我们可以发现很多这样的漏洞，甚至在我还是学生的时候，我们用电信运营商的权限漏洞赢得了很多付费游戏。
如果系统设计了权限管理模块，则在打开新功能时也应与之和解 BA 确认是否纳入权限管理。
2. 表单验证 如何验证用户输入的数据也经常被遗忘在需求中，这部分 QA特别容易给出 Bug，数据验证充满了大量的条件边界。
还有一个老生常谈的问题，服务器端还是前端应该做表单验证？ 显然，为了安全，后端必须做，前端选择体验。
3. SQL 注入和 XSS 攻击 SQL 在过去的两年里，。
ORM 框架几乎没有普遍使用，但是 XSS 还有很多。
处理 SQL 注入和 XSS 攻击的共同点是不相信任何用户的输入或来源。
用户在浏览器中输入的不仅仅是表单 URL，而往往 URL 数据验证很容易忽略输入参数。
4. 文件上传 上传文件背后的需求有上传文件的类型和尺寸限制；需要和 BA 确认是否可以批量上传，上传前是否需要预览；上传后如何命名，上传过程中是否需要压缩图片或视频。
这里的安全要求是不要上传可执行文件；需要获取文件的真实类型信息，而不是后缀名。
文件上传的陷阱之一是使用客户端来源的文件名作为文件存储的文件名，这是非常不可靠的。
上传后的文件系统需要使用内部建设的唯一命名，并通过数据库记录用户上传的文件名。
三、性能相关 1. 响应时间 说实话，我从来没有在那张卡上看到过明确的指标，这些功能需要多长时间才能完成响应。
但是，如果不在业务需求分析阶段提出，响应时间过长肯定不会通过 QA 测试。
需求分析阶段的响应时间包括三个注意事项： 系统性能设计要求。
对于一般需求，技术上应达到基本的性能指标。
当然，实现的方法是不同的，比如优化 SQL、优化静态资源等。
该功能是否适合同步操作。
然而，有些需求根本不适合同步操作。
例如，服务器应接受用户的请求，然后不断返回任务处理状态，而不是让用户端等待完成。
一些信息系统可以用于实现，例如 JMS 等。
第三方系统集成。
如果与第三方系统集成，则需要与资源提供商沟通是否需要增加批量数据操作，以避免数据循环获取。
JSON API提供了标准 include 该方法将多个资源聚集到一个请求中。
此外，调用人可以注意使用一些非阻塞的网络请求方法，如 RxJava 或AsyncRestTemplate。
2. 实时消息通知 当我们做一些类似于站内信件和系统信息的功能时，有时 BA、QA 信息的状态和数量(小红点)应实时显示在页面上，并及时更新。
但是开发伙伴可能认为开发伙伴可能认为 web 用户刷新后可以看到一些信息，很容易达成不一致的理解。
如果真的需要实时刷新，需要做一些技术调整，比如轮询，HTTP 长连接、websock 只有这样才能实现，这将带来额外的工作量。
3. 游离数据管理 从事服务器开发的合作伙伴可能有这样的经验。
一旦创建了一些数据，用户或管理员就找不到或跟踪它们。
有两个明显的例子： 在新资源办公室，异步上传图片或其他资源。
例如，当用户操作新的文章页面时，文章表可能没有写入数据，但用户需要上传一些封面或其他图片。
如果用户完成了整个操作，图片将与文章相关，但如果用户放弃操作，图片将成为自由状态，无法继续管理，导致大量垃圾数据占用系统资源。
删除操作，不删除一些相关数据。
例如，如果删除操作不是事务性的，则会浪费数据空间，并可能影响后续的统计功能。
上传新资源图片，可以和 BA 通信使用草稿在用户进入创建页面完成数据插入操作，或设计图片空间提醒用户使用上传图片；对于删除操作，系统可以设计为数据库表标记删除，而不是真正删除，或设计回收站功能移动到备份表。
4. 延迟分布式系统 由于稍大的系统采用分布式或微服务设计，系统之间存在同步延迟，如数据库主同步、静态资源服务器同步等。
在一些对文案有严格要求的项目中，隐藏的需求之一是提醒当前信息可能会延迟，请稍后再试一次。
或者在前端添加定期刷新页面或资源返回策略。
在我经历的一个项目中，上传图片成功返回图片 URL 之后，前端可能会延迟 2s 从正常情况下左右打开图片，需要增加 onload、onerror 重试或后续操作。
四、其他非功能需求 1. 兼容性 浏览器兼容性是前端开发中头疼的问题，从 IE6 到微信 webview，无论技术发展到哪个时代，它都无法逃脱。
所以这些事情是需要的BA确认的呢？ 与其讨论搜狗和360，不如讨论各种浏览器内核的具体型号 如果是这种壳浏览器。
APP 内部的webview，这就需要收集相关的安卓或安卓 IOS 的版本号。
是否允许一定程度的降级策略？例如，在旧的安卓手机中，有大量的安卓手机 CSS3 不支持特征可能会导致动画故障。
我们能不能在旧手机上要求过渡动画吗？ 2. 升级策略 如果前端有兼容性问题，服务器端会消失吗？ 不幸的是，如果 APP 如果不同步发布，API 修改需要照顾老客户端。
即使是同步发布的 APP 很难强制用户升级。
在服务器端开发中保持一定的兼容性，更重要的是需求和 BA 设计合理的升级方案。
我的经验是设计API 时，需要在URI在路径中预留版本号，如 V1/your-api/{id}。
同时，还需要增加合同测试，以确保API 修改不会破坏原始逻辑。
3. 本地化和国际化 这在一些国际项目中尤为重要，但有时很容易被忽视。
项目开始时需要多语言和时区问题 BA 确认，统一增加国际化计划。
其他本地化需要注意日期、货币、单位、标点符号等各种功能的输出。
4. 用户行为分析埋点 越来越多的项目开始使用用户的行为分析工具，例如 Google 的 Gtag 而且更专业 dynatrace，使用这些工具会对系统造成一定的侵入，需要埋点用户的操作。
如果项目有类似的需求，许多用户行为分析系统会根据特定功能提前定义一些标签，因此在开始新功能时需要确认用户行为分析的一些规则。
五、最后 写这篇文章的目的是分享在工作中开发一张卡片背后需要考虑的注意事项。
你想的细节越多，业务逻辑就越完整，开发工作就越顺利。
在参加公司的培训时，碰巧有很好的非功能需求课程，非常详细，所以有几页，但不幸的是，没有非常详细的解释和处理方法。
所以我决定根据我在工作中遇到的场景与你分享。
敏捷团队的一个痛点是，我们很少有一个大而完整的需求文档。
如果有一些需求在开卡时没有想到或没有想到 AC 如果反映出来，需要反复寻找。
BA、UX 反复确认。
开发和 BA 沟通调整需求，交互时可能忘记知识 QA 或者 UX，或者故事卡内容没有更新，会造成沟通麻烦。
来源：https://mp.weixin.qq.com/s/jOJDd8Nn69DYeC_dpKpnVw 作者:林宁；微信官方账号: ThoughtWorks洞见 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
在过去的几年里，最常见的场景是 QA 小伙伴满办公室追开发报告 bug，有时候开发会不开心，当时没说 XXX，要做 XXX。
” 好像 QA 即使单元测试覆盖率达到，小伙伴也总是比开发多一点心眼。
80%，QA 或者改变方法可以发现问题。
很大一部分原因来自需求背后的需求，BA、QA 小伙伴认为你考虑过，或者默认开发需要考虑过。
比如 CMS 系统中对新文章的需求不太可能写出需要防止表格二次提交的东西 AC（Acceptance Criteria，但是，如果没有人提出，谁会知道呢？ (最近流行的冰山图) 最终 QA 或者在线用户会通过报告 bug 告诉我们。
我们在功能需求背后隐藏这些东西 BA 默认情况下，开发需要考虑的需求被称为非功能需求，有时也被称为跨功能需求。
以下是工作中常见的非功能需求和应对方式。
一、互动体验相关 Loading 加载状态是最容易被忽视的需求之一，特别是在当前丰富的客户端开发模式下，数据访问是异步加载。
如果你忘记考虑这个需求，当网络条件更好时，它会闪烁，而在网络条件差的情况下，它似乎会卡住，没有响应。
实现统一的 Loading 拦截器可以添加到前端的网络请求库中，但需要注意多次网络请求中间使用计数器 Loading 图标不会中断，否则会出现闪烁问题。
1. 二次提交表格 有一些 QA 将使用极端的测试方法，如多次快速点击按钮，如果页面不处理，将触发多次提交表单的问题。
即使是后端 API 成功和失败的提示可能示成功和失败，这会让用户感到更加困惑。
有几种方法可以解决这个问题： 使用蒙层的 Loading 阻塞用户操作的效果会自带 点击禁止表单事件或在程序中添加请求状态 依靠后端配置一次性表单令牌(通常用于防止 CRSF） 2. 输出格式化 需求通常会告诉开发如何显示数据，但往往会忘记如何格式化数据。
例如，我们希望数字使用千分位分离或其他显示方法，使数字阅读不那么困难；字符串溢出处理截取方法；时间格式化方法，部分项目将使用一小时前、一天前或具体日期等更人性化的显示方法；如果封面图需要非拉伸截取面图需要非拉伸截取等。
3. 请求用户确认和提示 这两项专业 BA 一般会考虑通知 UX 设计相应的风格。
但细节值得讨论。
如果在一系列操作中提示用户确认，则需要明确用户点击取消后应返回用户的操作状态。
APP 用户编辑数据后，点击提交系统提示是否继续。
如果用户点击取消，页面上的数据将被删除。
开发需要和 BA 确认具体的互动和提示文案。
除了文案，还有成功和错误的提示 BA 需要确认的是：是独立的提示页面还是返回到源页面？提示需要自动关闭还是等待页面刷新？用户能主动点击关闭吗？ 互动体验的另一个坏消息是保持统一！！！我认为这是互动体验中最致命的，不会写在需求中，但 QA 通常可以从中找到 bug。
二、安全相关 1. 身份验证和权限 URL 可以列举和要求的资源不验证用户权限，这是一个致命而低级的安全问题。
BA 默认情况下，开发需要这样做。
但现实是，在一些遗留项目中有太多的例子，比如修改 URL 上的资源 ID 甚至 userID 然后修改其他用户的数据。
几年前，我们可以发现很多这样的漏洞，甚至在我还是学生的时候，我们用电信运营商的权限漏洞赢得了很多付费游戏。
如果系统设计了权限管理模块，则在打开新功能时也应与之和解 BA 确认是否纳入权限管理。
2. 表单验证 如何验证用户输入的数据也经常被遗忘在需求中，这部分 QA特别容易给出 Bug，数据验证充满了大量的条件边界。
还有一个老生常谈的问题，服务器端还是前端应该做表单验证？ 显然，为了安全，后端必须做，前端选择体验。
3. SQL 注入和 XSS 攻击 SQL 在过去的两年里，。
ORM 框架几乎没有普遍使用，但是 XSS 还有很多。
处理 SQL 注入和 XSS 攻击的共同点是不相信任何用户的输入或来源。
用户在浏览器中输入的不仅仅是表单 URL，而往往 URL 数据验证很容易忽略输入参数。
4. 文件上传 上传文件背后的需求有上传文件的类型和尺寸限制；需要和 BA 确认是否可以批量上传，上传前是否需要预览；上传后如何命名，上传过程中是否需要压缩图片或视频。
这里的安全要求是不要上传可执行文件；需要获取文件的真实类型信息，而不是后缀名。
文件上传的陷阱之一是使用客户端来源的文件名作为文件存储的文件名，这是非常不可靠的。
上传后的文件系统需要使用内部建设的唯一命名，并通过数据库记录用户上传的文件名。
三、性能相关 1. 响应时间 说实话，我从来没有在那张卡上看到过明确的指标，这些功能需要多长时间才能完成响应。
但是，如果不在业务需求分析阶段提出，响应时间过长肯定不会通过 QA 测试。
需求分析阶段的响应时间包括三个注意事项： 系统性能设计要求。
对于一般需求，技术上应达到基本的性能指标。
当然，实现的方法是不同的，比如优化 SQL、优化静态资源等。
该功能是否适合同步操作。
然而，有些需求根本不适合同步操作。
例如，服务器应接受用户的请求，然后不断返回任务处理状态，而不是让用户端等待完成。
一些信息系统可以用于实现，例如 JMS 等。
第三方系统集成。
如果与第三方系统集成，则需要与资源提供商沟通是否需要增加批量数据操作，以避免数据循环获取。
JSON API提供了标准 include 该方法将多个资源聚集到一个请求中。
此外，调用人可以注意使用一些非阻塞的网络请求方法，如 RxJava 或AsyncRestTemplate。
2. 实时消息通知 当我们做一些类似于站内信件和系统信息的功能时，有时 BA、QA 信息的状态和数量(小红点)应实时显示在页面上，并及时更新。
但是开发伙伴可能认为开发伙伴可能认为 web 用户刷新后可以看到一些信息，很容易达成不一致的理解。
如果真的需要实时刷新，需要做一些技术调整，比如轮询，HTTP 长连接、websock 只有这样才能实现，这将带来额外的工作量。
3. 游离数据管理 从事服务器开发的合作伙伴可能有这样的经验。
一旦创建了一些数据，用户或管理员就找不到或跟踪它们。
有两个明显的例子： 在新资源办公室，异步上传图片或其他资源。
例如，当用户操作新的文章页面时，文章表可能没有写入数据，但用户需要上传一些封面或其他图片。
如果用户完成了整个操作，图片将与文章相关，但如果用户放弃操作，图片将成为自由状态，无法继续管理，导致大量垃圾数据占用系统资源。
删除操作，不删除一些相关数据。
例如，如果删除操作不是事务性的，则会浪费数据空间，并可能影响后续的统计功能。
上传新资源图片，可以和 BA 通信使用草稿在用户进入创建页面完成数据插入操作，或设计图片空间提醒用户使用上传图片；对于删除操作，系统可以设计为数据库表标记删除，而不是真正删除，或设计回收站功能移动到备份表。
4. 延迟分布式系统 由于稍大的系统采用分布式或微服务设计，系统之间存在同步延迟，如数据库主同步、静态资源服务器同步等。
在一些对文案有严格要求的项目中，隐藏的需求之一是提醒当前信息可能会延迟，请稍后再试一次。
或者在前端添加定期刷新页面或资源返回策略。
在我经历的一个项目中，上传图片成功返回图片 URL 之后，前端可能会延迟 2s 从正常情况下左右打开图片，需要增加 onload、onerror 重试或后续操作。
四、其他非功能需求 1. 兼容性 浏览器兼容性是前端开发中头疼的问题，从 IE6 到微信 webview，无论技术发展到哪个时代，它都无法逃脱。
所以这些事情是需要的BA确认的呢？ 与其讨论搜狗和360，不如讨论各种浏览器内核的具体型号 如果是这种壳浏览器。
APP 内部的webview，这就需要收集相关的安卓或安卓 IOS 的版本号。
是否允许一定程度的降级策略？例如，在旧的安卓手机中，有大量的安卓手机 CSS3 不支持特征可能会导致动画故障。
我们能不能在旧手机上要求过渡动画吗？ 2. 升级策略 如果前端有兼容性问题，服务器端会消失吗？ 不幸的是，如果 APP 如果不同步发布，API 修改需要照顾老客户端。
即使是同步发布的 APP 很难强制用户升级。
在服务器端开发中保持一定的兼容性，更重要的是需求和 BA 设计合理的升级方案。
我的经验是设计API 时，需要在URI在路径中预留版本号，如 V1/your-api/{id}。
同时，还需要增加合同测试，以确保API 修改不会破坏原始逻辑。
3. 本地化和国际化 这在一些国际项目中尤为重要，但有时很容易被忽视。
项目开始时需要多语言和时区问题 BA 确认，统一增加国际化计划。
其他本地化需要注意日期、货币、单位、标点符号等各种功能的输出。
4. 用户行为分析埋点 越来越多的项目开始使用用户的行为分析工具，例如 Google 的 Gtag 而且更专业 dynatrace，使用这些工具会对系统造成一定的侵入，需要埋点用户的操作。
如果项目有类似的需求，许多用户行为分析系统会根据特定功能提前定义一些标签，因此在开始新功能时需要确认用户行为分析的一些规则。
五、最后 写这篇文章的目的是分享在工作中开发一张卡片背后需要考虑的注意事项。
你想的细节越多，业务逻辑就越完整，开发工作就越顺利。
在参加公司的培训时，碰巧有很好的非功能需求课程，非常详细，所以有几页，但不幸的是，没有非常详细的解释和处理方法。
所以我决定根据我在工作中遇到的场景与你分享。
敏捷团队的一个痛点是，我们很少有一个大而完整的需求文档。
如果有一些需求在开卡时没有想到或没有想到 AC 如果反映出来，需要反复寻找。
BA、UX 反复确认。
开发和 BA 沟通调整需求，交互时可能忘记知识 QA 或者 UX，或者故事卡内容没有更新，会造成沟通麻烦。
来源：https://mp.weixin.qq.com/s/jOJDd8Nn69DYeC_dpKpnVw 作者:林宁；微信官方账号: ThoughtWorks洞见 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
