我们在选购新车时，会预设一些选购的标准，比如GPS导航必须能够保存目的地，或者必须要买黑色的车。我们可能下意识以为这些是功能性需求，但实际上这些特性都是与用户体验相关的非功能性需求。
一、什么是非功能性需求(NFR)?
非功能性需求是对软件系统的全局性约束，包括但不限于开发成本、运营成本、性能、可靠性、可维护性、可移植性和扩展性等。一个与功能无关，但与可靠性、效率、可用性、可维护性和可移植性等属性相关的需求。
在系统工程和需求工程中，非功能性需求是一个指定可以用来判断系统操作的标准，而不是特定行为的需求。
在描述非功能性需求时常会用到一些副词或修饰语，如“系统应能快速打印发票”，或“系统应在确保信息安全的情况下打印出发票”。
软件的非功能性需求关乎用户体验。忽视这些需求可能会导致项目延期，预算超支，用户满意度降低，也可能会导致项目目标不明确，进而导致产品偏离用户的期望。
非功能性需求弥补了开发者认为客户想要的和客户真正想要的之间的差距。
研究显示，软件开发成本中的60%到80%用于修复产品存在的问题，完善的非功能性需求可以消除约50%到80%的产品缺陷。
既然我们已经知道了非功能性需求的重要性，那么问题来了：如何有效地将非功能性需求融入到产品开发过程中呢？
二、非功能性需求关注产品的”性能”
产品的”性能”包括质量、可靠性、可制造性、可用性、可服务性、可升级性等。
非功能性需求关注用户体验，定义了系统的质量、约束条件或外部接口等方面的要求。如果我们想设计出一个具有可扩展性的系统，仅凭口头描述往往不够清楚，需要将目标具体化，比如：“构建出一个在未来24个月内能够管理至少50,000名用户的系统，以防止系统崩溃对用户造成困扰”。
另外，非功能性需求还可能涵盖以下方面：
- 法律法规或相关规定。
- 定义软件的质量属性。
- 确保关键领域的性能表现，例如可靠性、可用性和可扩展性。
- 提升用户体验，使系统更易于操作，并最大程度地减少返工。
就像购车一样，不同的人获得最佳用户体验所要求的产品特性不同。你可能需要加热座椅，而其他人则可能想要三排座椅。所以，你为项目定义的非功能性需求会根据客户期望而变化。然而，一个可能的非功能性需求类别列表可以作为你的起始点，帮助你思考在你的需求列表中应该包含哪些非功能性需求。
三、非功能性需求的不同类别?
把非功能性需求想象成一种容器，里面装载的是与用户体验密切相关的重要属性。要记住，非功能性需求并不是关于产品将要完成什么任务（那是功能性需求的范畴），而是关于这个项目将要达到的目标或理想状态。
如果你选择了正确的容器并且衡量了正确的事物，那么你就可以放心，你交付的产品会满足客户的期望——因为你已经明确地定义了这些期望。每个人都在同一认知水平上，这在你集中管理你的需求时，会进一步增强。
接下来，让我们看看一些常见的非功能性需求类别：
- 性能和可扩展性：确定所需的响应时间、性能标准和其他与性能相关的属性。系统生成结果的速度有多快？系统在高负荷下的性能如何？
- 操作限制：这部分涉及产品开发过程中必须遵守的特定软件需求、系统需求，以及运行时候的约束。
- 平台限约束：大多数软件都会有平台限制，需提前明确这些限制。
- 可修改性：需要考虑修改软件所需的工作量。提前预知修改带来的工作量，可以帮助客户更有效地规划项目时间。
- 可移植性需求和能力：思考软件在不同平台运行的难易程度，以及适用的硬件和操作系统，还需要考虑软件是否会与其他程序产生冲突。
- 可靠性：需要考虑软件发生错误的频率和后果，以及检测错误和修复错误的手段。
- 安全性：关乎系统保护和数据保护的需求，例如破解系统的难易程度以及如何降低这些风险。
- 可用性：指用户体验，例如学习和操作系统的难度，实际使用软件可能出现的问题或者困难。
- 合法性：涉及到的法律问题，例如数据隐私和知识产权。
不同项目的需求会有所不同，常见的需求类别包括: 系统的可用性（系统是否易于使用）、容量（系统能处理多少任务或用户）、可靠性（系统的稳定性或故障率）和安全性（系统防止非法访问或攻击的能力）。可先从这些基本的需求类别着手，逐渐扩展到其他需求领域，最终构建出属于自己的新产品开发项目需求模板。
四、功能性需求和非功能性需求的区别？
功能性需求和非功能性需求都是软件开发的重要组成部分，关注点不同：
- 功能性需求（Functional Requirements）： 这些需求关注软件应执行的具体功能或行为。例如，一个电子商务网站的功能性需求可能包括用户能够浏览产品目录、添加商品到购物车、进行购物结算等。功能性需求通常以用户故事、用例或系统功能列表的形式进行文档化，这些需求是用户或系统需要完成的具体任务。
- 非功能性需求（Non-Functional Requirements）： 这些需求关注系统的质量、性能或约束。它们描述了系统应如何工作，而不是系统应该做什么。例如，一个电子商务网站的非功能性需求可能包括系统必须能够处理高并发访问（性能需求）、必须有良好的用户界面（可用性需求），或必须遵循某些数据安全标准（安全需求）。非功能性需求有时也被称为系统属性、质量属性或系统约束。
两者都是必不可少的，功能性需求解释了系统应该执行的任务，而非功能性需求解释了完成这些任务的方式、限制和其他期望。
五、什么是非功能性需求文档？
非功能性需求文档是软件需求规格说明（SRS文档）的关键组成部分。SRS描述了软件应具备的性能、约束特性及其实现方式，定义了用户对产品的性能、可靠性、安全性等方面的需求。
一份标准的SRS通常会包含以下部分：
序言：对系统进行简要概览，提供相关的背景信息，对需要提前定义的术语进行阐释。 总体描述：阐述项目的全局目标、商业价值及项目愿景。 详细需求：这部分明确规定了系统所需的特定属性、功能要求，以及与之相关的数据库需求等。
六、追踪和管理非功能性需求的模版
在整个软件和硬件开发生命周期中，团队需要共同参与定义功能性和非功能性需求。如果使用的工具各不相同，就会影响团队协作。统一化的需求管理方式能够提高效率，增强协作能力，确保团队开发出高质量、合规的产品。
使用统一需求管理方案的好处：
- 单一的真实数据源：团队成员能够共享相同的信息和数据，整个产品开发周期内信息的透明度较高。
- 实时更新的优点：可实时了解所有开发团队的进展，随时沟通，有助于团队做出更明智的决策，增强协作能力。
- 强大的可视化能力：我们可以看到测试如何追溯到需求，这样有助于提升产品质量和规范性。
- 复用已验证的需求：可以重用已验证过的需求，在不同产品上复制验证过的功能。
统一的需求管理平台（如PingCode等）可帮助我们更有效地定义和处理非功能性需求，提高产品开发效率。所有数据、对话和决策都可被集中在同一个系统中，确保了信息的一致性和准确性，有助于减少误解和混淆。统一的需求管理平台也可以避免重复输入数据或者重复讨论同一个问题，更好地跟踪项目的进度，避免错过重要的时间节点，可极大提高客户对产品的满意度。
