英文原文：Non-functional Requirements in Architectural Decision Making

　　本文由《IEEE Software》雜志首發，現在由InfoQ和IEEE Computer Society聯合向您呈現。

　　在軟件工程中，非功能性需求（nonfunctional requirements，簡稱NFRs）與軟件架構（software architectures，簡稱SAs）之間存在著緊密聯系。早在1994年，Rick Kazman和Len Bass就肯定地說過，軟件架構與實現非功能性需求之間存在密切聯系。¹這一想法在軟件開發領域已經流行很多年，它也解釋了為什么開發項目要在實現非功能性需求方面做大量投入。²

　　當我們認識到軟件架構的概念如何從簡單的結構性表示演變為決策視角時，這個籠統的觀點就顯得更加具體了。 ³從決策角度來看，非功能性需求是對各種設計方案進行選擇的標準。⁴ 例如，從可維護性或可移植性方面考量，需要一種層次性架構風格；從效率方面考量，需要一種專門的數據庫技術。

　　軟件架構師在執行軟件架構設計任務時，必須連續不斷地應對非功能性需求。他們必須了解系統有哪些非功能性需求，以及架構決策對實現這些非功能性需求的影響。 在本文中，我們將介紹一項實證研究，它揭示了軟件架構師們在決策過程中應對非功能性需求的有關實踐。這項研究以一個調研活動為基礎，該調研活動由兩部分組 成。首先，我們從工程角度對非功能性需求加以分析，尤其是與三類需求工程活動（獲取、文檔化和驗證）的關系。然后，我們深入研究了非功能性需求是如何影響 架構決策的。

　　調研

　　我們針對同一個軟件項目，多次組織了半結構化訪談（semi-structured interviews），訪談的對象都是參與過該項目的軟件架構師。相對其他定性研究策略（如結構化問卷調查）而言，半結構化訪談更具靈活性，它使我們可 以更好地研究對話中出現的相關問題。另外，我們把討論范圍限定在單個軟件項目以內，而不是考慮一般性的架構原則，這有助于我們更好地理解與評估背景信息。⁵

　　訪談對象及所在機構

　　本調研涉及13位訪談對象，他們來自12家跨越不同業務與應用領域的軟件密集型機構（見表1）。根據業務種類不同，這些機構可分為三類：

• 軟件咨詢公司，主要是為客戶從事軟件開發任務。
• IT部門，為滿足機構內部需求而從事或外包軟件開發任務。
• 軟件供應商，開發特定私有方案，并將其商品化。

　　本調研涉及的軟件項目，其功能與大小也有差別。

　　盡管所有訪談對象都在各自項目中履行架構師職責，但他們的所在機構并沒有專門設置軟件架構師職位。相反，機構是根據技術知識或經驗來為各個項目選擇架構師的。除去一個例外，其他所有訪談對象都同時還兼任其他角色（如項目經理、顧問或開發者）。

　　訪談實施

　　我 們為訪談制作了一個訪談指南，并通過兩位研究者和兩位軟件架構師對它進行了測試，以確保有效。然后，我們把訪談指南預先發送給所有訪談對象，讓他們有機會 熟悉訪談話題，并挑選一個用于訪談的項目。訪談是面對面進行的，每次訪談大約一小時。我們對訪談進行了錄音，然后將它們轉錄為文本，以便進行分析。而后， 我們請訪談對象來驗證轉錄內容。有時，我們會明確請求訪談對象澄清某些方面。我們使用了NVivo軟件來評估收集到的數據。我們對所有語句和詞語進行了歸類，把描述相同想法、動作或屬性的語句和詞語歸為一組。最后，我們根據機構和項目的特征來分析了數據。

　　局限性

　　我 們了解我們的樣本不是隨機的，因此未必能夠代表更廣泛的軟件開發全體。所以，為了試圖緩解可能存在的偏差，我們讓機構自己挑選訪談對象，并允許訪談對象自 己挑選項目。我們承認，訪談對象可能會傾向于選擇較為成功的項目。為了緩和這一問題，我們向訪談對象說明，該項研究不用于分析最佳實踐，只是想了解做事方 式。我們承諾為反饋內容保密。大部分機構是中小型機構，而且都來自西班牙。當然，調研結果可能受到上述因素的影響。此外，大部分都不是緊要領域的項目。不 過，由于我們試圖通過這些項目來揭示工業界實踐，而不是提出一般性理論，所以這不算重大弱點。

　　架構師如何應對非功能性需求

　　我們向軟件架構師們提出了好幾個具體的問題，關于他們如何獲取并文檔化非功能性需求，以及之后如何在系統中進行驗證。我們認為，這對理解架構師在項目中進行決策制定的背景十分重要。關于這部分的詳情，請參見我們的另一篇文章⁶。問題列表見下。由于我們實施的是半結構化訪談，因此這些問題只是作為指導，訪談是依據對話情況來推動的。關于需求獲取、文檔化和驗證方面的話題自然而然地在對話中出現。

　　獲取非功能性需求，由誰負責？

　　需求獲取的目的是從涉眾等處得到系統需求，并細化之。研究者和實踐者都認同需求獲取是需求工程中最具挑戰的部分。致力于精確無歧義表達需求的技術有很多，如調研、創意研討會等。

　　這些技術假定來自客戶方面的涉眾（最終用戶、經理等）在需求獲取方面將貢獻很多。就功能性需求而言，一些訪談對象認同該假定。例如，訪談對象A說：“[業務分析師]編寫一個詳細的文檔來反映所有[功能性]需求”。

　　但 是，該假定對非功能性需求來說并不成立。在我們的調研中，有10個項目，軟件架構師是非功能性需求的主要來源。有些客戶從未提到非功能性需求。訪談對象E 說：“[客戶]從沒提到過網頁加載時間不能超過2秒這樣的需求，但他后來卻對此頗有抱怨。”訪談對象L2說：“客戶提到一個基本的[非功能性需求]，然后 我們根據自己的經驗作了補充”。”

　　這一數值已經超過了Uwe van Heesch和Paris Avgeriou提到的架構師顯著涉及需求獲取的比例（60%）。7

　　只 有訪談對象D、H、I的所在機構是由客戶來領導非功能性需求獲取的。有趣的是，也只有這幾個機構的項目是外包的（管理方分別是一家航空工業公司、一家軟件 公司和一家銀行）。這一情況是由機構之間的從屬關系造成的。然而，即便在這些案例中，架構師仍然在定義非功能性需求方面發揮著積極作用。訪談對象D說： “我們的客戶是一個航空系統部門，所以所有非功能性需求都是良好定義的。另外，我們需要基于我們的經驗再補充一些非功能性需求。”

　　如何獲取非功能性需求？

　　非 功能性需求難以捉摸的特性，決定了不容易事先獲取。根據這條一般性的看法，所有訪談對象都認同非功能性需求的獲取是一個迭代的過程，需要跨越整個系統生命 周期。因為在達到一定重要階段（通常是原型）之前，可能不太容易對系統的部分行為提出期望。訪談對象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%是相稱的。⁸）

　　八位訪談對象執行了一些非功能性需求的驗證，不過僅限于一到三種。他們只考慮以下類型的非功能性需求。

• 性能效率。訪談對象H說：“我們通過負載和壓力測試來進行性能評估。”
• 正確性。訪談對象A說：“我們每編碼一小時，就投入一小時來測試。”
• 易用性。訪談對象K說：“我們制作了一個原型，確保客戶對用戶界面滿意。”
• 可靠性。訪談對象J說：“我們強行引入一些錯誤，看看系統會發生什么，會不會丟失數據等。”

　　安 全性，作為十分重要的一類非功能性需求，所有訪談對象都沒有提到。訪談對象F描述了一個極端的不作驗證的例子：“我們等客戶來抱怨，他們會發現問題的。” 盡管這是個不令人滿意的回復，但它再次反映了這點（和前面提到的檔案化一樣）：出于預算和時間上考慮，工程實踐可能沒法按照理想的方式進行。

　　與之形成鮮明對比的是，訪談對象D采用基于統計分析和模擬的形式化方法來檢查系統的可靠性。當然，這是預料之中的，因為他們的項目涉及到航天工業中的信息系統，屬于緊要領域。過去有研究發現，評估方法與評估目標有關。⁹ 我們的發現與之不謀而合。

　　我們有一個可能與前人研究結果一致的發現，即檔案化與驗證之間的聯系。如Andreas Borg及其同事所說的那樣，“如果用不可度量的詞語來表達需求，那么測試會很消耗時間，甚至根本無法測試。”¹⁰僅有兩位訪談對象采用了可度量的方式來表達非功能性需求，這可能是驗證水平整體較低的原因之一。

　　非功能性需求如何影響架構決策

　　毫無意外，所有訪談對象都認同：非功能性需求會影響他們的決策。但是他們的具體回答反映出了一些細微差別。

　　決策類型

　　非功能性需求影響著四類決策。

　　架構模式

　　對于給定類型的項目，大部分訪談對象會很自然地選擇層次架構，盡管他們中有些人明確給出了決策理由。訪談對象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將性能效率定義為“一定條件下相對于所用資源數量的性能”。”¹³ 該定義有助于我們解除混淆。

　　為了 檢查研究中的觀察結果是否有效，我們與一些大型IT企業展開了一項新的研究。我們期望在文檔化和驗證上看到改善，并且有可能的話，在各種非功能性需求的重 視程度上有所變化。我們還想研究，如果把非功能性需求與架構決策之間的關系明確表達出來（比如，考慮了哪些權衡，放棄了哪些選擇等等）的話，將對最終的系 統架構決策有何影響。關于本課題的相關研究，請見下方。

　　致謝

　　我們非常感謝參加本課題的參與者，感謝他們的時間和貢獻。本課題獲得西班牙項目TIN2010-19130-C02-01的資助。

　　參考文獻

1. R. Kazman and L. Bass, Toward Deriving Software Architectures from Quality Attributes, tech. report CMU/SEI-94-TR-10, Software Eng. Inst.， Carnegie Mellon Univ.， 1994.
2. F. Buschmann, “Value-Focused System Quality，” IEEE Software, vol. 27, no. 6, 2010, pp.84.86.
3. P. Kruchten, R. Capilla, and J.C. Duenas, “The Decision Viewfs Role in Software Architecture Practice,” IEEE Software, vol. 26, no. 2, 2009, pp. 36.42.
4. L. Chung and J.C.S. do Prado Leite, ”On Non-functional Requirements in Software Engineering,” Conceptual Modeling: Foundations and Applications, A.T. Borgida et al.， eds.， Springer, 2009, pp. 363.379.
5. R. Conradi et al.， ”Reflections on Conducting an International Survey on Software Engineering,” Proc. Intfl Symp. Empirical Software Eng.， IEEE, 2005, pp. 214.223.
6. D. Ameller et al.， gHow Do Software Architects Consider Non-functional Requirements: An Exploratory Study，h Proc. 20th IEEE Int‘l Requirements Eng. Conf.， IEEE, 2012, pp.41.50.
7. U. van Heesch and P. Avgeriou, “Mature  Architecting-a Survey about the Reasoning Process of Professional Architects,” Proc.9th Working IEEE/IFIP Conf. Software Architecture (WICSA 11)， IEEE CS, 2011, pp.260.269.
8. R.B. Svensson, T. Gorschek, and B. Regnell, “Quality Requirements in Practice: An Interview Study in Requirements Engineering for Embedded Systems,” Requirements Engineering: Foundation for Software Quality， LNCS 5512, Springer, 2009, pp. 218.232.
9. M. Ali Babar, L. Bass, and I. Gorton, “Factors Influencing Industrial Practices of Software Architecture Evaluation: An Empirical Investigation” Software Architectures, Components, and Applications, LNCS 4880, Springer, 2007, pp. 90.107.
10. A. Borg et al.， “The Bad Conscience of Requirements Engineering: An Investigation in Real-World Treatment of Non-functional Requirements,” Proc. 3rd Conf. Software Eng.Research and Practice in Sweden (SERP 03)， CSREA Press, 2003, pp. 1.8.
11. B. Nuseibeh, “Weaving Together Requirements and Architectures”， vol. 34, no. 3, 2001, pp. 115.119.
12. J.P. Carvallo and X. Franch,  “” Extending the ISO/IEC 9126-1 Quality Model with Non-technical Factors for COTS Components Selection,h Proc. Intfl Workshop Software Quality (WoSQ 06)， ACM, 2006, pp. 9.14.
13. Software Engineering.Software Product Quality Requirements and Evaluation (SQuaRE).Guide to SQuaRE, ISO/IEC 25000, International Org. for Standardization, 2005.

　　非功能性需求領域的相關工作

　　盡管相關研究不多，但我們還是試圖把非功能性需求方面的實證研究結果匯總起來。Richard Svenssion和他的同事描述了18個與我們的提議有一定關系的研究。¹ 然而，這些研究沒有涉及非功能性需求與架構決策之間關系的研究。他們的研究大部分是關注非功能性需求（NFR）方面，而其他研究者對軟件架構（SA）問題 做了更深入的探索；Uwe van Heesch和Paris Averiou專門對非功能性需求與軟件架構之間的關系進行了研究。²

　　在 我們的觀察結果中，有一部分與前人的發現是一致的——比如，軟件架構師常常也承擔其他職責。我們其他的觀察結果之前還沒人公布過。比如，本課題參與者會在 只做簡單驗證的條件下就認為非功能性需求（NFRs）已經符合要求。在我們的觀察結果中，有一些與前人的研究結果不同。比如，我們發現非功能性需求的可度 量性很弱，這與過去報告的案例不一樣。³我們還分析了不同類型的非功能性需求的影響程度。我們發現這與之前的研究存在一定相似性。比如Jose de la Vara和他的同事也把效率和易用性列為最重要的因素。⁴ 不過，我們的研究結果在必要的嚴格性上還差了一點。首先，本課題采用了不同的非功能性需求分類方案。另外，所涉及的職責經常不同，所以非功能性需求的類型也有所不同。¹

　　參考文獻

1. R.B. Svensson, M. Host, and B. Regnell, gManaging Quality Requirements: A Systematic Review，h Proc. 36th Euromicro Conf. Software Eng. and Advanced Applications (SEAA 10)， IEEE CS, 2010, pp. 261.268.
2. U. van Heesch and P. Avgeriou, "Mature Architecting.a Survey about the Reasoning Process of Professional Architects"， Proc. 2011 9th Working IEEE/IFIP Conf. Software Architecture (WICSA 11)， IEEE CS, 2011, pp.260.269.
3. A. Borg et al.， “The Bad Conscience of Requirements Engineering: An Investigation in Real-World Treatment of Non-functional Requirements”， Proc. 3rd Conf. Software Eng. Research and Practice in Sweden (SERP 03)， CSREA Press, 2003, pp. 1.8.
4. J.L. de la Vara et al.， “An Empirical Study on the Importance of Quality Requirements in Industry，” Proc. 23rd Intfl Conf. Software Eng. and Knowledge Eng. (SEKE 11)， Knowledge Systems Inst. Graduate School, 2011, pp. 438.443.