アーキテクチャ要件仕様は、TOGAFの成果物の一つであり、実装プロジェクトがアーキテクチャ12に準拠するために何をしなければならないかを概説する定量的な記述のセットを提供します。これは、ソリューションの定性的な視点を提供し、アーキテクトの意図を伝えることを目的とするアーキテクチャ定義文書の補足文書です。アーキテクチャ要件仕様は、ソリューションの定量的な視点を提供し、アーキテクチャの実装中に満たすべき測定可能な基準を明示します3。通常、実装契約またはより詳細なアーキテクチャ定義4のための契約の主要な構成要素となります。参考資料：
* 成果物: アーキテクチャ要件仕様 - The Open Group
* アーキテクチャ要件仕様 - Visual Paradigm コミュニティ サークル
* TOGAF 標準バージョン 9.2 - 定義 - The Open Group
* TOGAF 標準バージョン 9.2 - アーキテクチャ要件仕様 - The Open Group

包括的かつ詳細な説明
アーキテクチャの範囲を定義する際に、TOGAF では考慮する必要がある 4 つの側面を特定しています。
* 範囲 - この側面は、アーキテクチャが影響を与える企業の範囲を表します。これは、「企業のどの程度の範囲がカバーされるのか？」という問いに答えます。例えば、スコープには企業全体、事業部、部門、あるいは単一の組織機能のみが含まれるのでしょうか？
* 深さ - これは、カバーされる詳細レベルを指します。例えば、アーキテクチャは高レベルの機能を説明するのか、それとも詳細なシステム設計まで踏み込むのか？
* 期間 - アーキテクチャの計画期間を定義します。短期（戦術的）、中期、長期（戦略的）のいずれかになります。
* アーキテクチャドメイン - 対象となるドメイン（ビジネス、データ、アプリケーション、テクノロジー）を示します。スコープには、これらのドメインのすべて、または一部が含まれる場合があります。
* プロジェクトの範囲 (場合によっては個別に議論されます) - 影響を受ける特定のプログラム、ポートフォリオ、またはプロジェクトに焦点を当てます。
これらのうち、企業の規模に特に関係する次元は「幅」です。
他の選択肢が間違っている理由
* A. アーキテクチャ ドメイン: 企業の範囲ではなく、カバーされているドメイン (ビジネス、データ、アプリケーション、テクノロジー) を指します。
* B. 深さ: 企業の範囲ではなく、詳細レベルを指します。
* C. プロジェクト: 企業の範囲ではなく、プログラムまたはイニシアチブの焦点を指します。
参考文献
* The Open Group、TOGAF 標準、バージョン 9.2、パート II: ADM - 予備フェーズ (範囲の考慮事項)。
* The Open Group、TOGAF 9 認定学習ガイド - アーキテクチャ範囲の次元 (幅、深さ、期間、アーキテクチャ ドメイン) に関する説明。

アーキテクチャガバナンスとは、エンタープライズアーキテクチャとその原則、標準、目標への準拠を確保するための実践です。アーキテクチャガバナンスは、アーキテクチャの開発および実装プロセスを確立、監視、および制御し、発生する可能性のある問題や対立を解決するための手段を提供します。また、アーキテクチャガバナンスは、すべての利害関係者が意思決定プロセスに代表され、関与し、彼らの利益と懸念がバランスよく整合していることを保証します。ステートメント1と2は、アーキテクチャ活動における責任、説明責任、公平性、透明性の重要性を強調しており、組織内でアーキテクチャガバナンスを導入することの価値と必要性を強調しています。ステートメント3と4は、ガバナンスの側面よりも、優れたエンタープライズアーキテクチャを持つことの利点と成果に関連しています。参考文献：TOGAF標準バージョン9.2、パートVI：アーキテクチャ能力フレームワーク、第50章：アーキテクチャガバナンス：TOGAF標準バージョン9.2、パートIII：ADMガイドラインとテクニック、第29章：アーキテクチャガバナンス

TOGAF 標準によれば、説明に一致する成果物は次のとおりです。
1 アーキテクチャ原則：これらは、永続的でめったに変更されないことを意図した一般的な規則とガイドラインであり、組織がその使命を果たすための方法を示し、サポートします1。これらは、企業内の様々な要素間の合意レベルを反映し、将来のITに関する意思決定の基礎となります1。
2 アーキテクチャ契約：開発パートナーとスポンサーの間で、アーキテクチャの成果物、品質、および目的適合性について締結される共同契約です2。合意された仕様と標準に従ってアーキテクチャが実装および管理されることを保証するために使用されます2。
3 アーキテクチャ作業依頼書：これは、アーキテクチャ開発サイクル3の開始を促すために、スポンサー組織からアーキテクチャ組織に送信される文書です。アーキテクチャプロジェクト3のスコープ、スケジュール、予算、成果物、および関係者を定義します。
4 アーキテクチャ要件仕様：これは、実装プロジェクトがアーキテクチャ4に準拠するために何を行う必要があるかを概説した定量的な記述の集合です。各アーキテクチャドメインの要件と、それらの間の関係性および依存関係を定義します4。
1: アーキテクチャの原則 2: アーキテクチャ契約 3: アーキテクチャ作業の依頼 4: アーキテクチャ要件仕様