システム開発は「作るものを決める」工程と「作って届け、動かし続ける」工程からなる。 本ハンドブックでは前半の4つを 4層モデル と呼び、中心的に扱う。
この分類は本ハンドブックの独自定義であり、ISO/IEC/IEEE 12207(共通フレーム)・ISO/IEC/IEEE 29148・V字モデルなどを源流に実務向けへ整理したもの(後述「標準規格との対応」を参照)。
なぜやるか。ビジネスと業務の話であり、唯一システムの話をしない層。 主語はユーザーや発注者。背景・目的・成功基準(数値)・制約・スコープ外を明らかにする。
何を実現するか。要求を満たすためにシステムに求める機能・性質。 ここから主語が「システムは〜」になる。
どう振る舞うか。システムを外から見た振る舞いの取り決め。 入力・出力・条件・例外を定め、「正しい/間違い」を判定できる基準になる。
どう作るか。仕様を実現する内部構造と技術の選択。 ここで初めて実装の中身の話になる。
設計に従いコードを書く。決め事はコーディング規約・レビュー観点・ブランチ戦略として残す。 実装中に仕様や設計の矛盾が見つかったら、コードで勝手に解決せず上の層へ差し戻す。
作ったものが上の層の決め事どおりかを確かめる。検証対象は層と対応する: 単体テスト↔設計、結合テスト↔仕様、システムテスト↔要件、受入テスト↔要求(V字モデル)。
作ったものを利用者に届ける。手順の再現性と、失敗時に戻れることが要点。
動かし続け、問題から学ぶ。監視・障害対応・改善のサイクル。 ここで得た知見が次の要求の種になり、プロセスは一周する。
本ハンドブックの分類は独自定義だが、以下の標準・モデルを源流としている。
ソフトウェアライフサイクルプロセスの国際規格。開発だけでなく、企画・運用・保守・廃棄まで含むプロセス全体を定義する。IPAの「共通フレーム」はこれを日本向けに拡張したもので、日本のSIにおける工程分割(企画→要件定義→設計→実装→テスト→運用・保守)の事実上の出どころ。
要求の獲得・分析・記述に関する規格。要求を段階の異なる文書として区別する:
| 文書 | 内容 | 本ハンドブックでの対応 |
|---|---|---|
| StRS (Stakeholder Requirements) | ステークホルダーが何を必要としているか | 要求 |
| SyRS (System Requirements) | システムが何を満たすべきか | 要件 |
| SRS (Software Requirements) | ソフトウェアが何を満たすべきか | 要件〜仕様 |
英語ではいずれも requirements であり、「要求/要件」の訳し分けは日本語圏の工夫。この規格の「ステークホルダーの要求とシステムの要件は別物」という区別が、4層モデルの上2層の根拠になっている。
工程とテストレベルの対応関係を示すモデル。左辺(定義)と右辺(検証)が層ごとに対になる:
| 定義(左辺) | 検証(右辺) |
|---|---|
| 要求 | 受入テスト |
| 要件 | システムテスト |
| 仕様 | 結合テスト |
| 設計 | 単体テスト |
「各層はそれぞれ検証できる相手が違う」という4層モデルの根拠はこの対応にある。層を省くと、対応する検証が根拠を失う。
「仕様」を要件と設計の間の独立した層として立てるのは、外部設計(外から見た振る舞い)/内部設計(中身)という日本の伝統的な工程分割に由来する。海外では仕様(functional spec)を要件側に含めるか設計側に寄せるかは揺れており、独立層として扱うのはこのハンドブックの選択である。
なぜ 要求
何を └ 要件
振る舞い └ 仕様
作り方 └ 設計
└ 実装 → テスト → リリース → 運用 ─┐
なぜ(次) 要求 ←──────────────────────────┘