如何获取非功能性需求？
非功能性需求难以捉摸的特性，决定了不容易事先获取。根据这条一般性的看法，所有访谈对象都认同非功能性需求的获取是一个迭代的过程，需要跨越整个系统生命 周期。因为在达到一定重要阶段（通常是原型）之前，可能不太容易对系统的部分行为提出期望。访谈对象J称：“我们首先确定一些相关的非功能性需求，比如与 其他系统的兼容性等，然后开发一个原型，并分析其他候选方案。”?
此外，我们无法在第一次开发之前把非功能性需求考虑完全。他们需要纠正性维护， 以纠正未符合预期的不正确行为。访谈对象K说，“在效率方面，我们必须作出改变，因为在项目开始之时并没有就服务水平提出要求。”?这样是合理的。有些非 功能性需求（例如安全性方面）只有在目标环境中部署系统或意外发生时，才能进行全面检查。
如何档案化非功能性需求？
为了让档案化更加有效，学术界与标准化组织已经提出了许多用于编写系统需求规格说明书的表示法和模版。然而，13位访谈对象中有9位承认他们不对非功能性需 求进行档案化。访谈对象H说：“[功能性需求]是用UML、概念模型、用例来表示的，但没听说过非功能性需求。”一些访谈对象说，只有当客户需要，或者项 目属于紧要领域时，才有必要档案化。有四位访谈对象表示他们明确记录非功能性需求。访谈对象D的所在机构采用一种领域特定语言（domain- specific language）。“因为我们为航空领域工作，我们必须以可验证的方式来明确表达非功能性需求。我们有专门的模版，我们采用来自其他工程领域的不同技术 （如风险模型、故障树等）。”两位访谈对象表示，他们采用具有一定结构的自然语言来记录非功能性需求。访谈对象B采用Volere需求模版（它提供了一个 高度结构化的需求模版）；访谈对象K采用符合ISO/IEC 9126质量模型的纯文本。
访谈对象J只采用纯文本文档。只有访谈对象B和 D是不断维护需求文档的；J和K只记录最初的非功能性需求。访谈对象K说：“起初，我们用自然语言记下一些关于非功能性需求的想法，... 不过之后，我们并没有跟踪它们，在设计过程中也没有出现新的非功能性需求。”人们似乎很自然地认为，可度量性与连续（或至少规律的）记录更新之间存在一定 关系。但要确认这种关系是否存在，需要做进一步研究。
所以我们可以看到，非功能性需求很多是不言而喻的，甚至是隐含的。把它们档案化，准 确性和及时性会受到严重损害。这种情况可以用成本和收益来解释。访谈对象C直率地说：“我几乎不对项目进行适当的档案化，主要是它耗费太多钱。”如果实践 者们无法从中感到益处，那么非功能性需求将继续保持难以捉摸的状态。
如何在系统中验证非功能性需求？
验证系统的行为 是否满足非功能性需求是有难度的。不同非功能性需求之间存在差异，因此相应的验证方法也有所不同。不过，有11位访谈对象说，所有非功能性需求都在项目中 得到了满足，尽管总有改进余地。然而，当我们问道如何针对非功能性需求进行验证时，他们的回答显得含糊。访谈对象D是这么说的：“对于一些[不是全部]非功能性需求，由于不容易测试，我们只是非正式地跟客户进行了讨论。“因此，我们有必要把自以为满足非功能性需求（正如访谈对象中的那11位（85%）所做 的）和真正的验证区分开来（访谈对象中有8位（61%）对某些类型的非功能性需求进行了验证）。（这与过去研究得出的60%是相称的。8）
八位访谈对象执行了一些非功能性需求的验证，不过仅限于一到三种。他们只考虑以下类型的非功能性需求。
性能效率。访谈对象H说：“我们通过负载和压力测试来进行性能评估。”?
正确性。访谈对象A说：“我们每编码一小时，就投入一小时来测试。”?
易用性。访谈对象K说：“我们制作了一个原型，确保客户对用户界面满意。”?
可靠性。访谈对象J说：“我们强行引入一些错误，看看系统会发生什么，会不会丢失数据等。”?
安全性，作为十分重要的一类非功能性需求，所有访谈对象都没有提到。访谈对象F描述了一个极端的不作验证的例子：“我们等客户来抱怨，他们会发现问题的。” 尽管这是个不令人满意的回复，但它再次反映了这点（和前面提到的档案化一样）：出于预算和时间上考虑，工程实践可能没法按照理想的方式进行。
与之形成鲜明对比的是，访谈对象D采用基于统计分析和模拟的形式化方法来检查系统的可靠性。当然，这是预料之中的，因为他们的项目涉及到航天工业中的信息系统，属于紧要领域。过去有研究发现，评估方法与评估目标有关。9 我们的发现与之不谋而合。
我们有一个可能与前人研究结果一致的发现，即档案化与验证之间的联系。如Andreas Borg及其同事所说的那样，“如果用不可度量的词语来表达需求，那么测试会很消耗时间，甚至根本无法测试。”10仅有两位访谈对象采用了可度量的方式来表达非功能性需求，这可能是验证水平整体较低的原因之一。
非功能性需求如何影响架构决策
毫无意外，所有访谈对象都认同：非功能性需求会影响他们的决策。但是他们的具体回答反映出了一些细微差别。
决策类型
非功能性需求影响着四类决策。
架构模式
对于给定类型的项目，大部分访谈对象会很自然地选择层次架构，尽管他们中有些人明确给出了决策理由。访谈对象J说：“我们采用层次架构，因为它允许以后变化。”?
实现策略
有些类型的需求可能需要具体的架构级策略。它可以是一般性的设计决策（比如访谈对象L1说“我们采用单点登录，以增强子系统的集成性”），也可以是有关个别组件的具体决策（比如访谈对象A说“我们为数据库表建立副本，因为访问时间过长”）。?
横向决策
有 些非功能性需求会影响到整体架构。访谈对象L1说，“我们更倾向于采用我们已经掌握的技术。”一个反复出现的问题是，第三方组件尤其是开源软件（open source software，OSS）的使用。访谈对象D说，“出于可维护性考虑，我们希望能够获得源代码，所以我们选择了开源软件方案。”?
技术平台
非功能性需求也许可以通过选择正确的数据库或中间件等来满足。在这种情况下，它们可能是影响整个系统的。访谈对象K说：“我们需要高可用性 （availability），而只有Oracle能够保证这一需求。”非功能性需求也可能是局部的。访谈对象H说：“有一个查询是直接通过 JDBC（Joint Database Connectivity）实现的，由于效率原因，所以没有采用Hibernate。”?
不同的决策制定过程
我 们在本次调研中发现了一个关于决策制定的特别方面，即技术决策与其他决策的交织。我们听到三种不同的反馈。有四位访谈对象表示，非技术性决策优先。访谈对 象C说：“架构师应该在之前设计好的逻辑结构上，选用合适的技术。”另外四位访谈对象说，重大技术决策优先，之后的决策应该与之配合。访谈对象H说：“客 户给我们设了一些限制，比如，架构必须基于开源软件（OSS）和Java。”而其他五位访谈对象认为，技术决策和其他决策是交叉并彼此影响的，可以看成是 一种架构设计层面上的局部双峰模型。11
影响程度
我们询问访谈对象在进行架构决策时会考虑哪些非功能性需求。我们以ISO/IEC 25000质量标准为统一框架，将他们的回答汇总如下。
明确性（Explicitness）
很明显，架构师们期望一定的非功能性需求，即便还没有将它们作为需求明确列出。访谈对象I说：“我不会考虑一个不安全的系统。”由于所采用技术与平台的当前 特性，这些不言而喻的非功能性需求经常浮现在架构师的脑海里。访谈对象E说：“我们不会去考虑文档的安全性，因为它是由SharePoint管理系统负责 的。”?
来源（Source）
有些需求直接来自开发团队或架构师。访谈对象B说：“未来要维护这个系统的人是我们， 所以，确保它的可维护性对我们来说是很重要的。”相对于来自客户的非功能性需求，这些来自开发团队的非功能性需求与架构决策过程更加接近，因为技术人员从 解决方案的角度去思考，而客户的思考角度是面向问题的。
非技术性（Nontechnicality）
非技术性的非功 能性需求（NFRs）指那些不与软件内在质量直接相关、而是与系统环境有关的的需求，比如许可证或成本等。12架构师要考虑这些基本因素；访谈对象们表 示，所有非功能性需求中有大约40%属于非技术性的。有时，他们会以最高优先级来考虑这些需求。访谈对象J称：“成本是第一位的，所有别的都得服从 它。”?
重要性（Importance）
我们询问访谈对象哪种类型的非功能性需求是最为重要的。许可证问题、易用 性、可靠性、性能效率，以及可维护性是被提到最多的。而只有两位访谈对象提到了可移植性。我们将该信息与访谈对象在面谈中提到的决策案例进行了交叉检查； 我们发现，性能效率和可维护性对决策的影响最大。
术语问题（Terminology issues）
在与访谈对象讨 论非功能性需求时，我们碰到一些术语上的问题。有些访谈对象请求对术语进行补充解释，比如“可用性（availability）”和“准确性 （accuracy）”。其他的访谈对象会在给定上下文中错误地使用术语，比如用“人体工学”来表达“易用性”。有些访谈对象甚至采用错误的定义，比如 “可维护性（maintainability）是十分重要的，因为我们不能对运转中的系统进行修改。”另一个常见的问题是混淆使用“性能 （performance）”与“效率（efficiency）”。ISO/IEC 25000将性能效率定义为“一定条件下相对于所用资源数量的性能”。?”13 该定义有助于我们解除混淆。
为了检查研究中的观察结果是否有效，我们与一些大型IT企业展开了一项新的研究。我们期望在文档化和验证上看到改善，并且有可能的话，在各种非功能性需求的重 视程度上有所变化。我们还想研究，如果把非功能性需求与架构决策之间的关系明确表达出来（比如，考虑了哪些权衡，放弃了哪些选择等等）的话，将对最终的系 统架构决策有何影响。关于本课题的相关研究，请见下方。
致谢
我们非常感谢参加本课题的参与者，感谢他们的时间和贡献。本课题获得西班牙项目TIN2010-19130-C02-01的资助。
本文由《IEEE Software》杂志首发，现在由InfoQ和IEEE Computer Society联合向您呈现。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters