细节决定成败。

-Common谚语

非功能性要求

非功能需求（NFR）定义系统属性，例如安全性，可靠性，性能，可维护性，可伸缩性和可用性。它们作为跨越不同积压的系统设计的约束或限制。

也称为系统质量，非功能性需求与功能性Epics，Capabilities，Features和Stories一样重要。它们确保整个系统的可用性和有效性。未能满足其中任何一个可能导致系统无法满足内部业务，用户或市场需求，或者不符合监管机构或标准机构强制要求的系统。

NFR是持久性质量和约束，与功能要求不同，它们通常作为每个迭代，程序增量（PI）或发布的完成定义（DoD）的一部分重新访问。 NFR存在于所有积压中：团队，计划，解决方案和投资组合。

NFR的正确定义和实施至关重要。过度指定它们，解决方案可能成本太高而无法生存;指定不足或低于它们，系统将不适合其预期用途。探索，定义和实施NFR的自适应和增量方法是敏捷团队的一项重要技能。

细节

考虑影响解决方案整体适应性的所有类型需求的一种方法是管理要求[5]中描述的“FURPS”分类：功能，可用性，可靠性，性能和可支持性

功能需求主要表现在用户故事以及功能和功能中。这是大多数工作发生的地方。团队构建了为用户提供价值的系统，解决方案开发的大部分时间和精力都致力于此。

FURPS是非功能需求的占位符。虽然它们可能有点微妙，但NFR对系统成功同样重要。 NFR可以被认为是对新开发的限制，因为每个NFR都为构建系统的人消除了一定程度的设计自由度。例如，基于SAML的单点登录（SSO）是套件中所有产品的要求。 （SSO是功能要求，而SAML是约束。）

NFR可以涵盖广泛的业务关键问题，这些问题通常很难通过功能要求来解决。作为对系统设计人员的提醒，[1]中描述了这种潜在NFR的综合列表。

NFR发生在所有级别

NFR与SAFe各级的积压相关，如图1所示。

图1. NFR发生在所有级别

由于NFR是敏捷发布系列（ART）和价值流创建的解决方案的重要属性，因此它们最明显的表现形式是程序和大型解决方案级别。系统和解决方案架构师和工程师通常负责定义和完善这些NFR。

所有团队都必须了解他们为系统创建的特殊属性。加速NFR测试，而不是推迟测试，有助于培养内置质量实践。团队将相关的NFR纳入其国防部，将其用作本地设计和实施决策的约束，并自行负责某些级别的NFR测试。否则，该解决方案可能不满足关键NFR，并且在该过程的后期发生的校正成本可能非常高。

此外，团队积压NFR也很重要，因为它们会对出现的功能和子系统产生约束和性能要求。

投资组合积压可能也需要NFR。这通常是跨系统质量的情况，例如单点登录情况。其他示例包括对开源使用，安全要求和监管标准的限制。如果尚未实现特定的投资组合级别NFR，则可能需要启动器实施它。 NFR在“史诗假设陈述”中定义，用于描述商业和推动者史诗。

NFR作为Backlog约束

NFR在框架中被建模为积压约束，如图2所示。

图2.积压受NFR限制

此外，SAFe需求模型指定NFR可以约束零，一些或许多积压项目。此外，为了知道系统符合约束，大多数NFR需要一个或多个系统质量测试，如图3所示。

图3.积压项目，NFR和系统质量测试之间的关系

许多NFR都是需要解决的推动因素。之后，他们会限制系统和所有新的积压项目。

NFRs对解决方案开发的影响

非功能性需求可能对解决方案开发和测试产生重大影响。 NFR很难指定;太容易过火了。例如，像“99.999％可用性”这样的声明可能会比“99.98％的可用性”以指数方式增加开发工作量。有时这是必要的，有时则不是。但是那些定义要求的人必须很好地理解NFR的影响。类似地，如果没有给予足够的考虑，诸如重量，体积或电压的物理约束可能导致解决方案过于复杂和昂贵。

解决方案的经济框架应包含评估NFR的标准。应在与成本和其他考虑因素进行权衡的背景下看待NFR。 NFR也影响供应商，因为它们不正确地宣布它们，或者没有经济框架的完全权衡后果，可能导致不必要的复杂和昂贵的系统和组件。

定期重新评估NFR也很重要。与其他要求不同，NFR是积压的持久约束，而不是积压项本身。因此，在PI Planning期间，它们可能并不总是出现。但NFR在开发过程中确实会发生变化，因此确保它们得到解决非常重要。

NFR和解决方案意图

解决方案Intent是解决方案的唯一真实来源。因此，它包括NFR以及功能要求。它还包括NFR之间的链接，它们影响的要求以及用于验证它们的测试。 NFR在理解固定与可变解决方案意图的经济学方面发挥着关键作用。

图4.解决方案意图

在早期，一些功能尚不清楚，需要在开发期间与客户进行测试和协商。 NFR也是如此。有些是固定的，事先众所周知;其他人将随着解决方案而发展。

通过施加约束，NFR可能影响广泛的系统功能。因此，在以下情况下，它们是需要考虑的重要因素：

•     分析业务史诗，功能和功能
•     规划和建造建筑跑道
•     重构以更好地反映不断增加的解决方案领域知识
•     对制造，部署，支持，安装，可维护性等施加DevOps限制

用于帮助开发解决方案意图的工具提供了一些机制来建立定义和实施NFR的经济方法：

•     合规性 - 这证明系统或解决方案符合法规，行业和其他相关标准和准则
•     基于模型的系统工程（MBSE） -  MBSE可用于模拟NFR的影响，并可链接到验证它们的测试
•     基于集合的设计（SBD） -  SBD为实现NFR提供了不同的选项，可以指导一系列边缘案例测试以支持设计决策

详细说明NFR

与所有其他要求一样，必须对NFR进行量化，以确保每个人都能清楚地理解利益相关者的愿望。 [3]中的图5量化了NFR要求。第1步定义NFR的质量，包括其名称，规模和测量方法。第2步量化NFR的可测量值，包括当前测量值（基线），要达到的值（目标），变得不可接受的值（约束）。图5中的示例显示了自动驾驶车辆速度限制检测的可测量效率。平均而言，用户当前手动设置每英里的速度.1时间，从而覆盖自动化解决方案。新系统功能将提高到每英里0.01倍，但在实施过程中不应低于每英里.15次。

图5.定义NFR质量

考虑以下标准有助于定义NFR：

•     有界 - 当他们缺乏有限的背景时，一些NFR是无关紧要的（甚至是有害的）。例如，性能考虑因素对于主应用程序而言可能是至关重要的，但对于管理和支持应用程
•     独立 -  NFR应相互独立，以便在不考虑或影响其他系统质量的情况下对其进行评估和测试。
•     可协商 - 了解NFR业务驱动因素和有限的上下文要求可转让性。
•     可测试 -  NFR必须以客观，可测量和可测试的标准陈述，因为如果您无法测试，则无法发货。

实施方法

许多NFR规定必须进行一些额外的工作 - 无论是现在还是将来 - 以满足它们。有时NFR必须一次全部实施;其他时候，团队可以采取更多的增量方法。经济框架中描述的权衡取决于实施方法。实施应该以允许几个学习周期来确定NFR的正确水平的方式进行。

•     一下子 - 一些NFR似乎是新的问题，需要立即实施。例如，衍生品交易的新监管规则，如果不立即适应，可能会使公司完全退出市场或导致监管违规。
•     逐步增加的故事路径 - 在其他时候，团队可以选择。例如，如图6所示，可以随着时间的推移处理对显着改善的性能的需求，一次一个故事。

图6. NFR的增量实现

NFR的实施也受到ART组织方式的影响。围绕建筑层构建的ART将发现完整地实施和测试NFR具有挑战性。然而，围绕能力组织的火车将更容易实施，测试和维护系统性NFR。

使用Agile Architecture支持NFR的开发，并在需求发展时帮助保持灵活性。

测试非功能需求

当然，要知道系统符合NFR，必须对其进行测试。敏捷测试象限的象限4，'系统质量测试'是大多数NFR测试的基础。由于其范围和重要性，NFR测试通常需要系统团队和敏捷团队之间的协作。为了防止技术债务，团队应尽可能自动化，以便这些测试可以连续运行，或至少按需运行。

然而，随着时间的推移，即使在自动化的情况下，越来越多的回归测试可能会消耗太多的处理时间和太多的资源。更糟糕的是，它可能意味着NFR测试可能仅在某些情况下或仅与专业资源或人员一起实用。为了确保实用性和持续使用，团队通常需要创建简化的测试套件和测试数据，如图7所示。

图7.与系统团队和敏捷团队的协作，以创建更实用的NFR测试策略

虽然部分测试听起来不太理想，但它有助于提高系统质量：

•     当团队可以在本地应用简化的测试套件时，他们可能会发现测试数据或测试方法的不一致
•     团队可以创建新的和独特的测试，其中一些可以被系统团队采用以帮助构建更大的集合
•     测试基础架构和配置可能会持续改进
•     团队对NFR的影响有了实际的了解，这有助于改进业务和启动器功能的估算

即便如此，在某些情况下，可能无法每天获得可以测试NFR的环境（例如，车辆引导软件的现场测试）。在这些情况下，可以使用以下方法[4]：

    使用虚拟化硬件

    创建模拟器

    创建类似的环境

在所有情况下，有效地测试NFR需要一些思考和创造力。另一方面，缺乏NFR测试可能会增加大量技术债务或更糟糕的系统故障的风险。

 

学到更多

• [1] https://en.wikipedia.org/wiki/Non-functional_requirement
• [2] Leffingwell，Dean。敏捷软件要求：团队，计划和企业的精益需求实践。 Addison-Wesley，2011年。
• [3] Leffingwell，Dean和Ryan Shriver，非功能性要求（系统质量）敏捷风格，敏捷2010。
• [4] Larman，Craig和Bas Vodde。扩展精益和敏捷开发的实践：大规模Scrum的大型，多站点和离岸产品开发。 Addison-Wesley，2010年。
• [5] Leffingwell，Dean和Don Widrig。管理软件需求：用例方法（第二版）。艾迪生 - 韦斯利，2003年。

原文：https://www.scaledagileframework.com/nonfunctional-requirements/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】