1.非功能性需求都包括哪些方面

非功能性需求，指的是信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素。

一般不会在用户的业务需求中进行明确的提出，需要分析人员根据实际业务需要进行调研归纳。 例如税务业务系统的非功能性需求，可以从以下几个方面进行分析。

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

日常交易指传统的大厅交互业务，如纳税申报、发票销售等，以及一次完成多笔业务处理的交易，如批量扣款等，日常交互类业务具有较高的响应要求。 查询类业务如登记资料查询、申报数据查询等。

查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，给出一个参考范围。 批处理业务如会计核算等业务处理，该类业务处理复杂、操作数据量大、处理时间长。

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

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

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

4。数据存储量：每年的数据存储容量（G）及未来几年该数量的预期（增长）值。

指标包括累计存储容量（G）、年增长（G）。 二、系统可靠性：一般是窗口业务应在从星期一到星期五的所有工作日的工作时间是可以使用的；其它业务应满足7*24小时可以使用； 三、可扩展性：可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。

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

下面对其中的某些指标加以说明。在这里可以看到非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。

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

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

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

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

易用性也是我们在开发非功能性需求中必须要考虑到的问题，易用性同时还涉及到美工和UI界面，人机工程，交互式设计，心理学，用户行为模式等多方面的知识。易用性的三原则就是易见，易学和易用或者叫为发现，易懂，效率。

易见就是各种功能操作不要藏得太深，用户很容易找到他们期望进行的各种操作；易学需要软件系统通过在线帮助，导航，向导等各种方式保证软件是可自学习的；易用的重点则在软件在熟练使用后应该可以更快的进行各项操作。这三者相互间也存在冲突，需要平衡，而平衡的一个重点就是真正的做到以用户为中心进行设计，需要去细分场景和用户。

对于非功能性需求的描述，在描述过程中必须要强调到人，业务场景，环境等各方面的内容。强调的目的就是要说明非功能性需求不是无限度的，任何一项非功能性需求的实现往往会付出更大的研发人力成本和硬件网络成本。

比如我们在描述一个表单的模糊查询功能的时候，如果简单的描述为所有查询都要在多少秒内完成，那么这种需求将很难得到满足，以下是一些可选的描述方式。1.估计用户数为1万人，每天登录用户数为3000左右，网络的带宽为100M带宽。

2.在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。3.当通过互联网接入系统的时候，期望在编号和名称搜索时最长查询时间 评论0 0 0。

2.什么是功能性需求和非功能性需求

(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）或系统的“某属性”。这些需求包括：可用性、可靠性、性能和可支持性

3.非功能性需求都包括哪些方面

非功能性需求，指的是信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素。

一般不会在用户的业务需求中进行明确的提出，需要分析人员根据实际业务需要进行调研归纳。 例如税务业务系统的非功能性需求，可以从以下几个方面进行分析。

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

日常交易指传统的大厅交互业务，如纳税申报、发票销售等，以及一次完成多笔业务处理的交易，如批量扣款等，日常交互类业务具有较高的响应要求。 查询类业务如登记资料查询、申报数据查询等。

查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，给出一个参考范围。 批处理业务如会计核算等业务处理，该类业务处理复杂、操作数据量大、处理时间长。

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

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

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

4。数据存储量：每年的数据存储容量（G）及未来几年该数量的预期（增长）值。

指标包括累计存储容量（G）、年增长（G）。 二、系统可靠性：一般是窗口业务应在从星期一到星期五的所有工作日的工作时间是可以使用的；其它业务应满足7*24小时可以使用； 三、可扩展性：可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。

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

下面对其中的某些指标加以说明。在这里可以看到非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。

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

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

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

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

易用性也是我们在开发非功能性需求中必须要考虑到的问题，易用性同时还涉及到美工和UI界面，人机工程，交互式设计，心理学，用户行为模式等多方面的知识。易用性的三原则就是易见，易学和易用或者叫为发现，易懂，效率。

易见就是各种功能操作不要藏得太深，用户很容易找到他们期望进行的各种操作；易学需要软件系统通过在线帮助，导航，向导等各种方式保证软件是可自学习的；易用的重点则在软件在熟练使用后应该可以更快的进行各项操作。这三者相互间也存在冲突，需要平衡，而平衡的一个重点就是真正的做到以用户为中心进行设计，需要去细分场景和用户。

对于非功能性需求的描述，在描述过程中必须要强调到人，业务场景，环境等各方面的内容。强调的目的就是要说明非功能性需求不是无限度的，任何一项非功能性需求的实现往往会付出更大的研发人力成本和硬件网络成本。

比如我们在描述一个表单的模糊查询功能的时候，如果简单的描述为所有查询都要在多少秒内完成，那么这种需求将很难得到满足，以下是一些可选的描述方式。1.估计用户数为1万人，每天登录用户数为3000左右，网络的带宽为100M带宽。

2.在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。3.当通过互联网接入系统的时候，期望在编号和名称搜索时最长查询时间<15秒。

4.如何获取和分析非功能性需求

基于以上分析，本系统没有明显的质量属性冲突。

第三步：确定这些质量属性的优先级。 这个优先级是根据各个质量属性对系统的影响程度来定性判断的。

一般来讲，影响安全生产的要素要高优先级考虑，其次是影响企业经营的要素，最后考虑哪些支持性的要素。因此，该案例的软件质量优先级排序如下：1.安全性2.持续可用性3.易用性4.可维护性5.可扩展性、可移植性、可重用性、可测试性。

第四步：筛选关键的软件质量属性。 一个系统关键的软件质量属性和质量目标不可能太多，一般视系统的规模从2-5个不等。

因此，该案例的关键软件质量属性可以选择前三个：1.安全性2.持续可用性3.易用性。 （二）获取和分析软件约束的过程如下： 第一步，获取约束。

可以从以下4个方面获取软件约束。 （1）来自业务环境的约束，如：与其他系统集成、预算限制、上线时间紧等 （2）来自使用环境的约束，如：用户群特征（知识水平、语言能力、操作习惯等），系统运行环境（干扰、网络质量、移动性等） （3）来自构建（开发）环境的约束，如：开发人员的素质（技术水平、学习能力、）、团队分布等 （4）来自当前技术环境的约束，如：技术平台、中间件、编程语言等等。

第二步，分析约束，发现功能性需求和软件质量属性。 案例：某公司欲开发一个全球农产品C2C电子商务项目，主要功能是提供一个便捷、快速的交易流程。

投资5000万用于初期开发系统、运营和市场营销。先期估算买卖会员一年内可以到达20万，以后计划每年确保50%的会员增长率。

该系统拟采用支付宝和快钱进行第三方结算。目前这两家公司向其他客户提供Web服务接口。

承接方希望在年度内完成开发，因为他们下一年要被一家外资公司执行收购。 第一步，获取约束 业务环境存在哪些约束？投资方投资额限制、会员增长率、第三方系统集成要求 。

使用环境存在哪些约束？全球农民或农场主为系统的使用者，隐含一个设计约束：系统操作简单。有些农村地区网络质量差，带宽小。

构建环境存在哪些约束？系统开发商有对开发时间的限制。 技术环境存在哪些约束？可能以Web服务方式集成。

第二步，分析约束，发现功能性需求和软件质量属性。 直接的设计约束：以Web服务方式集成，开发周期，多语言版本等等。

可引出功能需求：“主要功能是提供一个便捷、快速的交易流程”，并且，全球农民或农场主为系统的使用者，这就要求系统能够进行产品快速搜索和产品比价。 可引出质量需求：“有些农村地区网络质量差，带宽小。”

在网络环境差的条件下保证系统的可用性等。

5.功能性需求和非功能性需求的区别

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

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

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

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

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

6.需求开发中的非功能需求包括哪些

非功能性需求

4-1、系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

4-2、业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

4-3、功能需求记录在软件需求规格说明（ SRS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。

4-4、质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

4-5、约束（constraint）限制了开发人员设计和构建系统时的选择范围，如局限于软件工程学科。 注：分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和非功能性需求对软件的开发有着重大的指导意义，绝不可以以偏概全，错误地去揣摩用户的心思；对于开发者而言，所有软件功能的开发我们都应该一一征求用户的意见，对需求有了清晰的认识后再进行实质性的开发工作。

7.如何获取和分析非功能性需求

基于以上分析，本系统没有明显的质量属性冲突。

第三步：确定这些质量属性的优先级。 这个优先级是根据各个质量属性对系统的影响程度来定性判断的。

一般来讲，影响安全生产的要素要高优先级考虑，其次是影响企业经营的要素，最后考虑哪些支持性的要素。因此，该案例的软件质量优先级排序如下：1.安全性2.持续可用性3.易用性4.可维护性5.可扩展性、可移植性、可重用性、可测试性。

第四步：筛选关键的软件质量属性。 一个系统关键的软件质量属性和质量目标不可能太多，一般视系统的规模从2-5个不等。

因此，该案例的关键软件质量属性可以选择前三个：1.安全性2.持续可用性3.易用性。 （二）获取和分析软件约束的过程如下： 第一步，获取约束。

可以从以下4个方面获取软件约束。 （1）来自业务环境的约束，如：与其他系统集成、预算限制、上线时间紧等 （2）来自使用环境的约束，如：用户群特征（知识水平、语言能力、操作习惯等），系统运行环境（干扰、网络质量、移动性等） （3）来自构建（开发）环境的约束，如：开发人员的素质（技术水平、学习能力、）、团队分布等 （4）来自当前技术环境的约束，如：技术平台、中间件、编程语言等等。

第二步，分析约束，发现功能性需求和软件质量属性。 案例：某公司欲开发一个全球农产品C2C电子商务项目，主要功能是提供一个便捷、快速的交易流程。

投资5000万用于初期开发系统、运营和市场营销。先期估算买卖会员一年内可以到达20万，以后计划每年确保50%的会员增长率。

该系统拟采用支付宝和快钱进行第三方结算。目前这两家公司向其他客户提供Web服务接口。

承接方希望在年度内完成开发，因为他们下一年要被一家外资公司执行收购。 第一步，获取约束 业务环境存在哪些约束？投资方投资额限制、会员增长率、第三方系统集成要求 。

使用环境存在哪些约束？全球农民或农场主为系统的使用者，隐含一个设计约束：系统操作简单。有些农村地区网络质量差，带宽小。

构建环境存在哪些约束？系统开发商有对开发时间的限制。 技术环境存在哪些约束？可能以Web服务方式集成。

第二步，分析约束，发现功能性需求和软件质量属性。 直接的设计约束：以Web服务方式集成，开发周期，多语言版本等等。

可引出功能需求：“主要功能是提供一个便捷、快速的交易流程”，并且，全球农民或农场主为系统的使用者，这就要求系统能够进行产品快速搜索和产品比价。 可引出质量需求：“有些农村地区网络质量差，带宽小。”

在网络环境差的条件下保证系统的可用性等。

8.为什么非功能性需求很重要

不要脱离实际环境

有时，我们会因为读到一篇文章或一本书，或者看到一个感觉不完善的介绍而变得异常偏执。在每种情况下，人们只讨论一些技术、解决方案和选项的某些方面，而忽视了一个至关重要的问题：非功能性需求。

诚然，功能性是非常重要的。毕竟，如果您不能展示您构建的系统实现了您想要的功能，那么谁会有兴趣呢？采取一种新颖、巧妙、更简单、更漂亮或更得体的方法来解决某种问题固然很好，但是如果您没有考虑非功能性需求，则您的解决方案可能无法取得实效。

非功能性需求是这样一种需求，它不一定解决“我想要我的系统实现这种功能”，而是解决“如何使这个系统能在实际环境中运行”。对于这些实际环境，您很少听到人们提及的一些问题是：MILY： 宋体； mso-bidi-font-size: 10.0pt; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">；◆

对在线系统的请求过多：用户太多了，全都在一块了！◆部署应用程序的管理员负担过大：在实际环境中，管理员对每个应用程序都将部署多次，而在部署之后必须对每一个应用程序进行监视。◆管理员会犯错误：毕竟，我们大多数都是普通人！虽然无差错地执行100 次手动部署步骤在理论上是可能的，但是实际环境中没有出现过。◆会有恼人的脚本小子 （script kiddy） 和真正的破解高手攻击我们的系统：安全是多么重要啊！

可靠性需要考虑的一些具体方面是：

可用性如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是：◆您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？◆系统是否根据模型-视图-控制器 （Model-View-Controller） 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？◆是否界面本来就有状态而功能无状态（反之亦然）？有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑：◆性能：这个系统的运行情况有多好？它只是平稳缓慢地运行吗？系统可以达到其响应时间目标吗？应用程序的设计是否符合性能要求？您利用缓存了吗？◆可伸缩性：如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？它的设计是否达到吞吐量目标？可以复制系统来实现线性扩展吗？是否存在瓶颈（例如公共数据库）？可维护性这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。假设您是一位管理员，您承担了解决此问题的任务，那么您如何配置它？如何监视它？如果您一件事情需要执行很多次（例如，安装许多应用程序），那么会怎么做呢？您是否有一个可复制的部署流程呢？您是否可以使重复的任务自动化，使之在大范围内可行呢？可移植性虽然列在最后，但它并非最不重要。例如，如何采用标准来提供某种形式的平台中立性呢？是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢？如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢？如果您的项目基于开放源代码，则也有类似的问题。如果每当某人有个更好的捕鼠器 （mousetrap） 您就必须重写整个应用程序，则没有人会问津。

在完美的世界中，我们希望每篇文章、论文、红皮书、幻灯片和系统设计都率先解决这些重要问题。它们非常重要。差不多始终都要进行一些折衷，它们应该显式进行以便确定特定的设计是否符合您的需要。如果您阅读的文章没有解决这些问题，将这作为我们的警告——一些重要的东西往往会被忽视。如果您是一位作者，请考虑我们的恳求：不要忽视这些问题！