要件定義書は業務領域単位で書く

要件定義書を何の単位で1ドキュメントにするかを定める。結論は「1業務領域 = 1ドキュメント、その上に全体要件書を1枚」である。これは文書という器の粒度の話であり、記述の層(要求・要件・仕様・設計)とは別の軸である(「層と粒度は別の軸である」参照)。

規則

全体要件書(1枚)     … 領域分割・共通用語・共通ルール・非機能
 ├ 要件定義書 — 領域A
 ├ 要件定義書 — 領域B
 └ …

複数の画面をまたいでも、一つの業務ゴールに向かう作業のまとまりである。

判定は「業務ゴールを一文で言えるか」。言えれば領域、言えなければ領域ではない。

例	ゴール	判定
コンテンツ管理	書籍を正しい内容・タイミングで読者に提供し続ける	領域
お知らせ管理	伝えるべき情報を適切な分類・タイミングで利用者に届ける	領域
コンテンツ編集画面	(ゴールではなく、上のゴールの実現手段の一部)	領域ではない
ダッシュボード	(各領域の状態を横断表示する入口。固有のゴールがない)	領域ではない

一文テストを補強する徴候が3つある。いずれも「変更理由の軸で凝集させる」という同じ原理の現れである。

単位	却下の理由
画面単位	画面は設計の産物。UI変更のたびに要件文書が壊れる。機能同士の関係を画面経由で記述するため相互参照が増殖し、同じ情報の二重定義(→必ず食い違う)を招く
機能単位	「何のためにその機能があるか」の文脈が消え、網羅的な水増しを止める装置がなくなる
アプリ全体で1本	中規模以上でユースケースが20本近くになり、レビューが1回で回らない。小規模なら可
ユースケース単位	共有物(用語・業務ルール)の置き場がなくなり、二重定義が構造的に発生する

画面単位・機能単位の既存資産(画面仕様書・機能一覧)は捨てるのではなく、要件合意後の仕様層の文書として位置づけ直す。

1領域 = 海面ユースケース5〜10本、本文A4で5〜8枚。

これを超えて太る → 文書を割るのではなく、領域の切り方を疑う。2つのゴールが混ざっていないか(ユースケースの粒度が崩れている場合は「Fish の線引き」参照)
ユースケースが2〜3本しかない → 独立領域ではなく隣の領域への吸収を検討する。導線が未接続・提供時期未定の機能群は、領域として立てること自体を要確認にする

横断画面(ダッシュボード等): 領域にしない。各領域の要件(要対応事項の提示など)の実現手段として、全体要件書に位置づけだけ書く
編集画面・一覧画面: 領域の実現手段の一部。独立文書にしない
要求とのトレース: 各領域のユースケースは要求一覧の要求IDへトレースする(「要求フェーズの作成資料と情報項目」参照)。どの要求にも紐づかないユースケースは水増しの疑いとしてレビューで問う

この文書は誰の変更で書き換わるか。 領域単位の文書は、その領域の業務が変わったときだけ改版される。画面や実装の変更で要件文書が書き換わっているなら、単位か層のどちらかが崩れている(「層の越境パターン集」参照)。