一、非功能性需求都包括哪些方面？

非功能性需求，指的是信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素一般不会在用户的业务需求中进行明确的提出，需要分析人员根据实际业务需要进行调研归纳。

例如税务业务系统的非功能性需求，可以从以下几个方面进行分析。

一：性能方面：

1。响应时间：分日常交互类、日常查询类、批量交易分别考虑。

日常交易指传统的大厅交互业务，如纳税申报、发票销售等，以及一次完成多笔业务处理的交易，如批量扣款等，日常交互类业务具有较高的响应要求。 查询类业务如登记资料查询、申报数据查询等。查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，给出一个参考范围。

批处理业务如会计核算等业务处理，该类业务处理复杂、操作数据量大、处理时间长。

响应时间指标包括：平均响应时间参考值(秒)、峰值响应时间参考值（秒）。

2。用户数：用户数要考虑用户数的增长情况，有以下指标：总用户数、峰值在线用户数、峰值并发用户数、平均在线用户数、平均并发用户数。

3。吞吐量：系统交易量的估算。指标有年交易笔数（笔/年）、高峰期交易笔数（笔/天）。

4。数据存储量：每年的数据存储容量（G）及未来几年该数量的预期（增长）值。指标包括累计存储容量（G）、年增长（G）。

二、系统可靠性：一般是窗口业务应在从星期一到星期五的所有工作日的工作时间是可以使用的；其它业务应满足7×24小时可以使用；

三、可扩展性：可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。

所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。在这里可以看到非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。非功能性需求必须考虑软件既要可用，又要易用。

对于非功能性需求描述的困难在于很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚，在描述这类需求时候我们经常采用软件性能要好，查询要在多少时间内出结果，软件健壮性要好等较模糊的描述词语。这类描述词语都是脱离了软件的执行环境，人和相关的场景的描述，因此信息很难体现到软件架构设计和具体的实现中。我们在架构设计中关注的安全，系统开发框架，并发和性能，异常日志等不是凭空产生出来的，而是来源于我们对非功能性需求的分析。

一个软件系统必须完整，因此不仅仅包括了可执行的程序，还包括了在线帮助，数据和用户管理，日志异常查询，自动升级等相关功能特征。这些需求不仅仅是为了满足用户的需要，也是为了我们后续维护和监控系统的需要。

系统的可靠性，可维护性和适应性是密不可分的。当系统出现故障和用户出现错误的操作后是否支持恢复，当用户在使用过程中遇到错误的时候是否可以立即定位问题，但业务场景和逻辑发生变化的时候系统是否支持，当网络不稳定或使用中异常中断的情况下系统是否都有相应的容错措施，这些都是需要在非功能性需求中考虑到的问题。

易用性也是我们在开发非功能性需求中必须要考虑到的问题，易用性同时还涉及到美工和UI界面，人机工程，交互式设计，心理学，用户行为模式等多方面的知识。易用性的三原则就是易见，易学和易用或者叫为发现，易懂，效率。易见就是各种功能操作不要藏得太深，用户很容易找到他们期望进行的各种操作；易学需要软件系统通过在线帮助，导航，向导等各种方式保证软件是可自学习的；易用的重点则在软件在熟练使用后应该可以更快的进行各项操作。这三者相互间也存在冲突，需要平衡，而平衡的一个重点就是真正的做到以用户为中心进行设计，需要去细分场景和用户。

对于非功能性需求的描述，在描述过程中必须要强调到人，业务场景，环境等各方面的内容。强调的目的就是要说明非功能性需求不是无限度的，任何一项非功能性需求的实现往往会付出更大的研发人力成本和硬件网络成本。比如我们在描述一个表单的模糊查询功能的时候，如果简单的描述为所有查询都要在多少秒内完成，那么这种需求将很难得到满足，以下是一些可选的描述方式。

1.估计用户数为1万人，每天登录用户数为3000左右，网络的带宽为100M带宽。

2.在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。

3.当通过互联网接入系统的时候，期望在编号和名称搜索时最长查询时间<15秒。

二、非功能性需求包括哪4种类型

(1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。

(2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。

(3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。

(4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求。

扩展资料

非功能性需求是随着软件系统的规模成长和复杂性增加这两个因素才逐渐成为软件工程师们的新着眼点和关注点的，早期的时候，甲方处于自身对软件技术的了解和自身对系统文件维护的方便性考虑等，对系统有了诸如：开发平台、技术流派、关键实现等等方面的要求，这被称之为“设计约束”。

从甲乙双方合同的角度，设计约束也是一种需求——一种“非功能”性的需求，后来，软件的质量问题越来越突出，描述软件质量目标的要求也成为非功能性需求的一部分。于是，目前业界关于软件的非功能需求，一般就包括：质量属性要求和约束性要求。

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

翻译自 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测试可能会增加大量技术债务或更糟糕的系统故障的风险。

四、非功能性需求都包括哪些方面?

1�0�2�0�2�0�2 非功能性需求：用户对软件质量属性、运行环境、资源约束、外部接口等方面的要求或期望，包括：

(1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。

(2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。

(3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。

(4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求。

(4) 运行环境约束：用户对软件系统运行环境的要求。

(5) 外部接口：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。

五、软件开发中的 系统非功能需求 是什么？

非功能性需求，指的是信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素。一般不会在用户的业务需求中进行明确的提出，需要分析人员根据实际业务需要进行调研归纳。

例如税务业务系统的非功能性需求，可以从以下几个方面进行分析。

一：性能方面：

1。响应时间：分日常交互类、日常查询类、批量交易分别考虑。

日常交易指传统的大厅交互业务，如纳税申报、发票销售等，以及一次完成多笔业务处理的交易，如批量扣款等，日常交互类业务具有较高的响应要求。 查询类业务如登记资料查询、申报数据查询等。查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，给出一个参考范围。

批处理业务如会计核算等业务处理，该类业务处理复杂、操作数据量大、处理时间长。

响应时间指标包括：平均响应时间参考值(秒)、峰值响应时间参考值（秒）。

2。用户数：用户数要考虑用户数的增长情况，有以下指标：总用户数、峰值在线用户数、峰值并发用户数、平均在线用户数、平均并发用户数。

3。吞吐量：系统交易量的估算。指标有年交易笔数（笔/年）、高峰期交易笔数（笔/天）。

4。数据存储量：每年的数据存储容量（G）及未来几年该数量的预期（增长）值。指标包括累计存储容量（G）、年增长（G）。

二、系统可靠性：一般是窗口业务应在从星期一到星期五的所有工作日的工作时间是可以使用的；其它业务应满足7×24小时可以使用；

三、可扩展性：可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。

六、什么是功能性需求和非功能性需求

(1) 在一般使用中，需求按照功能性（行为的）和非功能性（其它所有的行为）来分类。

功能性需求是说有具体的完成内容的需求。

例如：比如客户登录、邮箱网站的收发收发邮件、论坛网站的发帖留言等。

非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。

例如：性能要求：要求系统能满足100个人同时使用，页面反应时间不能超过6秒；

　可靠性： 系统能7×24小时连续运行，年非计划宕机时间不能高于8小时。要求能快速的部署，特别是在系统出现故障时，能够快速的切换到备用机。

(2) 在统一过程（UP）中，需求按照“FURPS+”模型进行分类。

功能性（Functional）：特性、功能、安全性；

可用性（Usability）：人性化因素、帮助、文档；

可靠性（Reliability）：故障频率、可恢复性、可预测性；

性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率；

可支持性（Supportability）：适应性、可维护性、国际化、可配置性。

“FURPS+”中的“+”是指一些辅助性的和次要的因素，比如：

实现（Implementation）：资源限制、语言和工具、硬件等；

接口（Interface）；强加于外部系统接口之上的约束；

操作（Operation）：对其操作设置的系统管理；

包装（Packaging）例如物理的包装盒；

授权（Legal）：许可证或其他方式。

使用“FURPS+”分类方案（或其他分类方案）作为需求范围的检查列表是有效的，可以避免遗漏系统某些重要方面。

其中某些需求可以统称为质量属性（quality attribute）、质量需求（quality requirement）或系统的“某属性”。这些需求包括：可用性、可靠性、性能和可支持性