第23章 處理非功能需求

不管你怎么稱呼它們，往往都需要花費一些精力，來獲得可應用于所構建的軟件系統的非功能需求清單。

1．捕捉

我從事軟件開發超過15年，其中大部分是在為客戶構建軟件的情況下做咨詢工作。在這段時間，客戶明確給出非功能需求信息的次數屈指可數。我當然接到過大量需求規格書或功能需求清單，但很少看到其中包括任何關于性能、伸縮性、安全性等信息。面對這種情況，你就得主動出擊，自己去捕捉它們。

挑戰就在這里。如果你問一個業務擔保人，他們的系統想達到哪種級別的可用性，你可能會得到一個類似“100%”、“24/7/365”或“好的，全部”等回答。

2．提煉

一旦你開始問那些有關非功能需求的棘手問題，或你已經走運到能收到一些信息，就可能需要提煉它們。

有為數不多的幾次，我接到功能需求規格書中確實包含一些非功能需求的信息，但通常都含糊無用。舉個例子，我曾從潛在客戶那里收到過一份125頁的文檔，詳述了對軟件系統的需求。其中功能需求的細節占據了文檔的絕大部分，只有最后半頁是留給非功能需求的。里面說道：

? 性能：系統必須要快；

? 安全性：系統必須安全；+ 可用性：系統的運行時間應該達到100%。

雖然不是很有用，但至少能展開一些討論了。你可以根據交流對象變換問題，而不是問需要多少可用性，然后得到一個不可避免的“24/7”的答案。比如下面這些。

? “你能忍受的系統停機時間是多少？”

? “如果系統核心在朝九晚六的正常工作時間內出現故障，會發生什么？”

? “如果系統核心在正常工作時間以外出現故障，會發生什么？”

你現在要做的是探索需求，搞清楚驅動力是什么。為什么系統要可見？當我們談論“高安全性”，要保護的是什么？我們的目標是獲得一組特定的，理論上可以明確量化的非功能需求。比如下面這些。

? 系統平均應該支持多少并發用戶？高峰時段呢？

? 多長的響應時間是可以接受的？系統各個部分都是如此，還是只是針對特定的功能？

? 為了保護系統安全，我們究竟該怎么做？我們真的需要對數據加密嗎，受限訪問足夠了嗎？

如果你能聯想到一定數量的非功能性需求（如用戶數、數據量、最大響應時間等），就能寫一些驗收標準并客觀地進行測試。

挑戰

記住這一點，如果問人們是否需要一個東西，無疑我們都知道他們會說“是的”。這就是為什么很難劃分功能需求、用戶故事等的優先級。不管你使用哪一種度量優先級的方法（MoSCoW，高/中/低，等等），只要嘗試劃分優先級，每件事最后都會變成“不可或缺”。你可以創建一個“一定不能少”的目錄，但我們知道每件事都會上目錄。

這就要換一種方法，提出成本的影響有助于集中注意力。比如下面這些。

? 架構師：“你需要一個正常運行時間為100%的系統。構建這個系統必須通過大量冗余來消除每一個故障點，我們所有的花費都需要翻一番，外加很多自動故障轉移工程的工作。這個成本大概是100萬美元?；蛘呶覀兛梢詾槟銟嫿ㄒ粋€簡單一些的系統，必須告誡你，某些組件可能需要進行監測，發生故障時需要手動重啟，這樣的成本大概是10萬美元。您需要哪一種呢？”

? 擔保人：“哦，如果是那樣，我要便宜的方案。”

凡事皆有可能，但每件事都有代價。解釋那些代價有助于找到給定語境中的最好方案。