一、稳定性

系统非功能性需求分析 系统非功能性需求分析写哪些

系统非功能性需求分析 系统非功能性需求分析写哪些

如果你的同时参考人数(并发数)特别大，对稳定性的要求会更高。

同时考试的人数用专业点的术语来讲就是并发性，即在某一段时间内计算机系统对于多个计算同时执行的能力。线上考试平台支持的同时考试人数越多，则并发性越强，需要的系统性能就越高，价格自然就越贵。

建议用户在购买产品时，选择同时考试的人数档次稍大一些，不光能够避免一些临时性的突发状况，对于考生实际参加考试的过程中体验也会较好一些。过低的并发性可能会导致考试过程中出现延迟、卡顿、宕机甚至崩溃的状况。

二、并发性

在线考试时，一般时进入考试界面和提交试卷时的并发，除开稳定性外，是否能高效进入和提交也是值得高度关注的，这直接关系到考生的成绩。

网络上的考试平台现在也有不少，虽然使用上大同小异，但关键时刻不同平台之间还是有异的。以并发性这项需求来说，平台提供的并发性数据是否真实有效其实有待商榷。因为用户没有条件尝试后再买，毕竟平台说并发性支持5万考生，用户不可能真的组织5万考生先去测试。在这种情况下不容失误，所以参考平台的历史案例就十分重要。

三、价格

如果前三点都完美匹配了，你再来比较价格。价格的话有当前价格和后续升级服务的价格，这些都要三思。

四、服务

话说一款产品好不好，服务也是其中一个重要原因。服务的话，个人觉得解决和处理问题的时效性是重中之重。

一般是从安全性、可靠性、作方面、延展性、可维护性方面去进行描述

优考试的考试系统在这些方面都做的很好，可参考

也有很多，包括 系统运行环境、系统的易用性需求、性能需求、可靠性、安全性、易用性、灵活性

【翻译】需求分析之非功能性需求

翻译自 Nonfunctional Requirements

非功能需求（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与SAFe各级的待办列表相关，如图1所示。

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

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

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

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

NFR在框架中被建模为待办列表约束，如图2所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

非功能性需求定义了评估整个系统的标准，也成为质量属性并且在架构规范中有明确描述。这些标准不是针对一个特定的行为，而是针对整个系统的。

所有的非功能性需求可以分为两大类：

在系统运行期间影响系统运行，用户作体验的非功能性要求

影响系统开发和运维的非功能性要求

一个成功的系统通常都会同时满足多个非功能性需求。在满足一个非功能性需求时，需要考虑对其他非功能性需求的影响并找出非功能性需求之间的折中方案（找到多个质量属性之间的平衡）。每个系统对非功能需求要求以及即使非功能性需求相同，其中的优先级也是不同的。

本文并未涵盖所有现有属性，但涵盖的那些属性可以作为设计系统的良好开端。

Image 2. ISO/IEC FCD 10 diagram

上面的标准描述了软件产品的质量属性。下面，我们将详细讲解每个属性的意思。

性能（Performance）

性能反应了在某段时间内系统对某些作的响应，有两种方式来度量性能：

延迟（Latency）：响应（作）所花费的时间。

吞吐量：在某个时间单位内发生的数。

在实践中，可能的性能指示包括以下几种，比如：

单位时间平均/系统用户数

页面平均加载时间

方法平均执行时间

性能问题通常会影响系统的各个方面，包括的吞吐量，前端的开发方式，数据库查询的优化以及网络通信的优化。

因为性能会影响整个系统并且会影响架构决策的很多方面，所以性能一直都是架构师需要认真考虑的一个质量指标。

互通性（Interoperability）

互通性描述的是系统或者系统中的一部分跟外部系统交互或者传递数据的能力。一个设计良好的系统有利于集成第三方系统。为了提升系统的互通性可以使用良好设计的外部接口，标准系统等等。

但是对于互通性还存在很多的问题：

过时的外部系统

相似的外部系统使用不同的数据格式

外部系统中不同版本的API

集成API的向后兼容性

质量的、缺乏标准的外部系统

互通性不能被忽略。的情况是，为交互API创建额外的层。在最坏的情况下，就需要考虑重建整个系统。

可用性（Usability）

可用性是最基本的属性，跟其他属性的情况不同，用户可以直观地感受到这个属性的好坏。可使用性最的问题是，为了完成一个任务需要很多的交互和作。在多级界面中不正确步骤顺序也是可用性的问题之一。数据元素和控件没有根据用户接受的模式来设计也会造成复杂作。比如，在开发IOS应用时，使用Apple的指南是很重要的。

此属性的重要指标如下：

支持的设备、作系统版本、屏幕分辨率和浏览器及其版本的列表。

加速用户交互的元素，比如“热键”，“建议列表”等等。

用户执行单个作所需的平均时间。

支持残疾人无障碍作。

可靠性（Reliability）

可靠性是描述系统在预设的条件下正常运行的能力。大多数情况下，系统会因为无法访问外部资源（例如数据库、系统和网络连接）而失败。

可用性（Availability）

可用性是可靠性的一部分，并通过系统正常运行时间占比整个工作时间来表示。可用性的重要指标是：

可用性

停机时间

更新软件所需时间等等

性能需求，可靠性需求，易用性需求，安全性需求。

对于非功能性需求描述的困难在于很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚，在描述这类需求时候我们经常采用软件性能要好，查询要在多少时间内出结果，软件健壮性要好等较模糊的描述词语。

这类描述词语都是脱离了软件的执行环境，人和相关的场景的描述，因此信息很难体现到软件架构设计和具体的实现中。我们在架构设计中关注的安全，系统开发框架，并发和性能，异常日志等不是凭空产生出来的，而是来源于我们对非功能性需求的分析。

非功能性需求分析注意事项

在调研业务需求时，要时刻留意功能实现对非功能性指标所带来的影响，并在调研过程中有意识地了解系统运行的相关情况，例如客户提供的硬件设备，用户量，业务量，业务办理频率、峰值等问题。

对于一些客户明确提出的关键指标或可预见的问题，如大数据应用的性能问题，或者像可靠性、可用性等问题，需要让架构师提前考虑，在技术上给出解决方案，在工作中及时总结，记录问题和解决方案，并进行归类整理，在下一个同类的系统或项目时，做到提前考虑。

非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。

包括

安全性、可靠性、互作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性。