重點摘要#
- 「快速」、「可響應」、「可擴展」都不是需求——因為無法客觀衡量
- 所有品質屬性都可以被量化並設定閾值
- 使用範圍（最小值、標稱值、最大值）來表達不確定的量化標準
- 拒絕接受「很多」和「很快」這樣的模糊回答
詳細內容#
「快速」不是需求。「可響應」也不是。「可擴展」也不是。這些詞最大的問題在於：你沒有客觀的方法來判斷它們是否被滿足。然而使用者確實想要這些品質，而架構師的角色在很大程度上就是幫助系統具備這些品質，並平衡它們之間不可避免的衝突。
模糊形容詞的問題#
沒有客觀的標準，架構師就會受制於：
- 善變的使用者：「不，我不接受，還是不夠快」
- 偏執的程式設計師：「不，我不會發布，還是不夠快」
每次有人告訴你系統需要「可擴展」時，問他們新使用者從哪裡來、為什麼來。問多少個、什麼時候。拒絕「很多」和「很快」作為答案。
如何量化#
應該問的簡單問題：
- 多少個？（How many?）
- 在什麼時間段內？（In what period?）
- 多頻繁？（How often?）
- 多快？（How soon?）
- 是增加還是減少？以什麼速率？
如果這些問題無法回答，那表示需求本身還沒有被理解清楚。答案應該在系統的商業案例中，如果沒有，就需要深入思考。
用範圍表達不確定性#
不確定的量化標準必須以範圍來表達：最小值、標稱值和最大值。隨著架構的演進，可以對照這些標準來檢查是否仍在容許範圍內。
一個真正的需求範例：「必須在不超過 1500 毫秒內回應使用者輸入。在正常負載下，平均回應時間必須在 750 到 1250 毫秒之間。低於 500 毫秒的回應時間使用者無法感知差異，因此我們不會為低於此值付出成本。」這才是一個需求。
— By Keith Braithwaite