要件の種類と四層の対応 — ビジネス要件・業務要件・システム要件はどこに置くか

要件定義の書籍・現場では、要件を「ビジネス要件」「業務要件」「システム要件(機能/非機能)」に分類する流儀が広く使われている。本文書は、この分類とハンドブックの四層(要求・要件・仕様・設計)の対応を定め、他流派の用語を自分たちの体系に変換できるようにする。

結論: 分類としては採用しない。対応表で吸収する。 ただしこの分類が照らし出す欠落(非機能要件の置き場)は取り込む。

対応表

一般的な分類四層での置き場具体的な記載先
ビジネス要件要求要求一覧、全体要件の目的・前提
業務要件要件(の本体)領域別要件のユースケース・業務ルール・管理する情報
システム要件(機能)要件〜仕様要件側は受入基準に畳む。振る舞いの詳細は仕様書
システム要件(非機能)要件全体要件の非機能節(性能・可用性・セキュリティ・データ保全)。領域固有の性能は各領域の受入基準
実現方式・構成(アーキテクチャ)設計設計書。一般的な本でもこれを「要件」とは呼ばない

よくある誤解: 「システム要件=設計」ではない

「ビジネス=要求、システム=設計」という対応づけは半分だけ正しい。ビジネス要件=要求は正しいが、システム要件は要件〜仕様に跨るものであり、設計ではない。

混同の出どころは「システム」という語の二義性にある。

システム要件を設計に置くと、機能要件・非機能要件が「受注側の内部判断」の箱に落ち、客先の審査対象から外れる。特に非機能要件(性能・稼働時間・セキュリティ)は客先が決めるべき要件であり、この誤配置は検収時の争点を生む。

層の判定には分類名でなく、いつもの2つの問いを使う。

  1. 客先が業務の言葉で正否を判断できるか — Yes なら要件
  2. この記述が変わる理由は、業務の変化か、作り方の変化か — 作り方なら仕様以降

なぜ分類として採用しないか

  1. 境界が運用可能でない。 業務要件/システム要件の線は本によって引き方が揺れる。「客先が業務の言葉で判断できるか」という判定を既に持っている以上、曖昧な境界に乗り換える理由がない
  2. 二面記述を誘発する。 この分類で節を分けると、同じ事柄を「業務要件: 担当者は遅延に気づける」「システム要件: システムは遅延アラートを提供する」と両側から書くことになり、二重定義(→必ず食い違う)が構造的に発生する。ユースケース+受入基準の形式は、この二面を1箇所で表現している(ユースケースの主語は業務、受入基準はシステムの振る舞いを業務の言葉で判定する)

取り込むもの: 非機能要件の節

システム要件という分類が可視化する実在の欠落は、非機能要件の置き場である。対応は新しい分類の導入ではなく、全体要件書(または全体要件シート)に非機能の節を1つ追加すること。

非機能の項目置き場例
性能(全体)全体要件の非機能節通常操作の応答時間の許容
可用性・稼働時間同上業務時間内の稼働、障害時の復旧目標
セキュリティ同上アクセス制限、認証の失効
データ保全同上バックアップ、削除の復旧可否
性能(領域固有)各領域の受入基準「想定規模から対象を特定できる」
運用・移行全体要件または別文書初期データ投入、切替手順の要件

数値・水準はすべて発注者が決定するものであり、初版は要確認だらけのドラフトでよい。要確認として明示されていることが、確認されないまま実装される状態より価値がある。

使い方

まとめ

この記述は誰が審査するのか。 分類名が何であれ、客先が審査すべき記述が受注側の内部文書に置かれていたら、それは層の誤配置である。