非功能性需求重要性

非功能性需求往往影响整个系统用户体验，在资源、时间有限的情况下，有限完成功能性需求，很多情况下是优先功能性需求，从而忽略了非功能性需求，这样导致后面软件稳定性差、扩展困难等问题，比如我查询一个数据要等1分钟（性能），系统三天两头宕机（稳定性），用户要增加一个简单的功能都需要程序员改很多东西，往往加班加点好几天拿不出来（可扩展性）等等，估计所有的用户都会砸桌子，这样往往会得不偿失。

另外，非功能性需求需要在设计过程中在软件开发后期或者软件交付后调整困难，经常涉及颠覆性改动，改造成本大，增加软件开发风险。

例如之前遇到过用户有EOS统一框架的要求，因为没有采用相应的框架，最后导致整个系统重新开发，浪费大量的人力物力。

三、非功能性需求特点

1、可变性

非功能性需求并不是一成不变的，而是随着环境、行业等情况有所变化。

2、易忽视

功能性需求是客户最看重的，也是测试和度量的最主要方向，也是技术设计和开发部门的工作量的考核依据。用户往往是从能看到的东西来衡量，很多非功能需求都是不可见的，例如安全性、可移植性、可扩展性等等，这些方面往往会被用户所忽视。

非功能性需求经常被忽略，因为它们不易被发现，发现后不易表达、实现以及测试。

3、衡量困难或不可衡量

非功能性需求管理的几个难点在于，他们难以度量，很多时候难于计算工作量，从而纳入考核体系。虽然理论上可以通过一些用来指定非功能性系统特性的度量的测试可使其验证更为客观，但在实际过程中，对需求描述进行量化是很困难的。这种困难性体现为客户没有能力把目标需求进行量化的同时，有些目标（如可维护性）本身也没有度量可供使用。例如功能响应时间、最大并发量、资源利用率等，要进行衡量，需要较深的技术能力；界面等感官多于客观的内容也很难对其进行衡量。

4、投入成本高

大部分的非功能性需求投入资源较高，且成果并非功能需求那样显而易见，不容易让用户所认可。例如一套软件预算为80w，其中40w用于实现功能性需求，40w用于优化非功能性需求，一般的用户很难采纳这种方案。

四、非功能性需求内容

软件非功能性需求包含多个方面，有不同的分类方式，ISO9126-1质量模型标准中，将质量属性分了（功能性、可靠性、易用性、效率、维护性、可移植性）6大类以及27个小类，这里参考《软件架构的非功能性需求指标和区域化支持》（张宏升）的分类方式，将非功能性需求的常见指标分为观感需求（界面需求）、安全性需求、系统的完整性需求、易用性需求与可执行需求、系统的可扩充性与可维护性几个方面进行描述。

1、观感需求（界面需求） 主要描述了对产品外观的期望、情绪和风格。这些需求规定了外观想要达到的目标，它和详细的界面设计还是有区别的，体现的是客户的感觉。界面需求还包括对控件进行规范和对控件的使用范围进行一个规定等方面的内容。可以考虑借用一个原型来描述。

风格需要和局内其他系统风格保持一致； 地图模块工具栏布局以及常用界面布局和现有系统保持一致； 用户确认以及用户提示，方式保持统一； 界面布局方便用户操作；

2、易用性需求与可执行需求

易用性会使产品提高符合用户习惯的能力以及其对使用的期望。它会对用户使用产品的生产效率、错误率以及用户对新产品的接收程度产生很大的影响。

可执行需求是指产品可以在给定的时间或者特定的精确度来执行某些任务，或者在一段时间内的极端状态值。在考虑执行需求时，可以从完成任务的速度、结果的精确度、容量、允许值的范围、单位时间内完成的任务数、资源的使用效率、两次故障间的平均无故障时间、连续不停机时间等方面入手。它还应该包括对风险的控制内容。

业务审批时候，常用语设置； 对于错误情况应该有较为友好的提示，防止系统崩溃、卡死情况的发生； 增加表单关联，避免重复输入等问题； 使用的词语、标签含义明确，易于理解； 本地化以及国际化需求； 等待过程增加进度条等提示； 系统响应时间要在可空范围内（一般1s以内）； 浏览器打开模式（新的tab页面还是原有页面打开）； 数据小数位数以及计算精度要求； 数据时效性要求； 长时间执行操作后台任务执行； 运行稳定，发生故障要在指定时间内恢复； 用户是否要求不间断运行？是否集群部署，保证可用性； 系统并发量要求； 服务器资源估算，磁盘、cpu、内存的初始需求以及增长量等；

3、安全性需求

安全性指产品消除潜在风险的能力和对风险的承受能力。包含、保密性、可靠性和完整性三个子特性。保密性指的是数据不能被授权用户以外的任何人访问的能力。可靠性指的是授权用户可以不受阻止的访问数据、与其它软件的兼容的能力和产品的强壮度。完整性指的是安预期目标完成任务的能力。

一般分为程序安全、系统安全、数据安全。程序安全是指开发的程序是否是安全的，程序上有没有安全的漏洞，例如Web开发中服务器代码没有对输入的参数进行验证，从而导致客户端机器人轻易的获取数据。系统安全指的是系统整体的安全，例如安全的粒度，未经授权的用户是否可以轻易的访问非法的数据等。数据的安全是对数据的保护，数据库中数据有没有做审核，用户之间是否会共享数据等。

用户体系，是否与已有的门户系统集成；密码策略可以参考门户； 满足等保测评三级要求，web漏洞、渗透测试漏洞、服务器扫描漏洞； 是否有文件存储，文件存储大小，是否需要分离存储。现场对于大容量文件统一要求采用分布式文件系统存储。 容灾备份以及应急预案； 数据存储安全，配置文件加密； 数据备份； 网络环境（业务内网、政务外网、互联网）； 多网络环境数据交换机制； 文件上传控制，大小、格式等校验；

4、系统的完整性需求

指为完成业务需求和系统正常运行本身要求而必须具有的功能，这些功能往往是用户不能提出的。典型的功能有：联机帮助、数据管理、用户管理、软件发布管理、在线升级，等等。

并不是所有的系统都必须包括以上所有的功能，而是可以根据产品的使用环境和企业的产品发展决策进行挑选。因此，完整的系统应该包括数据备份、恢复、日志管理、垃圾数据清除等基本功能，哪怕这些功能的核心只是一条语句或命令。用户管理功能是另一项必不可少的功能，它定义哪些用户可以以什么样的功能使用系统。好的用户管理功能不仅可以有效控制用户对系统的使用，使系统处于一个安全、负载合理的运行状况，还能提高系统的应用适应性。

升级管理； 帮助手册； 日志、字典、用户等管理；

5、系统的可扩充性与可维护性

这里指的是当系统达到瓶颈的时候怎样在不修改代码的情况下提供系统的负载能力，扩展一般分为Scale UP和Scale Out。一般情况下会综合运用UP和OUT。例如，增加服务器的性能来提高系统的处理能力，但是任何计算机都会有一定的瓶颈，当增加服务器性能不能达到提高系统性能的时候，我们需要考虑横向的扩展服务器，也即Scale Out。在Scale Out时一般需要我们的系统是状态无关的，即Stateless。

当技术变化或业务变化时，不可避免将带来系统的改变——不仅要进行设计实现的修改，甚至要进行产品定义的修改。好的软件设计应在系统构架上考虑能以尽量少的代价适应这种变化。常用的技术方法有面向对象的分析与设计以及设计模式。

考虑软件生命周期内的扩展； 模块化、松耦合、可复用； 用户操作环境要求（操作系统、浏览器、分辨率等），例如麒麟操作系统，浏览器版本等； 热更新，是否可以通过集群实现不间断业务更新； 版本管理； 代码规范、数据库规范、服务规范 开发平台：如无特殊要求，流程的采用普元平台，其他的可以采用数据中心框架； 软件要求：采用相同版本软件，ArcGIS10.1 Oracle11.2.0.4 PostgreSQL11 Tomcat8 ； 操作系统：Windows Server2008 R2，Centos7.6 网络要求、宽带要求、不同网络数据交换要求；

通过认识以上非功能性需求的常见指标，非功能需求的重要性主要程度要看项目具体情况而定，比如对于一个嵌入式系统软件运行开销非常重要，如果是实时系统，响应时间就很关键，如果是联机交易系统可靠性、安全性、性能都很重要。

五、非功能性需求获取

1、直接提供，用户直接提出要求（可能性较低）或者可以从招投标文件或者合同中获取，例如很多项目招投标中都对响应时间、软硬件平台等有所要求。

2、提问式（对话式）获取，架构师以软件系统各方面的质量属性为索引，系统的启发用户，获取具体需求。例如可以通过获取系统使用人数、使用频率、主要使用时间段等来初步判断并发量以及资源情况。

3、自行分析，提前发现可能存在或者发生的事宜并纳入考虑。例如后续是否有迁移的需要，可能需要与那些网络环境的那些外部系统进行对接等。

对于非功能性的需求，收集起来不是很容易的，如果你问人们是否需要一个东西的时候，他们的回答无疑都会是 “是的” 这就会导致最后划分优先级的时候 每件事情都变得不可或缺，因为客户回答都是 是的。这时候就需要换一种方法 我们可以提出完成这件事情所需的成本等因素来影响用户的单一选择。

六、参考

http://www.woshipm.com/pmd/3391140.html 常见的非功能性需求和应对方式

https://www.yuque.com/eureka/pm/no5b6t 非功能性需求

https://www.jianshu.com/p/423ad251a520?from=groupmessage 性能分析

https://blog.csdn.net/u012760183/article/details/51660393 软件设计--质量属性（非功能性需求）