要件定義と設計
このドメインで問われること
利用者の要望を、測定可能な非機能要件とアドレス設計・文書構成に落とせるかが試される。「可用性を高く」といった曖昧な表現を、数値と設計判断に変換する力が問われる。
要件の構造化
- 機能要件は「何ができるか」、非機能要件は「どの程度の品質か」。可用性・性能・拡張性・セキュリティ・運用性・移行性に分けて整理する。
- 非機能要件は必ず測定可能な形にする。例: 稼働率 99.9%、基幹業務の RTT 10ms 以内、将来 3 年で帯域 2 倍。
- 制約条件（予算、既存設備、回線事業者の提供地域、法令）を先に洗い出し、設計の選択肢を絞る。
設計の成果物
- HLD（概要設計）は方式選定と構成、LLD（詳細設計）はアドレス表・VLAN 表・設定パラメータ・接続表まで含む。
- IP アドレッシングは集約可能なように上位ビットから連番で割り当てる。拠点ごとに /24 を連続で振れば 1 本の集約経路で広告できる。
- 要件と設計項目の対応（トレーサビリティ）を残す。試験項目も要件から導出する。
実例（集約を意識した割当）
10.10.0.0/24、10.10.1.0/24、10.10.2.0/24 を 3 拠点に割り当てれば 10.10.0.0/22 で集約でき、上位ルータの経路数は 1 本で済む。これに対し 10.10.0.0/24、10.20.0.0/24、10.30.0.0/24 と飛び番にすると 3 本の経路が必要になり、将来の拡張余地も読みにくい。
失点しやすい罠
- 非機能要件を数値化せず、試験で判定できない状態にする。
- ピーク率やバーストを考慮せず平均帯域だけで設計する。
- 収容数を現状だけで決め、拡張時の再設計コストを見積もらない。