如何定义有效的非功能需求？

非功能需求经常被遗忘，但是要想使得客户/最终用户感觉到他们享受的服务很好，使得服务可以正常工作的话，这些需求却是非常重要的。如果服务有很多功能，但是界面非常难以使用，甚至根本没法使用，以至于最终用户不想使用此服务或者去使用竞争对手提供的服务，那么这个服务就没有任何用处了。或者，搞不好是你的服务有很多特性，但是客户需要等待很长时间才能开通服务，或者你的系统响应时间很长。非功能需求是指你的服务是怎样交付给客户/最终用户的，而不是指交付给用户什么东西（那是功能需求）。如果没有非功能需求，你的服务就会没有任何用处！通常，正是非功能需求使得你的服务和你竞争对手的服务有所不同，尤其是现在服务供应商提供的功能特性变得非常相似。以响应时间为例，如果你的服务响应时间比客户想要的长（如会话建立时间或呼叫建立时间），那么感觉就是你的服务质量很差，客户将会去寻找其他的供应商。

编写准确的、可测试的非功能需求经常是困难的。有很多因素和参数要考虑，很难定义有意义的数字化的度量值。还是以响应时间为例，如果你说对于宽带最终用户会话，其会话建立的响应时间是0.5s，那么需要100%的是这个值吗？对于响应时间来说，所考虑的负载情况是什么？可以接受的较低的响应时间极限是多少？一个解决这个问题的方法就是陈述目标数字并期望在一定百分比（如80%）下达到这个值。

试图达到某个非功能需求（如性能需求）可能会非常昂贵，以至于很容易贵的超出收益。以响应时间为例，0.5s的成本可能是每最终用户$10，而1s响应时间可能成本是每最终用户$2。因此，在定义非功能需求时，经常想到潜在的成本是非常值得的。不现实的非功能需求也是应该避免的。

非功能需求还非常难以度量和测试。建立一个测试环境去测试非功能需求，可能是非常昂贵的。因此，定义非功能需求时应确保预先获得了测试成本，作为业务用例的一部分。非功能需求被分为如下几个方面：

● 性能（performance）。从服务观点上看，主要是指在特定负载下，系统的响应时间或呼叫/会话建立时间；服务提供的速度；随着网络和系统的负载和资源利用率的变化，服务质量的下降会有多少。这些需求指出了整个端到端服务的需要，这是客户/最终用户的体验。指出特定系统的响应时间一般不太有用，除非某个功能只跟这一个系统相关。指定有意义的服务性能需求并不那么容易。性能需求还应该包括：当服务接近最大负载时，服务的行为是什么样的。

● 可用性（availability）。它是指服务可用的时间百分比（即什么时候可以使用服务）。服务可用性既包含网络可用性又包含系统可用性。有计划地停止服务，一般不算在可用性指标之内。

● 健壮性（Robustness）和错误比率（error rate）。定义了服务是否容易被破坏，以及错误发生的频度。这经常跟服务的负载相关（例如，在最终用户/客户体验到服务质量下降时的系统负载是怎样的）。服务的可用性，受“实现健壮性需求的能力”所影响。(www.xing528.com)

● 易用性（Usability）。这些需求是关于“最终用户/客户”跟“服务的不同功能/特性”之间的交互的。这些交互可能是通过网络终端设备（如移动电话）或通过门户网站（如通过Internet访问服务绩效报告）发生的。这些需求可以被翻译成GUI需求。易用性需求可以通过使用下面的参数来定义：用户可以学会使用服务的速度、客户/最终用户需要什么文档和培训材料、在线帮助需求、遵循的标准。

● 吞吐率（throughput）。它是指数据流过网络或系统的速率。吞吐率也可以是性能需求的一部分，但是，在电信服务领域，吞吐率需求最好单独列出来；因为服务比较复杂，而不同功能和特性可能需要不同的吞吐率。吞吐率需求决定了网络设备和系统的处理能力需求。在设计服务时，应该尽量避免产生“限制服务吞吐率的瓶颈”。

● 可维护性（Maintainability）和可升级性（upgradeability）。这些需求定义了维护和升级服务的简单性。你应该把如下内容定义为需求：当升级网络或系统时，是否可以接受服务暂时不可用；客户/最终用户终端设备上的不同软件版本之间是否需要向后（backward）兼容。如果服务暂时不可用是可以接受的，那么就应该指出可以接受的服务不可用时间长度是多少，以及可以接受的服务不可用时间窗是多少（例如，计划的服务不可用时间可以发生在工作日的上午1点至5点之间，每次服务不可用应该小于2小时）？如果需要向后兼容，那么你需要指出本服务的当前版本后的多少个版本内可以支持向后兼容。

● 恢复（recovery）和数据完整性（data integrity）。这些需求指出了：当系统/设备故障时，恢复和数据完整性的需求。还包括备份需求。平均恢复时间（Mean Time To Recover，MTTR）指标经常被用来描述这些需求。

● 错误（error）和异常处理（exception handling）。这些需求定义了在错误情况（under error conditions）下，服务的行为是什么，以及最终用户/客户受到的最大影响是什么。异常怎样被处理，也应该在需求中进行陈述。

安全性有时被划分到非功能需求中。下面的一些问题，有助于引发你对非功能需求的思考。