软件设计——质量属性(非功能性需求)

当你在收集需求的时候 人们会很乐意给你一个愿望清单，写满了他们想要软件系统所完成的事，也有完善的方法以用户故事、用例、传统的需求规格书、验收标准等形式来捕捉这些功能需求 但是那些讨厌的非功能性需求呢？？

什么是非功能性需求？

非功能性需求通常被看做是能力，主要跟服务质量有关，也就是一个软件的质量属性，下面大致介绍下 常见的非功能性需求：

1.性能
性能也就是一个东西有多快 通常指响应时间或延迟
响应时间—>从发出请求道收到响应所用的时间
延迟—>消息从A到B通过你的系统所用的时间

2.可伸缩性
可伸缩性基本上就是软件处理更多用户。请求、数据、消息的能力 可伸缩性和并发机制密不可分，因此能在相同的时间内处理更多的东西

3.可用性
可用性是软件对服务请求的可操作性和可见程度 也就是软件可用的时间 通常用“9”来衡量，比如说 99.9% 表示正常运行时间的百分比，意味着留给计划维护、升级和故障处理的时间每天只有那0.1%的时间

4.安全性
安全性涵盖了软件运行中的所有地方，和性能一样，在一定程度上它对你很重要。对于部署到互联网上的程序，安全性很重要，也是很基础的东西

5.灾难恢复
对于发生故障的时候比如你的硬盘、服务器、数据库损坏了，如何还能保证程序正常运行，如果你的软件系统至关重要，经常会听到人们讨论它在发生灾难的时候应该如何做才能保证软件的持续运行

6.可访问性
指的是如何让一些能力有限的人 比如 残疾人 也能使用你的软件，因为网络可以提供平等的机会给每一个人，应该让每一个人都能享受到我们软件的便捷

7.监测
有些组织对于如何监测软件系统才能确保它们正常运行有特定的需求，这就需要提供监测的功能了。。。

8.管理
提供给用户可管理的能力、、

9.审计
特别是在涉及到重要数据的时候 比如钱的时候 需要对引起数据变化的原因进行审计，记录变动产生的对象 原因 时间 等等

10.灵活性
指软件处理多个任务，以不同方式执行单个任务的灵活性 也就是说可以灵活的更改处理这一任务的方式。。

11.可扩展性
指的是否可以更好的扩展软件系统的功能

12.可维护性
后期维护的难易

13.法律法规
有些行业需要遵守一定的法律法规，比如有时候需要根据法律来保留审计日志等信息

14.国际化
当一个软件需要走向国际的时候，就需要考虑国际化的问题，语言的不同，习惯的不同，比如 有些语言是从右向左写的。。

15.本地化
指以符合最终用户的文化习俗的方式来展示货币数字日期等信息

对于上述的这些非功能性需求，不同的软件系统对于不同的非功能性需求有不同的需要，我们需要根据自己软件的情况，来确定非功能性需求

处理非功能性需求

对于功能需求 用户往往会给你一份清单或者文档，可是对于非功能性需求，通常不是那么明确的，这时候如果你忽视这些非功能性需求，在软件系统完成之后，用户就会感觉你的软件系统与他预想的系统有所差别，不管是性能上还是功能上，这就导致了尴尬悲剧的局面。。。
因此我们需要在软件开发前来花费一定的时间来处理确定这些非功能性需求

1.捕捉
在软件开发过程中，客户明确给出非功能性需求的情况通常很少，在大量的需求规格书中也很少提到有关性能、伸缩性、安全性的信息，所以我们就得主动的去捕捉它们。
但是这是一件不太好办的是 因为如果你去问一个业务人员，你的系统要达到哪种级别的性能，他通常会回答100% 最快 最好 之类的答案，这是完全没有意义的回答。。。

2.提炼
如果你有幸已经获得一些有关非功能性需求的信息，那么你就需要提炼了
比如 如果你收到了 一份文档 里面讲述了少许的非功能性需求，你就可以根据这些需求展开讨论了 当然 与客户讨论的时候不能问那种 你要多少安全性 这种类似的问题，客户即使回答了 答案也是没有意义的 你要根据交流对象变换问题
比如如果客户的 需求上 写到 ”性能必须要快 “ 这个需求显然不是很有用 但是我们可以根据这个与客户进行讨论，在讨论的过程中 你可以问 “你能忍受的系统停机时间是多少” “你希望你的系统最慢在多久内响应” 之类的问题 而不要问。。 你要什么级别的性能、、

针对和客户讨论的问题 还有如下例子可以参考 ：
如果系统在朝九晚六的正常工作时间内出现故障 会发生什么？(可用性 判断系统需要什么时候可用)
如果系统核心在正常工作之外出现故障，会发生什么？ (同上)

系统平均应该支持多少并发用户？高峰时段呢？(可伸缩性)

多长的响应时间是可以接受的？ (性能)
为了保护系统安全 我们应该做什么 需要对数据加密码 需要访问权限吗？ (安全性)

挑战

对于非功能性的需求，收集起来不是很容易的
记住一点，如果你问人们是否需要一个东西的时候，他们的回答无疑都会是 “是的” 这就会导致最后划分优先级的时候 每件事情都变得不可或缺 因为客户回答都是 是的。。

这时候就需要换一种方法 我们可以提出完成这件事情所需的成本 影响用户的单一选择
比如下面例子 ：
架构师： 你需要一个正常运行时间是 100%的系统 构建这个系统 需要大量的冗余来消除每一个故障点，我们所有的花费都会加倍 这个成本大约需要100万美元，或者我们可以给你提供一个相对简单点的系统，但是发生故障时 你可以通过手动重启来消除故障，这个成本大约是10万美元 ，您看一下 您需要哪一种呢？

担保人： 哦 如果是这样 我要便宜一点的方案吧

我们可以通过上述的方式 来明确需求 不同的做法有不同的代价，我们也不能做代价与利益不相符的事情不是？ 客户也是一样 所以 解释那些代价有助于找到客户和我们所需要的最适合的方案 。