◀ 2.

基本設計

▶
編集

本稿は 基本設計 (BD: Basic Design) に関する記事です。基本設計は 要件定義 の次に位置し、「ユーザから見えるシステムの仕様」 を確定する工程です。外部設計 (External Design) とも呼ばれます。

基本設計の位置づけ

工程視点典型的な成果物
要件定義 (RD)「何を実現するか」要件定義書・機能一覧・非機能要件
基本設計 (BD)「ユーザから見たシステムの形」画面遷移・画面定義・帳票・I/F・テーブル定義
詳細設計 (DD)「内部でどう作るか」モジュール構造・クラス図・処理フロー
実装コーディングソースコード
単体テスト関数・クラス単位の検証UT 仕様書・結果
結合・総合テスト機能間連動・システム全体IT / ST 仕様書・結果
受入・運用テストユーザ視点の最終確認UAT 仕様書・運用手順

基本設計で決めること

カテゴリ主な内容
システム方式サーバ構成 (Web/AP/DB)、冗長化、クラウド／オンプレ、ミドルウェア選定
画面画面一覧・画面遷移・画面イメージ (ワイヤーフレーム)・項目定義
帳票・出力帳票一覧・レイアウト・出力タイミング・形式 (PDF / CSV)
外部インタフェース連携対象・データ形式 (CSV / JSON / SOAP / REST)・通信タイミング・認証
バッチバッチ一覧・起動契機・処理概要・リカバリ方式
データベースER 図・テーブル定義 (論理／物理)・キー・命名規約
権限・セキュリティユーザ種別・ロール・操作権限・データ参照範囲
運用設計監視・ログ・バックアップ・障害時運用・夜間バッチ
性能設計SLA・想定 TPS・想定データ量・キャッシュ方針
移行既存データの移行方式・件数・カットオーバ手順

主な成果物

  • システム方式設計書 — サーバ・NW・ミドルウェアの全体構成
  • 画面一覧 / 画面遷移図 / 画面定義書 — ID 付きで管理
  • 帳票一覧 / 帳票定義書
  • 外部 I/F 定義書 (CSV / API)
  • バッチ一覧 / バッチ処理概要
  • ER 図 / テーブル定義書 / コード値定義
  • 権限マトリクス
  • 運用設計書 (監視・障害・バックアップ・リリース)
  • 移行設計書
  • 命名規約 / コード規約

画面定義書の典型項目

項目内容
画面ID / 画面名命名規則に従い一意
画面イメージワイヤーフレーム / モックアップ
表示項目一覧項目名・型・桁・必須・初期値・編集可否
入力チェック必須・桁・文字種・範囲・相関チェック
ボタン動作遷移先・確認ダイアログ・サーバ処理概要
権限表示可・操作可となるロール
関連 API / SQL 概要裏で呼ばれる処理の概要
エラーメッセージメッセージID と文言

詳細設計との切り分け

項目基本設計詳細設計
視点ユーザ・運用者から見える内部実装
画面遷移図・項目一覧・チェック概要処理ロジック・状態遷移・モジュール構造
DB論理 ER・テーブル定義物理 DDL・インデックス・パーティション
APII/F 定義 (リクエスト/レスポンス)実装クラス・例外処理
性能SLA・想定値キャッシュ実装・チューニング

レビュー観点

  • 要件とトレーサビリティが取れているか — 機能ID ↔ 画面ID ↔ テーブルID
  • 欠落・矛盾がないか — 画面間の引き渡し項目、コード値の網羅
  • 非機能要件が反映されているか — 性能・可用性・セキュリティ
  • 運用シナリオを想定したか — 障害・夜間バッチ・閉塞時の挙動
  • 移行・並行運用の手順が現実的か
  • 命名規約・コード規約が決まっているか

注意点

  • 「基本設計＝画面と帳票」になりがち — バッチ・I/F・運用が抜けやすい
  • テーブル定義を後回しにしない。データ構造は後工程で変えると影響が大きい
  • ステークホルダの承認を必ず文書で残す
  • アジャイル開発では、基本設計をドキュメント主導ではなくユーザストーリー + プロトタイプで進めることが多い
  • 変更管理を導入。仕様変更は履歴を残し、影響範囲を必ず洗い出す

関連

編集
Post Share
子ページ

子ページはありません

同階層のページ
  1. 要件定義
  2. 基本設計
  3. 詳細設計
  4. 製造
  5. 単体テスト
  6. 結合テスト
  7. 総合テスト
  8. 受入テスト/運用テスト
2026-05-13 08:47:19 atom 300

人気ページ

最近更新/作成されたページ