跳至內容

架構重要需求

維基百科,自由的百科全書

架構重要需求(Architecturally significant requirements)是對軟體架構有重大影響的需求[1]。需求可能是軟體需求,也可能是硬體需求。

和非功能需求和品質屬性的關係

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

特徵

架構重要需求可以由以下幾個層面來挑選[1]

敘述式特徵

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

指標

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

文獻中有提到以下架構重要需求的指標:

  • 需求伴隨著高商業價值,或是高技術風險。
  • 此需求受到特定利害關係人的關注。
  • 此需求是頭一次實施,目前使用的架構中的組件都沒有負責此一需求。
  • 此需求的服務品質(QoS)或服務級別協議(SLA)特性和此架構可以滿足的特質都不同。
  • 在之前專案中,曾有類似內容的需求出現預算趣超支或是客戶不滿意的情形。

OpenUP英語OpenUP[4]和Peter Eeles[5]都討論過其他判斷架構重要需求的準則。在2020年軟體架構歐洲研討會中也討諭過一些:商業價值或風險、利害關係人的關注、品質水準、外部相依關係、交叉領域、第一次實施、其他專案的問題來源等"Architectural Significance Test". [2023-01-09]. (原始內容存檔於2023-03-19). 

推論

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

提取

就像所有的非功能需求以及品質屬性一樣[6],架構重要需求也需要符合SMART原則。品質屬性場景(Quality attribute scenarios)[2] 是一種達到SMART原則中S(特定)和M(可衡量)的方式。軟體工程學院英語Software Engineering Institute則建議使用Quality Attribute Workshops[7]。也曾有人建議要維持架構分析以及設計的輕量化,易於修改,特定應用分類以及技術領域的品質屬性樹(quality attribute trees)可以支持這種作法[8]

很重要的向其他人說明所提取的架構重要需求及其他架構產出物,利用對目標受眾英語target audience(尤甚是商業利害關係人)容易理解的表達方式及語言來說明[9]

影響

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

參考資料

  1. ^ 1.0 1.1 1.2 Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar. Characterizing Architecturally Significant Requirements. IEEE Software. 2013, 30 (2): 38–45. S2CID 17399565. doi:10.1109/MS.2012.174. hdl:10344/3061可免費查閱. 
  2. ^ 2.0 2.1 Bass, Len; Clements, Paul. Software Architecture in Practice. Addison Wesley. 2003. ISBN 978-0321154958. 
  3. ^ 3.0 3.1 Eckhardt, Jonas; Vogelsang, Andreas; Fernández, Daniel. Are "Non-functional" Requirements really Non-functional? - An Investigation of Non-functional Requirements in Practice (PDF). The 38th International Conference on Software Engineering. Association for Computing Machinery. 2016 [2023-01-07]. (原始內容存檔 (PDF)於2017-08-29). 
  4. ^ Concept: Architecturally Significant Requirements. [2016-08-19]. (原始內容存檔於2016-10-17). 
  5. ^ Peter Eeles on ResearchGate. [2023-01-09]. (原始內容存檔於2022-09-24). 
  6. ^ Quality Attributes (PDF). [2023-01-09]. (原始內容存檔 (PDF)於2017-08-29). 
  7. ^ The SEI Quality Attribute Workshop. [2023-01-09]. (原始內容存檔於2017-10-04). 
  8. ^ Keeling, Michael. Lightweight and Flexible: Emerging Trends in Software Architecture from the SATURN Conferences. IEEE Software. 2015, 32 (3): 7–11. doi:10.1109/MS.2015.65. 
  9. ^ Schulenklopper, Jochem. Why They Just Don't Get It: Communicating about Architecture with Business Stakeholders. IEEE Software. 2016, 33 (3): 13–19. S2CID 1309474. doi:10.1109/MS.2016.67. 
  10. ^ K. Julisch et al., Compliance by design - Bridging the chasm between auditors and IT architects 網際網路檔案館存檔,存檔日期2017-09-21. Computers & Security 30(6-7): 410-426 (2011)
  11. ^ Implementing System-Quality Attributes. [2023-01-07]. (原始內容存檔於2018-10-30). 
  12. ^ A. Rotem-Gal-Oz, SOA Patterns, Manning, 2012.

相關條目