架構重要需求

架構重要需求（Architecturally significant requirements）是對軟體架構有重大影響的需求。需求可能是軟體需求，也可能是硬體需求。

和非功能需求和品質屬性的關係
人們大約在2016年才認知到「架構重要需求」概念的重要性。在探討架構時，常會提到非功能需求或是品質屬性，不過近期的實證研究發現，對於軟體系統來說，不是每一個非功能需求都會影響其軟體架構，而且，相反的，有些功能性的也會影響架構。此研究建議，在討論軟體架構時，除了識別需求是功能需求還是非功能需求之外，也要識別哪些需求是架構重要需求。

特徵
架構重要需求可以由以下幾個層面來挑選。

敘述式特徵
架構重要需求多半不容易定義，也不容易表達清楚，一般會用含糊的方式描述，一開始很容易被省略，常會藏在其他的需求中，而且是主觀、易變、和情境有關的。其他的需求也常常會有這些敘述式特徵，不過因為架構重要需求的重要性，讓這些更加特殊且具挑戰性。

指標
若有一個需求的影響廣泛、會影響權衡取捨、有嚴格限制（有限制，無法妥協）、需要打破假設、或是很難達成，很有可能就是架構重要需求。

文獻中有提到以下架構重要需求的指標：
 需求伴隨著高商業價值，或是高技術風險。
 此需求受到特定利害關係人的關注。
 此需求是頭一次實施，目前使用的架構中的組件都沒有負責此一需求。
 此需求的服務品質（QoS）或服务级别协议（SLA）特性和此架構可以滿足的特質都不同。
 在之前專案中，曾有類似內容的需求出現預算趣超支或是客戶不滿意的情形。
和Peter Eeles都討論過其他判斷架構重要需求的準則。在2020年軟體架構歐洲研討會中也討諭過一些：商業價值或風險、利害關係人的關注、品質水準、外部相依關係、交叉領域、第一次實施、其他專案的問題來源等。

推論
若需求標示了軟體系統的品質屬性：說明甚核心特性、為系統加限制條件、定義系統運作的環境，此需求有可能就是架構重要需求。

提取
就像所有的非功能需求以及品質屬性一樣，架構重要需求也需要符合SMART原则。品質屬性場景（Quality attribute scenarios） 是一種達到SMART原則中S（特定）和M（可衡量）的方式。則建議使用Quality Attribute Workshops。也曾有人建議要維持架構分析以及設計的輕量化，易於修改，特定應用分類以及技術領域的品質屬性樹（quality attribute trees）可以支持這種作法。

很重要的向其他人說明所提取的架構重要需求及其他架構產出物，利用對（尤甚是商業利害關係人）容易理解的表達方式及語言來說明。

影響
在軟體設計中會考慮架構重要需求，而且會影響，也可以用來證明架構決策的合理性。若沒有滿足架構重要需求，可能會累積技術債務。例如，沒有符合安全或是法規的需求，會讓系統以及流程保證稽核變的複雜，也會增加稽核時發現漏失的可能性。有些文獻有提到如何處理系統品質屬性（以及架構重要需求）。

參考資料

相關條目

架構模式

非功能需求
需求工程
軟體架構

系統架構
软件架构