在软件工程中，非功能性需求（nonfunctional requirements，简称NFRs）与软件架构（software architectures，简称SAs）之间存在着紧密联系。早在1994年，Rick Kazman和Len Bass肯定地说过，软件架构与实现非功能性需求之间存在密切联系。这一想法在软件开发领域已经流行很多年，它也解释了为什么开发项目要在实现非功能性需求方面做大量投入。
　　当我们认识到软件架构的概念如何从简单的结构性表示演变为决策视角时，这个笼统的观点显得更加具体了。 从决策角度来看，非功能性需求是对各种设计方案进行选择的标准。4 例如，从可维护性或可移植性方面考量，需要一种层次性架构风格；从效率方面考量，需要一种专门的数据库技术。
　　软件架构师在执行软件架构设计任务时，必须连续不断地应对非功能性需求。他们必须了解系统有哪些非功能性需求，以及架构决策对实现这些非功能性需求的影响。 在本文中，我们将介绍一项实证研究，它揭示了软件架构师们在决策过程中应对非功能性需求的有关实践。这项研究以一个调研活动为基础，该调研活动由两部分组 成。首先，我们从工程角度对非功能性需求加以分析，尤其是与三类需求工程活动（获取、文档化和验证）的关系。然后，我们深入研究了非功能性需求是如何影响 架构决策的。
　　调研
　　我们针对同一个软件项目，多次组织了半结构化访谈（semi-structured interviews），访谈的对象都是参与过该项目的软件架构师。相对其他定性研究策略（如结构化问卷调查）而言，半结构化访谈更具灵活性，它使我们可 以更好地研究对话中出现的相关问题。另外，我们把讨论范围限定在单个软件项目以内，而不是考虑一般性的架构原则，这有助于我们更好地理解与评估背景信息。
　　访谈对象及所在机构
　　本调研涉及13位访谈对象，他们来自12家跨越不同业务与应用领域的软件密集型机构（见表1）。根据业务种类不同，这些机构可分为三类：
　　软件咨询公司，主要是为客户从事软件开发任务。
　　IT部门，为满足机构内部需求而从事或外包软件开发任务。
　　软件供应商，开发特定私有方案，并将其商品化。
　　本调研涉及的软件项目，其功能与大小也有差别。
　　尽管所有访谈对象都在各自项目中履行架构师职责，但他们的所在机构并没有专门设置软件架构师职位。相反，机构是根据技术知识或经验来为各个项目选择架构师的。除去一个例外，其他所有访谈对象都同时还兼任其他角色（如项目经理、顾问或开发者）。


　　访谈实施
　　我 们为访谈制作了一个访谈指南，并通过两位研究者和两位软件架构师对它进行了测试，以确保有效。然后，我们把访谈指南预先发送给所有访谈对象，让他们有机会 熟悉访谈话题，并挑选一个用于访谈的项目。访谈是面对面进行的，每次访谈大约一小时。我们对访谈进行了录音，然后将它们转录为文本，以便进行分析。而后， 我们请访谈对象来验证转录内容。有时，我们会明确请求访谈对象澄清某些方面。我们使用了NVivo软件来评估收集到的数据。我们对所有语句和词语进行了归类，把描述相同想法、动作或属性的语句和词语归为一组。后，我们根据机构和项目的特征来分析了数据。
　　局限性
　　我们了解我们的样本不是随机的，因此未必能够代表更广泛的软件开发全体。所以，为了试图缓解可能存在的偏差，我们让机构自己挑选访谈对象，并允许访谈对象自 己挑选项目。我们承认，访谈对象可能会倾向于选择较为成功的项目。为了缓和这一问题，我们向访谈对象说明，该项研究不用于分析佳实践，只是想了解做事方 式。我们承诺为反馈内容保密。大部分机构是中小型机构，而且都来自西班牙。当然，调研结果可能受到上述因素的影响。此外，大部分都不是紧要领域的项目。不 过，由于我们试图通过这些项目来揭示工业界实践，而不是提出一般性理论，所以这不算重大弱点。
　　架构师如何应对非功能性需求
　　我们向软件架构师们提出了好几个具体的问题，关于他们如何获取并文档化非功能性需求，以及之后如何在系统中进行验证。我们认为，这对理解架构师在项目中进行决策制定的背景十分重要。关于这部分的详情，请参见我们的另一篇文章6。问题列表见下。由于我们实施的是半结构化访谈，因此这些问题只是作为指导，访谈是依据对话情况来推动的。关于需求获取、文档化和验证方面的话题自然而然地在对话中出现。
　　获取非功能性需求，由谁负责？
　　需求获取的目的是从涉众等处得到系统需求，并细化之。研究者和实践者都认同需求获取是需求工程中具挑战的部分。致力于精确无歧义表达需求的技术有很多，如调研、创意研讨会等。
　　这些技术假定来自客户方面的涉众（终用户、经理等）在需求获取方面将贡献很多。功能性需求而言，一些访谈对象认同该假定。例如，访谈对象A说：“[业务分析师]编写一个详细的文档来反映所有[功能性]需求”。?
　　但是，该假定对非功能性需求来说并不成立。在我们的调研中，有10个项目，软件架构师是非功能性需求的主要来源。有些客户从未提到非功能性需求。访谈对象E 说：“[客户]从没提到过网页加载时间不能超过2秒这样的需求，但他后来却对此颇有抱怨。”访谈对象L2说：“客户提到一个基本的[非功能性需求]，然后 我们根据自己的经验作了补充”。”
　　这一数值已经超过了Uwe van Heesch和Paris Avgeriou提到的架构师显著涉及需求获取的比例（60%）。7
　　只有访谈对象D、H、I的所在机构是由客户来领导非功能性需求获取的。有趣的是，也只有这几个机构的项目是外包的（管理方分别是一家航空工业公司、一家软件 公司和一家银行）。这一情况是由机构之间的从属关系造成的。然而，即便在这些案例中，架构师仍然在定义非功能性需求方面发挥着积极作用。访谈对象D说： “我们的客户是一个航空系统部门，所以所有非功能性需求都是良好定义的。另外，我们需要基于我们的经验再补充一些非功能性需求。?”