概述#

架構師在設計系統之前，必須先辨識出架構顯著需求（Architecturally Significant Requirements, ASRs）。ASR 是那些對架構具有深遠影響的需求——納入或排除某個 ASR，往往會導致截然不同的架構設計。然而，ASR 不會自動浮現；架構師需要主動去搜集他們需要的資訊，來產出能回應專案需要的架構——無論這些資訊先前是否已被識別。

本章提供了系統化的技術，幫助架構師從多種來源中挖掘和捕捉 ASR，以及影響架構的其他因素。

一個合格的 ASR 必須同時具備兩個特徵：

• 對架構有深遠影響——納入它可能產生完全不同的架構
• 具有高商業或任務價值——值得在其他需求之間做出權衡取捨

從需求文件中收集 ASR#

尋找 ASR 候選者的一個明顯地方是需求文件或 user stories。然而，實際上這通常不是個可靠的來源，儘管需求文件中的資訊仍然可能有用。

不要抱太大期望#

許多專案並不會建立或維護那種教科書級別的需求文件。更重要的是，沒有架構師會坐等需求「完成」才開始工作——架構師必須在需求仍在變動時就開始設計。即使需求文件存在且穩定，它們通常在兩方面讓架構師失望：

• 大量需求與架構無關：需求規格書的絕大部分聚焦於功能需求（features and functionality），但真正驅動架構的是品質屬性需求（Quality Attribute requirements）。實務上，我們經常看到類似「系統應具備高可用性」或「系統應模組化」或「系統應滿足使用者的效能期望」這樣的需求——它們既無法測試也無法證偽，對架構師來說幾乎沒有實質用處。不過從樂觀的角度看，這些可以被視為架構師就這些領域的真正需求展開對話的邀請函。
• 對架構師有用的資訊往往不在需求文件中：許多驅動架構的關切並不會表現為系統的可觀察行為，因此不是需求規格書的主題。ASR 經常源自開發組織自身的商業目標（business goals），例如團隊編組假設、技術環境限制等。在採購情境中，需求文件代表的是採購方的利益，而非開發方的利益。

從需求文件中嗅出 ASR#

儘管需求文件無法提供完整的故事，架構師仍然應該進行一番調查與考古來挖掘 ASR。以下類別值得特別關注：

• Usage：使用者角色 vs. 系統模式、國際化、語言區分
• Time：時效性、元素協調
• External elements：外部系統、協定、感測器或致動器（裝置）、中介軟體
• Networking：網路屬性與配置（包括安全特性）
• Orchestration：處理步驟、資訊流
• Security properties：使用者角色、權限、認證
• Data：持久性與時效性
• Resources：時間、並行性、記憶體使用、排程、多使用者、多活動、裝置、能源使用、軟資源（如 buffer、queue）和擴展性需求
• Project management：團隊編組計畫、技能組合、培訓、團隊協調
• Hardware choices：處理器選擇、處理器系列、處理器演進
• Flexibility：功能彈性、可移植性、校準、配置
• Named technologies：指名的技術、商業套件

除了這些類別本身具有架構顯著性外，每一項的預期變更與演進同樣可能具有架構意義。即使需求文件未提及演進，架構師也應主動思考哪些項目可能隨時間變化，並據此設計系統。

透過訪談利害關係人收集 ASR#

當專案沒有完善的需求文件，或品質屬性需求在設計啟動前尚未確定時，訪談利害關係人是最可靠的方法。

架構師的角色——主動設定需求#

利害關係人經常不清楚自己的品質屬性需求。此時架構師被期待主動協助設定系統的品質屬性需求，而非被動等待。那些認知到這種協作需求並鼓勵它的專案，比那些不認知的專案更可能成功。

經驗豐富的架構師通常能提供以下洞見：

• 類似系統曾展現哪些品質屬性回應
• 當前情境下哪些品質屬性回應是合理可期的
• 哪些需求容易達成、哪些可能代價高昂甚至不可行
• 架構師是唯一能說「我實際上可以交付比你預想更好的架構——這對你有用嗎？」的人

例如，利害關係人可能要求 24/7 可用性（誰不想要？），但架構師可以解釋這項需求的可能成本，讓利害關係人在可用性與可負擔性之間做出有資訊的權衡。

如果你堅持要求量化的品質屬性需求，你可能會得到武斷的數字。其中某些需求將難以滿足，最終反而會妨礙系統的成功。

Quality Attribute Workshop (QAW)#

QAW 是一種以利害關係人為中心的引導式工作坊，用於在架構完成之前產生、優先排序和精煉品質屬性情境。它特別強調系統層級的關切以及軟體在系統中的角色。QAW 高度依賴利害關係人的參與。

核心步驟包括：

1. 商業/任務簡報（Business/Mission Presentation）：商業代表花約一小時介紹系統的商業背景、廣泛功能需求、限制與已知品質屬性需求。後續步驟中精煉的品質屬性將主要源自此步驟呈現的商業/任務需求。
2. 架構計畫簡報（Architectural Plan Presentation）：架構師展示目前的架構計畫（即使只是初步的系統描述或背景圖），讓利害關係人了解目前的架構思考。
3. 識別架構驅動因子（Identification of Architectural Drivers）：引導者分享從前兩步整理的關鍵架構驅動因子清單，請利害關係人澄清、新增、刪除和修正，達成共識。
4. 情境腦力激盪（Scenario Brainstorming）：每位利害關係人表達代表其關切的情境，引導者確保每個情境都涉及品質屬性（明確指定刺激和回應）。
5. 情境合併（Scenario Consolidation）：合併相似的情境以消除重複，前提是提案者同意且不認為合併會稀釋其情境。
6. 情境優先排序（Scenario Prioritization）：每位利害關係人分配相當於合併後情境總數 30% 的票數，可將任意數量的票投給任何情境或情境組合。
7. 情境精煉（Scenario Refinement）：將最高優先的情境精煉為六段式格式：來源（Source）- 刺激（Stimulus）- 產物（Artifact）- 環境（Environment）- 回應（Response）- 回應量測（Response Measure）。精煉過程中浮現的議題應被記錄。

利害關係人訪談的結果應包含一份架構驅動因子清單和一組經利害關係人群體優先排序的品質屬性情境。這些資訊可用於：

• 精煉系統與軟體需求
• 理解和釐清系統的架構驅動因子
• 為架構師後續的設計決策提供依據
• 引導原型和模擬的開發
• 影響架構開發的順序

當利害關係人說「我不知道這個需求應該是什麼」時，可以嘗試裝傻策略（playing dumb）：提出一個顯然不合理的值——「所以……24 小時的回應時間可以嗎？」「不行！」「1 小時呢？」「不行！」「5 分鐘呢？」「不行！」「10 秒呢？」「嗯……我想大概可以接受那樣的東西……」。透過裝傻，你通常能讓人至少給出一個可接受的值域，而這個範圍通常就足以讓架構師選擇適當的架構機制。24 小時 vs. 10 分鐘 vs. 10 秒 vs. 100 毫秒，對架構師來說意味著非常不同的架構途徑。

透過理解商業目標收集 ASR#

商業目標（Business Goals）是建構系統的根本理由（raison d’etre）。沒有組織會無緣無故建構系統——相關人員希望推進組織及自身的使命和抱負。商業目標對架構師至關重要，因為它們經常直接導向 ASR。

商業目標與架構的三種關係#

1. 商業目標導向品質屬性需求：每個品質屬性需求——如使用者可見的回應時間、平台彈性、堅不可摧的安全性——都源自某個更高層的目的。例如，為了在市場上差異化產品以搶占市場份額，可能導向看似不尋常地快速回應時間的需求。了解需求背後的商業目標，能讓架構師有意義地質疑需求或調動資源來滿足它。
2. 商業目標直接影響架構，而非透過品質屬性：例如，一位經理堅持架構中必須包含資料庫——不是出於技術原因，而是因為組織有一群高薪的資料庫團隊目前沒有被分配工作。沒有任何需求規格書會捕捉這樣的需求，也沒有任何經理會允許這樣的動機被記錄。然而，如果架構交付時沒有資料庫，從經理的角度看就跟缺少重要功能一樣有缺陷。
3. 商業目標對架構沒有影響：並非所有商業目標都導向品質屬性。例如，「降低成本」的目標可能透過降低辦公室暖氣溫度或減少員工薪資來實現，與架構完全無關。

PALM 方法#

架構師經常透過滲透（osmosis）——工作、傾聽、交談、吸收——來了解組織的商業目標。但更系統化的方式既可行也值得追求。PALM（Pedigreed Attribute eLicitation Method）方法需要與架構師和關鍵商業利害關係人舉辦工作坊，核心步驟包括：

• 商業目標引出（Business Goals Elicitation）：使用下方的類別引導討論，從利害關係人處捕捉重要的商業目標，將其精心表達為商業目標情境（business goal scenarios，一種結構化的七段式表達），合併幾乎相同的目標以消除重複，然後由參與者優先排序。
• 從商業目標識別潛在品質屬性（Identify Potential QAs from Business Goals）：對每個重要的商業目標情境，讓參與者描述一個品質屬性和回應量測值——如果架構實現了它，將有助於達成該目標。

商業目標類別#

以下 11 個類別可作為腦力激盪和引出的輔助工具，確保涵蓋面的完整性：

1. 組織的成長與持續性（Growth and continuity of the organization）
2. 達成財務目標（Meeting financial objectives）
3. 達成個人目標（Meeting personal objectives）
4. 對員工的責任（Meeting responsibility to the employees）
5. 對社會的責任（Meeting responsibility to society）
6. 對國家的責任（Meeting responsibility to the state）
7. 對股東的責任（Meeting responsibility to the shareholders）
8. 管理市場地位（Managing market position）
9. 改善商業流程（Improving business processes）
10. 管理產品品質與聲譽（Managing the quality and reputation of products）
11. 管理環境隨時間的變化（Managing change in the environment over time）

以 Utility Tree 捕捉 ASR#

在理想的世界中，前述的技術會在開發流程早期被應用。但現實中，架構師經常因組織或商業原因而無法在需要時接觸到利害關係人。此時可以使用 Utility Tree（效用樹）——一種自上而下的表示法，呈現架構師認為對系統成功至關重要的品質屬性相關 ASR。

Utility Tree 的結構#

• 根節點為「Utility」，代表系統整體的「良好程度」（overall goodness）
• 第二層列出系統需展現的主要品質屬性（如 Performance、Security、Availability）——它們只是後續精煉的中間佔位符
• 第三層為品質屬性的特定精煉，應該是與你的系統相關的精煉。例如 Performance 可分解為「data latency」和「transaction throughput」，或者「user wait time」和「time to refresh web page」
• 葉節點是具體的 ASR，表達為品質屬性情境

雙維度評估#

每個 ASR 情境需根據兩個標準進行評估，使用 H/M/L 評分：

• 商業價值（Business Value）：
  • H = 必備需求（must-have）
  • M = 重要但不致命
  • L = 有則更好，不值得太多投入
• 技術風險（Technical Risk）：
  • H = 讓你夜不能寐
  • M = 有顧慮但風險不高
  • L = 有信心能滿足

獲得 (H, H) 評級的 ASR 情境顯然最值得關注——它們是「最顯著中的最顯著」。如果有大量 (H, H) 情境，這可能引起對系統是否真的可行的擔憂。

Utility Tree 範例（醫療保健系統）#

利用 Utility Tree 進行檢查#

• 某個品質屬性精煉下沒有任何 ASR 情境，不一定是錯誤或遺漏，但應調查是否有未記錄的 ASR 情境
• (H, H) 情境應獲得最多關注——它們是你作為架構師的「行軍命令」

變更是常態#

Edward Berard 曾說：「在水上行走和根據規格書開發軟體，只有當兩者都凍結時才簡單。」

需求——無論是否已被捕捉——隨時都在變化。架構師必須適應並跟上，確保架構仍然正確。

架構師應對變更採取以下策略：

• 與決定 ASR 的關鍵利害關係人保持暢通的溝通管道——架構師需要是優秀的雙向溝通者
• 本章介紹的方法可以重複應用以適應變更
• 比變更領先一步更為理想：如果預知 ASR 可能變更，可以先做初步設計探索以了解其影響
• 如果變更代價過高，提早與利害關係人分享這個資訊是極有價值的貢獻——越早知道越好
• 更有價值的可能是：建議一些能（幾乎）同樣達成目標但不會超出預算的替代變更

本章總結#

ASR 可以從以下來源收集和捕捉：

• 需求文件：雖然大部分內容與架構無關，但仍可從特定類別中挖掘有價值的線索
• 利害關係人訪談：透過 QAW 等結構化方法，引出、優先排序和精煉品質屬性情境
• 商業目標：透過 PALM 方法，使用商業目標情境系統性地將商業目標轉化為品質屬性需求
• Utility Tree：當無法接觸利害關係人時，架構師可自行建構的自上而下表示法，使用 H/M/L 雙維度評估每個 ASR 的商業價值和技術風險

建議將所有 ASR 記錄在統一的地方，以便審查、參考、用於證明設計決策的合理性，並在系統重大變更或隨時間推移時重新審視。