Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定)
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定)
🚧 SoE 向け(※追記予定)
このページについて
- ここでは、基本設計工程の成果物である基本設計書を定義し、果たすべき役割を定めている。
基本設計書(Base Design Document)とは何か?
基本設計工程の唯一の工程成果物
基本設計工程のすべてのプロセスとその成果物は、基本設計書に統合される。
1つのファイルにする必要はなく、基本設計書から各構成要素にリンク等でたどり着ければよい。
要件を実現するシステムの仕様書
要件定義書は「システムが達成すべき条件」を示すが、基本設計書は「要件を実現するためのシステムの仕様」を示す。
そのシステムが「なぜそのように作られたか」は要件定義書が示すが、そのためにシステムが、どのように作られ、何ができるかを示すのは基本設計書である。
基本設計書の役割
基本設計書は、その後の開発のベースラインである。次工程で開発すべきものを定義し、工数・スケジュール見積の基礎となる。
基本設計書は、システム開発プロジェクトにおいて、以下の役割を果たす。
- 要件の実現方針の具体化:要件をシステムとして「どのように実現するか」具体化し、実装とテストを可能にする。
- システム外部仕様の合意形成:ステークホルダー間でシステムの完成イメージを共有し、合意する。
- 開発・保守の基準:開発と将来の保守における基準(ベースライン)。次工程で発生した基本設計書の内容との差異は変更管理対象になる。
要件の実現方針の具体化
基本設計書は、要件定義書で定められた要件を達成するために、システムがどのような振舞いや構造を持つべきか、その具体的な仕様を定める。
- 果たす役割
- システムの実装とテストを可能にする。
- 設計通りに構築されたシステムが要件を実現することを保証する。
- 果たされない場合のリスク
- チームによる開発が困難になる。
- 要件との不整合や漏れが生じ、実装後の手戻りや品質低下につながる。
システム外部仕様の合意形成
基本設計書は、システムの外部仕様(画面や帳票など)を明示し、完成形を顧客と共有する。
- 果たす役割
- 画面デザイン・機能・構造を可視化し、顧客と開発側が同じ完成イメージを持てるようにする。設計内容の妥当性を確認する。
- 顧客内部の担当者、ユーザー部門、決裁者の間でシステムの完成形を共有し、合意を得る資料となる。
- 次工程では、開発者は基本設計書の仕様に基づいて、顧客に確認することなく開発を完了できなければならない。
- 果たされない場合のリスク
- 顧客との認識齟齬により、「想定と違う」「仕様誤解」といったトラブルや追加工数が発生する。
- 顧客内部の認識齟齬により、ユーザー部門に受け入れられないトラブルが発生する。
開発・保守の基準
基本設計書は、詳細設計・開発・テスト・保守の共通基盤として、設計意図と構造を文書化し、継続的な品質維持と変更管理を可能にする。
- 果たす役割
- 詳細設計・実装・テスト工程において、システムの仕様を参照する基準点となる。
- 保守・運用フェーズにおいて、システムの設計意図を理解し、適切な変更判断を行うための基盤となる。
- 仕様変更が発生した際、影響範囲を特定し、変更管理を行うためのベースラインとなる。
- 果たされない場合のリスク
- 開発や保守時の判断が属人的となり、品質のばらつき・障害多発・保守困難が生じる。
- 仕様変更の影響範囲が不明確となり、意図しない副作用や機能劣化が発生する。
次のページ → 📄基本設計書の完成条件