UML 非功能（操作）要求规范和应用: 处理NFR(非功能需求)的常见错误及其纠正方法

 

处理NFR(非功能需求)的常见错误及其纠正方法

 

常见错误	纠正错误	举例
没有充分注意NFR，因为它们无法在视觉上建模	NFR应被视为功能要求的重要性; 提取NFR的方法是创建原型（例如，技术，界面，业务）。	请参阅本章的早期讨论和第16章中的原型设计。
没有意识到软件解决方案的用户体验在很大程度上取决于其NFR	举办一系列正式研讨会，记录NFR。	重新审视图20.1至20.3，以了解NFR的深度和广度，并写出与每个标题相对应的实际要求。
假设安全性是一个完全独立的实体，可以稍后以某种方式添加到正在开发的软件解决方案中	开始讨论每个用例和每个活动图的安全性。	请参阅本章中的讨论，然后重新访问用例文档以增加安全性。
只有在系统开发生命周期结束时才会测试卷和性能	特别是这两个NFR不能等待系统完全可执行。 相反，开始使用软件版本的初始模块测试这些要求。	请参阅本章中的讨论。
NFR都处于同一水平	NFR处于不同的级别，因此需要在相关级别的组织，项目，流程，用例和数据中进行记录。	各种NFR水平见图20.3。
可用性与用户体验相同	可用性涉及设计的精确性; 用户体验是用户从系统中获得的总体结果。	请参阅本章中有关可用性和用户体验的讨论; 还重新讨论了第16章的讨论。
云旨在处理数据存储	云计算是大多数新软件应用程序的组成部分。 云不仅可以处理数据，还可以处理分析和处理。 云还促进了系统，数据库和企业之间的协作。	请参阅本章关于云的讨论。

 

 

非功能（操作）要求规范和应用

 

NFR解决了诸如正常业务事务下的整个系统的性能，用于改变客户数量的系统的可扩展性以及基于web的架构上部署的系统的安全性之类的问题。此外，安全性，数量，服务质量（QoS）和可维护性也是NFR的一部分。系统的参数不是其功能（工作流程）的一部分，但对于良好的用户体验至关重要，这是NFR讨论的重点。

 

◾使用UML NFR和UML的软件工程

上述操作（非功能）需求不能用例如用例或活动图建模。 UML没有针对NFR的特定建模构造（符号或图表），因为它的主要重点是对功能（行为）要求进行建模。但是，NFR可以在UML图中以各种方式出现。例如，注释，约束和标记用作使用NFR注释UML图的机制。架构（背景）建模空间中的组件和部署图最适合描述其中的NFR。

特别是UML的注释功能在指定NFR方面有很大帮助。 Notes用于用例，活动和类图，以突出显示系统的操作需求。例如，用例图中的注释突出显示该用例在一天或一年中的最大用户数。

NFR的来源组织的建筑和运营限制是NFR的主要来源。例如，拥有Windows 8操作系统的限制（约束）会影响在组织中部署软件解决方案的方式。因此，软件解决方案必须能够在整个组织的Windows 8上运行。智能手机的操作系统（例如，iOS或Android，加上相应的版本号）是组织的策略规定了该系统的操作要求的另一个例子（在这种情况下是移动应用程序）。

组织的企业体系结构（EA）限制内容的类型和大小，分析，知识创建和客户交互。这些EA因子是NFR的重要来源。组织的技术边界和局限性影响NFR。

除了开发的软件的操作要求之外，一些额外的约束也会影响NFR。这些是项目和组织级别的约束，与直接属于软件解决方案的约束不同。以下是影响软件项目中NFR的一些因素的示例：

◾组织的现有技术环境，其功能和局限性

◾软件项目中使用的现有工具和技术

◾当前的项目背景，预算，资源及其局限性

◾项目的类型，大小和重要性

◾操作软件解决方案的过程

◾影响系统开发和部署方式的法律和合规专家（即律师），提供绑定解决方案的另一个操作要求来源这些NFR最终会影响最终用户的感知。软件解决方案的前端（例如在网站或移动应用程序上）受其后端性能参数的限制。例如，如果应用程序的网页由于低带宽而冻结，则用户不感兴趣或不能感知该基础非功能参数。用户的整体感知称为“用户体验”，由于操作性能差而受到影响。 NFR对于增强用户体验至关重要，它们在软件建模和开发中应该得到独立和专注的关注。

 

非功能参数的类型图20.1显示了系统中最常见的非功能参数的示例。这些非功能性参数在软件开发的早期阶段被陈述为要求。

系统的NFR不是孤立的，独立的要求，即使它们在这里如此呈现。相反，这些NFR彼此依赖，并且基于EA的约束一起应用于软件解决方案。

以下是NFR的摘要（如图20.1所示）。本章稍后将详细讨论这些NFR中的每一个：

◾性能（带宽） - 通常根据系统预期的响应速度来指定。基于Internet的部署的性能要求取决于可用带宽。例如，可用处理能力和要处理的数据量等因素也会影响性能。

 

◾可扩展性（时间） - 系统随时间的预期增长和使用。随着用户数量的增长，可扩展性包括系统参数，例如数据存储和与系统相关的性能。可扩展性要求取决于时间因素（第二天，一个月或一年的增长和需求）。

 

◾卷（数据库） - 例如，系统运行时预期的数据库大小。当前使用的数据空间以及操作数据库的备份和镜像是此要求的一部分。

 

◾可用性（QoS） - 这些要求的示例包括允许的维护停机时间，允许系统脱机的次数以及不同类型系统故障的预期QoS。

 

◾可操作性（平台） - 目前运行的几乎所有系统都需要后端操作系统和前端浏览器技术。此要求指定操作平台的类型和用于系统的浏览器。由于动态改变设备和位置（在移动接口的情况下），浏览器的规格变得非常重要。整个范围的浏览器和操作系统及其版本对于指定此NFR至关重要。

◾可访问性（设备，物联网） - 这些NFR处理用户设备的易用性。这种易于访问需要考虑可能有特殊需求的用户（例如，如果要求用户输入验证码字符以验证它们不是机器人，那么这些字符也应该以音频格式提供以确保某些用户不会处于不利地位） 。可访问性不仅限于用户的需求;它也是一个强制性的监管要求（本章后面会讨论）。

◾可靠性（信任，风险） - 此NFR基于系统的关键性。例如，飞机导航系统可以具有更接近十二西格玛（相对于六西格玛）的可靠性规范 - 隐藏十亿分之一，而不是百万分之一的缺陷。

◾环境（碳） - 环境意识在商业中日益增加的重要性意味着需要指定系统的碳含量。虽然一些业务系统可能不会直接导致碳排放，但它们对后端数据服务器的影响越来越多地计算在组织的整体碳排放中（Unhelkar，2011）.1或者，碳排放管理系统对其排放有更详细的规范。碳容量被指定为非功能性和功能要求。

◾法律（合规） - 金融系统总是要求跟踪和审计。虽然其中一些要求本质上是功能性的（例如，记录审计员的详细信息），但其他处理创建审计跟踪和备份的要求可能无法直接起作用。相反，法律要求被指定为无功能，需要仔细的演练和检查，以便在系统中进行验证。

前面的NFR中的每一个都受到四个其他非功能（操作）参数的影响。这四个参数如图20.1所示（本章稍后将对此进行更详细的讨论）。这些非功能性参数如下：

◾安全性（级别） - 此要求差异很大，从系统中的特定功能或用例到访问其Web门户的组织策略。

安全要求的示例包括加密（例如，128位），密码策略和浏览器要求。

◾可用性和用户体验 - 此要求适用于图20.1中心所示的所有其他要求。虽然可用性本身涉及系统的典型用户界面的易用性，但是用户体验处理在通过系统与组织交互时用户的整体“带走”。因此，图20.1中间的所有非功能性参数都会影响用户体验并受其影响。

◾大数据（速度和变化） - 这在图20.1中显示为更高级别的要求，它影响并受该图中心的所有其他要求的影响。虽然与大数据相关的要求较新（与早期的程序和面向对象的软件工程方法相比），但重要的是要将这些要求纳入任何新系统的总体NFR中。进入系统的数据速度尤其如此 - 例如当物联网设备（健身腕表，血压监测设备或碳排放记录设备）收集数据并将数据发送到系统时。此外，由于数据 - 音频，视频和图形的多样性，大数据还增加了非功能参数的挑战。

◾云计算在NFR讨论中提供了一个重要参数，因为大多数新软件系统（包括特别是移动应用程序）将其数据存储在云中。即使是拥有内部数据库的企业系统也会将这些数据库迁移到私有云。例如，容量，可用性，可伸缩性和可靠性参数受云计算架构的影响。随着云端的后端数据和处理（分析）也转移到云，系统的可用性及其可靠性取决于云的可用性以及承载连接到云的中间网络。

NFR的复合敏捷方法和策略以及原型制作第4章讨论的复合敏捷方法和策略（CAMS）鼓励对解决方案进行详细讨论，建模和原型设计，以便能够处理这些NFR。第16章讨论了原型设计在建模软件中的重要作用。

原型设计可以模拟应用NFR的技术环境。

因此，在项目开始时，为NFR创建原型变得至关重要。业务分析师与技术和业务专家合作创建原型，并通过测试确保在系统完全开发和集成时最终满足NFR。例如，在发现应用程序完全开发后，128位加密不适用于特定应用程序是没有意义的。通过创建技术原型，在项目中尽早测试NFR。

为了帮助改进估算和假设，CAMS建议在项目早期正式让业务分析师和用户参与进来。建筑师和解决方案设计师与业务分析师一起探索NFR并进行他们的概念验证原型。业务分析师与业务利益相关者，架构师和解决方案设计师密切合作 - 特别是在NFR方面 - 是CAMS在实践中的重要组成部分。

NFR类别：质量和约束NFR大致分为两部分：运行中系统的各种“质量”或属性以及系统上相应的“约束”。

图20.2显示了这两个主要类别的NFR：约束通常来自EA，而质量往往是在系统架构级别指定的。

约束：

◾这些是系统架构和设计的限制。在系统架构和设计期间遵守约束可确保部署的系统在这些组织参数内正常运行。各级限制的示例包括： - 组织（例如，100 mbps带宽） - 项目（例如，350 k预算） - 时间范围（例如，必须在某个日期之前生效）质量：

◾组织（例如，3秒响应时间）

◾项目（例如，每个需要进行演练的要求）

◾可接受性（例如，每百万1个缺陷;或每天23小时58分钟的正常运行时间）业务分析师以及关键业务用户和架构师，可以很好地调查和指定这些NFR。此外，业务分析师还可以概述这些NFR的验收标准（测试）。

系统的质量（偶尔也按照各种“能力”分组）由业务分析师与用户和领域专家合作指定。对系统的约束通常由了解适用于系统的组织参数的企业架构师决定。

NFR挑战NFR在开发生命周期的早期阶段有被忽略的趋势。偶尔会发生这种情况，因为这些NFR不是系统的行为，因此不容易记录和建模。

NFR的另一个困难是，当系统的至少某些部分已经开发时，它们开始变得相关。例如，指定和测试系统的性能不是用UML图建模的;相反，它只能在系统在生产等效环境中可用时进行验证。

因此，关键业务利益相关者和领域专家之间的互动是获取NFR的必要条件。然而，即使这些相互作用也不足以在项目开始时成功捕获NFR。这是因为当涉及到NFR时，专家会做出有根据的估计（猜测）以确定NFR。例如，预计在银行应用程序的第一年（10,000？或100,000？）打开的帐户数量可以是“任何人的猜测。”估计是在项目开始时进行的，然后作为迭代和增量进行细化。系统的发展进步。 NFR的迭代和增量方法确保系统的体系结构能够处理NFR。

由于NFR中涉及的猜测工作，将这些要求与相应的假设配对也是一个好主意。以预计将在第一年开设的100,000个账户为例，当与在线营销和银行的社交媒体相关时，假设可以相当准确。可以看出，这些要求对于满足系统用户在操作中的需求和“体验”以及最终的接受度是至关重要的。

组织系统和项目功能和用例数据和类项目（例如，35万美元预算）项目（例如，每项要求需要演练）组织（例如，3秒响应时间）组织（例如，100 mbps带宽）约束质量NFRS图20.2两个主要类别的NFR竞争约束（架构师说明系统不能做什么）和质量（业务利益相关者在功能中说明他们对系统的要求）。

在CAMS中捕获NFR业务利益相关者和领域专家参与通常由业务分析师组织的研讨会，以发现这些不熟悉和不明确的要求。对于NFR缺乏标准化的建模构造（特别是在纯粹的敏捷方法中）也意味着它们不是在视觉上建模的。此外，业务利益相关者可能不会完全了解NFR。

系统所需的正常运行时间或实现正常运行时间所需的资源可能在项目开始时仍然不确定和未建模。在需求建模研讨会上开放关于NFR的讨论是开始捕获这些NFR的理想方式。例如，如果企业要求对其新解决方案（系统预期的性能相关质量）的响应时间为3秒，那么企业架构师可以说：“不，这是不可能的，因为我们只有具有一定的带宽可用 - 100mbps。“一旦讨论（虽然不一定要整理或解决），它为业务利益相关者提供了增加预算以实现他们期望的解决方案质量的大门。或者，降低他们的期望。如果这些NFR在解决方案的后期阶段保持不变或未被讨论，那么解决方案的期望和提供将不匹配。

CAMS和NFR测试功能和非功能需求之间没有一对一的关系。

 

但是，仔细检查功能要求总能对NFR产生影响。许多NFR适用于项目和组织层面，但不适用于单个功能层面。这可能是NFR通常落后于功能要求的另一个原因。测试NFR也可能落后 - “因为没有系统，所以没有太多可以检查性能。”在CAMS中鼓励创建可以测试NFR的系统的早期原型。企业架构师和解决方案设计人员可以一起工作来加载数据库并针对这些测试数据库运行原型，而不仅仅关注功能需求的实现。这是NFR规范（包括性能，可扩展性和安全性）的方式，以及它们在解决方案中的结合是在CAMS中实现的。

由于NFR适用于整个组织，因此业务利益相关者可能无法完全理解这些要求应用于软件系统的级别。业务分析师强调NFR及其与成本和时间的关系。业务利益相关者对系统的期望质量需要具有相关的成本和时间，这两者都会随着业务预期的增加而上升。请注意，这些不是新的预期功能，也不与这些功能的更高质量相关联（需要更高的测试严格性）。 NFR中的这些特性是系统运行时的特征。系统对NFR的更高要求具有相应的成本和时间，需要在项目中加以考虑。

例如，利益相关方同意尽可能高的安全性，24×7正常运行时间以及镜像数据以提高全球性能。除非业务分析师显示这些NFR中的每一个与实现该要求所需的相应成本和时间之间存在直接关系，否则随着项目的进展，这些NFR将继续出现（并且增加）。

 

◾具有UML NFR级别的软件工程NFR不限于系统。相反，NFR来自组织内的各个级别并在其中应用。了解NFR的适用性水平最有助于确定它们在何处以及如何影响正在开发的系统。 NFR可以是整个EA的一部分，适用于特定系统级别，或应用于单个功能单元。确定NFR的级别并将其用于企业和系统架构以及这些架构的相应验证和验证非常重要。

图20.3显示了各种NFR水平：

◾组织级NFR适用于整个组织。因此，组织级NFR适用于为组织开发（或采购）的所有项目和系统。这些NFR的示例包括与电子访问，可用带宽，数据仓库资源和与用户相关的HR要求相关的策略。

 

◾项目（解决方案） - 级别NFR与项目产生的解决方案相关。这是整体解决方案，不仅仅是软件系统。例如，与解决方案相关的操作程序和规则可以在此级别指定为NFR。这些是适用于解决方案的规则。 （注意：这些与软件解决方案中嵌入的业务规则不同。）在软件系统级别指定时，这些NFR适用于软件解决方案的开发，部署和操作。例如，特定操作系统的要求或浏览器的版本号是可以涉及软件系统的操作但不一定涉及整个组织的要求。

 

◾流程（业务，系统） - 级别NFR是管理与解决方案相关的流程的一部分。因此，这些要求包括不属于任何视觉模型的详细业务规则。描述解决方案对系统的其他（通常是外部）元素的依赖性的系统级技术规则是此级别NFR的一部分。将规则与流程级NFR相关联的原因是这些规则在整个流程中应用，无法在视觉上建模，并且嵌入在解决方案中而没有对用户的直接可见性（因此，没有接口）。尽管流程规则具有隐藏的性质，但它们需要被指定为NFR的一部分。

 

◾用例（功能）级别NFR是适用于个别用例级别的要求（与上述适用于流程级别的规则和要求相比）。由于业务流程可以包含许多用例，因此此功能级别的NFR有助于数据套件（基础）用例（功能）流程（业务，系统）软件系统项目（解决方案）组织图20.3指定与软件解决方案关联的NFR并应用于组织内和项目的各个层面。

区分仅适用于一个用例的要求。例如，整个库存过程总体上可能有严格的审核要求;但是，与特定用例的审计相关的NFR可能没有相同严格的审计要求，这些用例涉及内部员工将库存从仓库移到店面。因此，用例级NFR修改或专门化适用于整个过程的NFR。

 

◾数据套件（基本）-NFR这里涉及一条数据或包含数据的表。

数据套件的NFR也适用于整个数据库。例如，与账户（典型银行应用程序）中的金额字段相关的NFR可以指定对四个小数点的合法（合规）需求。数据库级别的另一个NFR可以指定需要创建整个数据库的镜像，以确保提高关键业务功能的性能和可用性。

本章的其余部分详细介绍了迄今为止讨论的一些重要的NFR。

性能性能要求指定软件解决方案所需的速度或响应时间。

该性能标准在确定系统的效率和有效性方面起着重要作用。因此，该性能标准有助于整体用户体验。在大型复杂系统的情况下，子系统有自己的性能要求。例如，HMS中与患者相关的外部过程的性能要求是严格的（每页3秒），但对于内部员工相关过程，它可以更放松（每页5秒）。

在创建MOPS的早期阶段，应该谨慎地定义系统的性能标准。在开发的早期阶段，系统（特别是大型和复杂系统）分为子系统和包（第3章）。为每个子系统指定性能标准，然后将标准应用于整个系统。

将性能标准的规范留待以后是项目风险，因为一旦开发出解决方案，就很难对其进行重新架构和重新设计以满足性能标准。软件过程的迭代和增量基础在处理与NFR相关的风险，特别是解决方案的性能方面最有价值。

UML模型具有直接的标准化机制来显示性能要求。然而，CAMS鼓励在故事卡上记录NFR，其正常格式是列出系统的功能要求。 PRIMA-UML2等方法值得项目团队探索，试图在早期建模阶段获得性能要求。

响应时间和性能对于大多数实际用途，系统的性能等同于响应时间 - 即系统处理用户请求所花费的时间。无论正在执行的处理类型如何，最终用户都在寻求越来越快的响应时间。用户的需求基于使用系统的越来越多的专业知识，他们需要执行的功能越来越多，以及影响系统和设备的人类需求的心理社会因素。因此，用户不断增长的需求是系统可扩展性要求的一部分，需要将其纳入关于系统预期性能的讨论中。

如果不考虑影响性能标准的许多因素，系统设计将无法满足用户要求的性能目标。缺乏良好的系统性能可能会损害客户与组织的关系（例如，当系统响应不佳时，客户将总是拒绝系统）。内部组织流程也因系统性能不佳而受到影响，从而导致生产力下降和收入损失。如果系统需要重新设计以提高其性能，则项目将产生额外成本以及相关的机会成本风险（由于错过了市场窗口）。在极端情况下，整个解决方案都会被废弃，因为性能调整工作可能还不够，项目可能需要取消。

 

性能挑战的出现主要是由于在软件开发生命周期（SDLC）的早期阶段缺乏对NFR的关注。缺乏关注可能是由于难以从用户那里引出实际的性能要求。由于性能测试需要模拟技术环境（充足的数据库和执行系统），因此该测试也会在SDLC中推迟。此外，通过在构建软件系统中使用外部的，可重用的面向服务的组件，性能问题也可以依赖于那些外部服务。最后，通信机制（包括网络协议，安全需求，数据量和数据速度）也会影响系统的性能。

系统设计人员在设计系统时需要牢记用户的“期望时间”。重要的是要向用户传达要求更高性能时间与满足这些需求相关成本之间的平衡。系统响应的随机预期时间对于设置系统的目标和设计没有帮助。此外，响应时间不应太快以至于无法逃避用户的注意力。

性能要求及其满意度是技术，设计和开发以及用户期望之间的平衡。

响应时间和性能分析Miller（1968）3在他关于人机交互响应时间的研究工作中详细讨论了各种功能的基本响应时间。用户认为必要的预期响应时间几乎是瞬时的约0.1秒。这种情况发生在不需要特殊反馈的情况下，所需要的只是显示结果。一秒钟被视为系统在中断用户思维流程之前可以允许的最大延迟。即使感觉到这种延迟，也不会破坏用户对他/她任务的关注。十秒是最大时间范围，用户应将注意力集中在对话框（进度指示器）上。这提供了流程的预期完成时间，因此用户不会失去耐心并开始处理其他任务。

外包项目和绩效影响绩效的一个重要因素是软件开发外包。通常，外包工作等同于优势，包括显着节省成本，培训IT人员的可靠性，灵活的资源利用率以及最低的设置成本。常规的低级别任务可能会占用公司资源的很大一部分，这可能是利用外包的一个原因，这可能会大大减少执行这些日常低级别任务所需的资源量并间接降低公司资源花费。

尽管外包提供了多种优势，但是存在多种挑战。例如，如果外包供应商无法理解需求，特别是在敏捷项目中，无法协同参与开发，则整个系统的性能会受到影响。

服务级别协议（SLA）直接适用于性能分析。 SLA应明确说明所需服务的范围和性质。还应明确说明表现水平。吞吐量时间，周转时间和系统可用性等因素是直接影响系统性能的一些关键问题。一个完善的，装备精良且高效的供应商可以从系统的早期需求阶段参与，比仅仅签约“代码”的供应商更好地理解性能需求。带宽组织级别的带宽可用性与系统性能。

带宽可能是组织本身的IT基础架构对系统的约束。现有的组织通信网络和将携带软件解决方案的网络是性能不可或缺的。此外，需要研究，建模数据通信过程（例如向/从云发送和接收大数据）并将其合并到系统设计中。带宽可以对及时传递信息产生关键影响。

网络带宽是在给定时间内提供一定数量数据的能力。

应用程序要求组织内部和外部的高带宽负载网络。

 

软件解决方案的带宽规格应包括最低可接受的数据传输速率。然而，这种传输速率需要根据不同的负载而变化 - 这可以根据一天中的时间，访问位置和其他因素而变化。在示例HMS中，即使在64kbps的带宽下，仅交换静态和信息的模块也可以执行。 HMS模块进行密集分析，涉及病人视频剪辑和医学图像等多媒体信息的传输，需要更高的带宽，如4 Mbps。

可伸缩性可伸缩性是系统的NFR，用于逐步增加工作负载。由于来自用户的预期响应时间仍然相同，因此系统需求的扩大对其资源施加了约束。与可伸缩性相关的问题成为一个问题，特别是当系统运行成功时，因为系统提供价值越成功，用户对其服务的需求就越大。可扩展性要求涵盖范围：扩展到越来越多的用户，分析，用户界面和多媒体功能的分布，数据传输和存储，以及最终用户设备访问及其使用。

因此，可伸缩性既可以是技术要求，也可以是基于所使用的功能的业务需求。因此，可扩展性是可以在用例文档中输入的要求，作为在系统启动后的月，季度或年中可能使用该特定用例的用户的估计。

从技术上讲，可扩展性要求可以指定通过网络分配和平衡数据工作负载的技术和工具。此数据分布还有助于通过多个通道和并行会话进行传输。由于互联网和电子商务网站以指数级增长，因此可扩展性是项目可持续性中要分析的核心问题之一。

平衡扩展技术资源（尤其是基于云的资源）可以改善访问协议，存储资金的价值以及项目所有者利益相关者的总体满意度。

可伸缩性和硬件可伸缩性问题也可能具有硬件限制。为了应对更高的负载，可能需要添加更多处理器或更多服务器，具体取决于存在的问题类型。每个附加处理器都可以提高整体服务器性能。此外，良好的多线程架构技术可以帮助负载分配并提高系统性能，从而实现良好的可伸缩性。电子商务网站在后端涉及高水平的查询，这是一项耗费资源的任务。一个常见的过程是使用单独的数据库服务器，例如，从中央服务器中删除一些负载。

系统的体系结构应该足够灵活，以允许添加额外的硬件，因为这有助于项目的可伸缩性。架构空间模型中使用的部署图应该有助于开发一个没有可伸缩性问题的稳定系统。

HMS可扩展性要求示例HMS的可扩展性要求的示例包括这样的情况：例如，系统最初每天处理1000个事务，在发布后3个月，系统需要按比例放大以每天处理5000个事务。云端后端数据库空间的初始发布容量为1 TB;随着医疗数据的多媒体和相关内容呈指数增长，后端容量需求将在第一年增长到5 TB。此后，需要密切监视数据需求，以确保系统可以扩展以处理数据存储和处理的需求。

卷容量要求指定系统所需的总数据大小。该卷包括本地数据库，基于云的服务器，本地存储在计算机和智能手机上的数据等。随着大数据和相应云技术的进步，数据的数量（大小）对于系统的成功变得更加重要。

预计HMS将被员工和患者大量使用。网站交易的粗略估计是每天500。 HMS需要有效地处理数据 - 它们的摄取，质量，传输和安全存储。基于云的服务器可以处理HMS的负载 - 从服务器上的1 TB空间开始。体积需求的估计基于每天新患者（100）和返回患者（150）的数量，这些患者在其手术的第一年由HMS专门处理。除了患者的个人详细信息外，还有大量的多媒体数据，如外科手术，产前视频，恢复方法，其他健康相关视频，音频，图片和图形的视频，需要以各种格式存储。

 

操作系统系统的操作系统（OS）和相应的操作环境在项目开始时确定。这些操作系统要求并不像其他一些NFR那样难以确定。但是，决定操作系统及其版本对于开发工作至关重要 - 用户和系统架构师需要一起讨论这一要求，用户指定他们为什么需要在特定操作平台上运行的解决方案以及实现该操作的架构师组织给定参数内的要求。

除了现有的操作系​​统和环境之外，还需要结合兼容性和未来增长问题来处理此要求。举一个简单的例子，为Windows平台开发的系统无法在UNIX环境中工作，并引发兼容性和可移植性等问题。通过使用兼容接口，数据仍然可以作为服务传输到这些异构平台上;但跨多个平台执行系统是一个关键的NFR，需要业务和技术输入。

对于HMS，用户，业务分析师和软件开发人员聚在一起决定Windows操作平台最适合当前用户群（通常是员工）。

这些利益相关者还为系统的成功运行设置了最低工作条件，例如Windows 7或更高版本。浏览器要求可以是Internet Explorer v.9及更高版本以及Google Chrome，它能够执行所有系统功能，包括浏览，数据输入，编辑和保存页面上的内容。

移动操作系统通常移动应用程序在Apple iOS和Android操作系统上运行。这些操作系统为应用程序功能提供了基础。其附加功能包括安全性和性能调整。操作系统的要求基于管理资源，处理业务流程需求，满足设备分析需求（与后端基于云的分析相比）的需求，并提供安全性。

辅助功能辅助功能是一种重要的NFR，可增强用户体验。设计易于访问的软件解决方案需要了解用户的物理特性（和限制）及其可用性需求。可访问性要求也是大多数处理软件解决方案的政府机构的法律和合规需求的一部分。与物理可访问性需求类似，政府法规还规定了在解决方案发布之前软件解决方案必须满足的软件可访问性需求4。

可访问性要求的一个重要部分是确保它们不仅在设计，开发和测试期间满意，而且在系统完全部署时也满足。因此，与满足可访问性要求相关的工作仍然远远超出了软件的发布范围。

HMS的可访问性要求的示例包括用户（尤其是患者）处理颜色的能力（用颜色突出显示重要信息;色盲用户仍然可以获得信息），在屏幕上选择性地放大内容，基于上下文的工具提示，布局布置以对应于演员的逻辑工作流程，以及对键盘和鼠标的替代访问（例如，音频/声音输入和输出）。随着越来越多地使用物联网设备来监测患者参数，HMS的要求集中在最小干预和来自用户（患者）的输入上。因此，自动化是使用向HMS提供数据的物联网设备的关键标准。

可靠性和维护软件系统的可靠性和维护要求转化为用户最需要时系统的可用性以及系统在更改（维护）后重新联机的能力。

软件维护包括后交付活动，这些活动是为了系统稳定性和功能而执行的。维护通常被视为主要的资源消耗活动之一。迭代和增量方法也有助于维护周期（与新的开发周期相反），因为它可以计划对完全封装的包进行逐件维护。

除了一般的系统维护，数据库维护也是这个NFR的关键部分。维护策略应清楚地描述目标，功能，处理细节和验证程序。数据库维护策略描述了数据备份，数据清理和调度的过程。该策略还具有优先级计划，以在一般任务之前完成高优先级任务。维护过程包括定义，测量和改进风险分析和质量保证。

 

验证还构成维护策略的主要部分，并确保系统以所需方式执行。例如，在HMS项目中，使系统与各种组件和类的常规补丁保持同步是解决方案的重要组成部分 - 并且需要将这些活动纳入系统的迭代和增量维护生命周期。例如，每个月都可以更新HMS的每个包 - 只要一个更改对其他包没有影响。

维护还处理HMS数据的定期备份和镜像。此外，归档数据（不再在医院的患者和医生）也需要有计划的方法 - 并且需要在项目开始时指定为维护NFR。这种类型的维护消除了中央服务器的负载，并提高了解决方案的整体效率。

环境如前所述，越来越需要在解决方案设计中纳入环境要求。这些是与业务相关的可持续发展和环境要求。由于这些要求不是行为，因此属于NFR类别。

例如，涉及开发解决方案的总计算机硬件产生一定的碳含量;类似地，操作解决方案导致碳生成和对环境的相应影响。复杂的服务器技术和基于云的部署对组织的碳排放负有同等责任。计算硬件的相应冷却工作需要纳入碳计算中。

因此，系统的部署需要考虑系统的这些环境参数。

例如，HMS要求可以指定在开发工作期间产生的总碳将为100KT（千吨）。还可以估算碳产量（例如，每个用户每月1KT）。此外，这些环境要求规定了某些内部硬件要求（例如，低碳排放屏幕）和机器在不再使用时的回收（例如，自HMS发布之日起3年）。

法律和合规性大多数软件解决方案必须处理法律和合规性要求。这些要求源自业务情况以及开发和部署解决方案的地理区域。 NFR类别中的这些法律要求不同于作为系统逻辑一部分的法律要求。例如，如果法律要求规定在每个等级上增加10％的税（例如，增值税或商品及服务税），那么这就成为系统功能要求的一部分。操作系统的法律要求的示例包括托管系统，强制报告活动以及数据存储的隐私问题。

安全性安全性是迄今为止软件系统中最关键的NFR。早些时候，在图20.1中，安全性显示在框的顶部 - 影响所有其他NFR。这种影响很重要，因为从系统架构的角度来看，每个NFR都需要与系统的安全需求相平衡。假设世界上最安全的系统是一个根本无法访问的系统;但没有访问这样的系统是没有意义的。安全的理念和实施涉及在适当的时间和地点允许对权利（授权）人员进行相关访问的平衡行为。因此，安全性是系统的不断变化的动态NFR。

安全性也有很大的功能组件。例如，与现在无处不在的用户代码/密码访问相关联的功能可以使用用例和相应的活动图轻松建模。但是，在任何给定时间点访问系统并确保访问安全的用户数是与安全性相关的NFR的一部分。安全级别的数量，类型，加密需求，服务器，计算机和手持设备的物理安全性以及防火墙的实现是影响软件应用程序开发的重要非功能性参数。所有与安全相关的问题都不属于系统的功能或行为方面，通过NFR进行考虑，记录，原型化和验证。

有四个安全因素会影响软件系统中的所有安全级别。

 

图20.4a所示的这四个影响因素是机密性，完整性，责任性和可用性。系统的机密性要求描述了与未经授权的用户不公开信息相关的问题。完整性要求确保系统中的信息仅由具有适当访问权限（控制）的授权用户操作。问责制要求指定授权哪些用户以及具体时间。

 

 

可用性要求确保授权用户在需要时不会被拒绝服务。

这四个要求中的每一个都适用于为系统提供的安全级别（如图20.4b所示）。接下来描述这些安全级别：

◾物理安全性 - 对服务器的物理访问 - 在内部维护时（与云相比）需要仅限于授权用户。

- 服务器，网络和设备的物理位置应确保其安全性;这些机器应该对负责维护的人员是可访问的，否则其他用户不应该在物理上可见。

- 移动设备访问和设备潜在丢失需要考虑到系统的安全性;例如，确保数据存储在后端服务器而不是物理设备上，因此设备丢失不会导致数据丢失。

问责制可用性机密性完整性硬件安全性

•对服务器的物理访问 - 在内部维护时（与大声相比）

•与用户相比，服务器，网络和设备的物理位置

•移动设备访问和设备应用程序和浏览器可能容易丢失

•通用密码保护和用户培训

•密码的两部分验证

•特定于用户的生物识别（音频，指纹）访问

•恢复选项 - 基于用户的标识问题，设备和其他电子邮件

•浏览器的类型，版本和安全性（例如，用于存储密码）操作系统和平台

•加密应用程序和服务器之间发送/接收的数据

•操作系统的防御机制

•操作系统和服务器网络中内置的攻击性（检测）

•LAN，WAN（本地）和本地网络安全

•VPN（组织内部）通过提供访问的安全管道

•互联网访问和应用程序的安全性

•移动运营商网络和平台 - 以及内容提供商的责任（a）（b）图20.4软件和移动应用安全：（a）影响因素和（b）级别。

 

◾应用程序和浏览器 - 常用密码保护机制（如密码的长度和组成）以及使用浏览器方面的相应用户教育（例如，不在浏览器中保存密码） - 密码的两部分身份验证作为一个过程（这将是一个功能模型，虽然这里作为NFR的一部分讨论）。

- 特定于用户的生物识别（音频，指纹）访问 - 减少未授权访问的机会并增加责任 - 基于用户的识别问题，设备和其他电子邮件的恢复选项确保特定应用程序和设备的访问的完整性。

- 浏览器的类型，版本和安全性（例如，如果用于存储密码 - 尽管不建议使用）以确保用户的机密性和责任性

◾操作系统和平台 - 应用程序和服务器之间发送/接收的数据的加密保持数据的完整性。

- 操作系统的防御机制确保解决方案的机密性和完整性。

- 操作系统和服务器内置的攻击性检测也确保了解决方案的机密性和完整性。

 

◾网络 - LAN，WAN（本地）和本地网络安全，以确保用户的授权访问。

- VPN（组织内部），提供用于访问的安全管道，模拟内部访问。

- 应用程序的Internet访问和安全性，以确保解决方案的机密性和完整性。

- 移动运营商网络和平台以及内容提供商的职责也是为了确保解决方案的机密性和完整性。

可用性和用户体验将可用性要求应用于软件解决方案第16章讨论了可用性和以使用为中心的设计原则在软件系统中的应用。屏幕之间的控制流程是需求的功能方面的一部分，这也在第16章中讨论过。这里讨论的可用性要求仅在它们处理接口的静态结构方面时才被认为是无效的。例如，移动应用程序的屏幕上的颜色和按钮位置是系统的非功能方面的一部分。可用性与几乎所有其他NFR一起使用。

可用性还描述了系统为用户目标添加的价值。关于可用性的讨论不仅要考虑创建良好的用户界面，还要考虑提高用户的最终价值。精心设计的用户界面使用户能够完成任务，提高生产力，减少与培训相关的时间和成本，减少用户错误，提供用户支持并提高界面的可维护性。

 

可用性有助于熟悉系统的用户轻松学习和采用界面。例如，对于熟悉使用基于Web的应用程序的用户，常见的OK，Cancel和Help按钮的存在和位置是众所周知的。由于大多数用户可能熟悉这三个按钮，因此它们应该以熟悉的位置和精心设计的界面顺序出现。

界面中所有字段和按钮的命名约定是可用性的一个重要方面。应清楚地命名每个字段和按钮以表示它执行的功能。

界面中按钮和字段描述的隐蔽或极长名称可能会导致不必要的混淆。例如，使用“PID”或“数字”来表示PatientNumber或患者身份识别不是一个好的设计。另一个常见的例子是使用“保存”按钮。尽管可以在用户界面中使用“保存”，但最好使用按钮上的“更新”或“注册”来进一步阐明按钮背后的含义。

设计以防止错误设计界面时要记住的总体原则是关注预防，而不是纠正错误。例如，如果用户输入患者的“注册日期”，则系统应首先向用户显示“今天的日期”，然后允许用户更改它。此方法可防止在从头开始要求用户输入日期（或任何其他数据）时可能出现的典型错误。还应该对用户的操作进行连续的交叉检查和验证，以防止错误的数据进入系统。例如，如果用户在填写界面UI10-PatientRegistrationForm中的信息后错误地按下取消按钮，则系统应该要求用户在执行之前验证该动作。

通过良好的用户界面设计，可以立即验证屏幕上的大量字段，而不是在“从”接口类传输数据之后由实体类验证。例如，输入有效日期几乎总是接口类的函数，而不是实体类。但是，一旦输入日期，它是否在语义上是正确的日期（例如，出生日期不应晚于今天的日期）是实体类的责任，而不是接口类。

最后，接口的设计应考虑到美学。例如，关于界面的信息通常从左到右运行，而不是相反，患者的名字出现在患者姓氏的左侧。应避免在屏幕上过度拥挤，并应使用颜色来传达意义并在视觉上令人愉悦。

大数据（速度，多样性）大数据是一个广泛的术语，顾名思义 - 大量数据;此外，这些数据以非常高的速度进入系统（很可能是因为它是由机器生成的，除了人类之外）并且包含多样性。各种数据的特征除了文本构成的音频，视频，图形，非结构化描述（博客，电子邮件）和机器生成。在设计和开发新的软件应用程序时，需要牢记大数据的上述每个特征。这是因为大多数新应用程序处理大数据的某些元素 - 无论是在采购数据，分析它们，还是如下一节所述，将其存储在云上。

云如本章前面所述，云计算是大多数新系统不可或缺的一部分，在确保满足解决方案的非功能或操作要求方面发挥着至关重要的作用。

 

云计算描述了一个系统，用户可以将系统连接到位于其他地方的大量计算资源，数据和服务器，通常位于Internet上，而不是本地计算机，LAN或数据中心。云是存储数据的默认机制，它在软件解决方案中的重要性超越了数据存储。与软件相关的处理，其数据的来源和共享，以及软件在用户选择的时间和地点实现协作的能力是云计算所启用的。

因此，应用程序和分析的实际执行也发生在云上。云无需在用户设备上本地安装软件和分析应用程序。

因此，计算成为一种可以按需提供分析应用程序的实用程序.6前面讨论的NFR（包括性能，数量，可伸缩性，安全性和操作平台）都受到云的影响。这是因为云将组织的整个后端呈现为虚拟。

 

因此，云形成了软件解决方案的系统架构的关键部分。 需要在早期需求收集阶段中探索云对软件解决方案的非功能参数的影响，然后在解决方案部署之前和期间通过定期测试进行探索。