讀古今文學網 > 程序員必讀之軟件架構 > 第22章 質量屬性(非功能需求) >

第22章 質量屬性(非功能需求)

當你收集需求時,人們會很樂意給你一個願望清單,寫滿了他們想要軟件系統完成的事;也有完善的方法以用戶故事、用例、傳統的需求規格書、驗收標準等形式來捕捉這一信息。那麼,那些討厭的「非功能性需求」呢?

非功能性需求通常被看作是「能力」,主要跟服務質量有關。按理說,比非功能性需求更好的說法是「系統特徵」或「質量屬性」,但不太常用。下面大致列出了常見的質量屬性。

1. 性能

性能就是一個東西有多快,通常指響應時間或延遲。

  • 響應時間:從發出請求到收到響應所用的時間,比如用戶點擊網頁中的超鏈接或桌面應用程序中的按鈕。
  • 延遲:消息從A點到B點,通過你的系統所用的時間。

就算構建的不是「高性能」軟件系統,性能也可應用於Web應用程序、桌面應用程序、面向服務架構、消息系統等幾乎所有你要構建的軟件系統。如果用戶說你的軟件「太慢」,你就明白為什麼有一些性能的概念很重要。

2. 可伸縮性

可伸縮性基本上就是軟件處理更多用戶、請求、數據、消息等的能力。可伸縮性和並發機制密不可分,因此能在相同的時間內處理更多的東西(比如每秒的請求)。

3. 可用性

可用性是軟件對服務請求的可操作和可見程度。你常會看到用「9」來衡量或指代可用性,如99.99%(「四個9」)或99.999%(「五個9」)。這些數字指的是正常運行時間的百分比。硬幣的另一面是可以容忍的停機時間。99.9%(「三個9」)的正常運行時間意味著留給計劃維護、升級和意外故障的時間每天只有1分多鐘。

4. 安全性

安全性涵蓋了從認證和授權到數據在運輸和儲存中的機密性的所有事情。和性能一樣,安全性很有可能在一定程度上對你很重要。對於部署到互聯網的Web應用程序,安全性應該被視為最基礎的東西。開放Web應用程序安全項目(OWASP,Open Web Application Security Project)1 是學習安全性的一個很好的出發點。

1 https://www.owasp.org

5. 災難恢復

如果失去一個運行了你的軟件的硬盤、服務器或數據中心,會發生什麼?災難恢復處理的就是這些。如果你的軟件系統至關重要,就會經常聽到人們談論業務連續性過程,也就是發生災難事件時,應該做什麼才能保持持續運行的狀態。

6. 可訪問性

可訪問性通常是指像W3C的可訪問性標準2 這樣的東西,指的是如何讓視覺障礙之類的殘疾人也能使用你的軟件。

2 http://www.w3.org/standards/webdesign/accessibility

7. 監測

有些組織對於應該如何監測軟件系統才能確保它們正常運行和滿足服務請求,有特定的需求。這可能包括將軟件與平台特定的監測功能(比如Java平台的JMX)集成,或發生故障時向集中監測儀表發送警報(比如通過SNMP)。

8. 管理

監測通常提供一個軟件系統的只讀視圖,有時會有運行時管理需求。例如,有必要的話,暴露一些功能,使得操作人員能夠修改系統運行時的拓撲結構或配置元素,刷新只讀緩存等。

9. 審計

人們往往需要一個引起軟件系統中數據或行為變化的事件的日誌(即審計日誌),特別是涉及錢的時候。通常這些日誌需要捕獲與變動由誰做出、什麼時候做出以及為什麼做出相關的信息。變動本身(即變動前後的值)往往也需要記錄。

10. 靈活性

靈活性是一個有點濫用和含混的術語,指的是軟件執行多個任務,或以不同方式執行單個任務的「靈活性」。一個很好的靈活性需求的例子是非技術人員修改軟件內部使用的業務規則的能力。

11. 可擴展性

可擴展性也是濫用和模糊的,但它指的是擴展軟件使其可以做一些現在還不能做的事的能力,也許是通過使用插件和API。一些市面上的產品(如微軟Dynamics CRM)允許非技術用戶擴展存儲的數據和改變其他用戶與數據交互的方式。

12. 可維護性

可維護性往往被認為是一個需求,但這到底是什麼意思?作為軟件開發者,我們通常會努力打造「可維護」的軟件,但值得我們思考的是,代碼庫以後將由誰來維護。可維護性很難量化,所以我寧願思考我們可以遵循的架構和開發原則 ,因為這些是編寫可維護的代碼的驅動力。

13. 法律法規

有些行業受到當地法律或監管機構的嚴格管理,導致了與數據保留或審計日誌等相關的額外需求。舉個例子,大多數金融機構(投資銀行、零售銀行、信託公司等)為了保持在市場中的運作能力,必須遵守一些規則(如反洗錢)。

14. 國際化(i18n)

很多軟件系統,特別是部署在互聯網上的,不再以單一的語言交付。國際化是指以多種語言交付軟件中用戶可見元素的能力。這看似簡單,當你試圖將其加入已有軟件時,才會意識到有些語言是從右向左書寫的。

15. 本地化(l10n)