見出し画像

外部設計書(基本設計書)の作り方

システム開発における外部設計書(基本設計書)の作り方について、まとめてみます。
文字だけだと分かりづらいので、個人的なメモ書きです。
機会があれば、テンプレートを作れたら良いなと思います。

大事なポイント

「相手に伝わっているか」
これに尽きると思います。

伝わるか、という意味では設計書はドキュメントなので、伝わりづらいと思います。
なんだか矛盾していますが、最低限必要な仕様をまとめておく必要はあると思います。

1.業務要件

ユーザーがシステムを開発したい目的、要件をまとめます。
システムを開発する際には、ユーザーの要件がベースになります。

・背景と目的
なぜシステム化が必要なのか?
システム化に何を期待するのか?

といったあたりを記載します。

・用語の定義
システムに関連する用語をまとめます。

・業務の概要
業務の概要は要件定義をして、ユーザーからヒアリングします。
業務要件定義書を作っていれば、そこから概要を記載します。

概要を記載するにあたっては、業務フローとその中でシステム化をする範囲、システム化する範囲については画面遷移図なんかもあると良いと思います。

2.システム機能

ユーザーからの業務要件をシステムの機能として落とし込みます。

・機能種別(画面、帳票、バッチ等)
・機能名
・処理概要
・利用者
・内容
などを記載する感じですかね。

3.画面

システムとして開発する画面を記載します。

画面ごとに以下のような項目を記載します。
・URLの形式
・画面レイアウト→別途、モックを作って、モックと紐付けて記載
・画面項目(種別、内容、データの取得元、データの保存先など)
・入力チェック
・イベント

4.バッチ

システムとして開発するバッチを記載します。

バッチごとに以下のような項目を記載します。
・処理フロー
・実行頻度
・実行時間
・処理詳細

5.データベース

システムとして作成するデータベースを記載します。

データベースごとに以下のような項目を記載します。
・テーブル名(論理、物理)
・型
・桁数
・キー
・NOT NULL
・初期値

また、想定データ量なども記載すると良いと思います。
ER図なんかもあると良いと思います。

6.外部インターフェース

外部とやり取りする場合は、インアウトそれぞれのインターフェースについて記載します。

インターフェースごとに以下のような項目を記載します。
・やり取り方法
・容量
・頻度
・インターフェース項目

インターフェースについては、どういう形式かによって、多種多様ですね。

7.帳票

PDFやファイル出力、印刷などがある場合は記載します。

帳票ごとに以下のような項目を記載します。
・出力方式
・容量
・頻度
・帳票項目

8.システム方式

開発するシステムの方式について記載します。

・インフラ
構築するインフラについて記載します。
また、構築するサーバーのスペックも、それぞれ記載します。

・使用ソフトウェア
名前、内容、バージョンなどを記載します。

・ドメイン
使用するドメインを記載します。

・サーバー構成図
使用するサーバーの構成図を記載します。

・サーバー接続方法
サーバーにどのように接続するか、を記載します。

・テスト環境
テスト環境について記載します。
本番環境との差異についても記載します。

・デプロイ方法
デプロイ方法について記載します。

・対応ブラウザ
動作対象として保証するブラウザについて記載します。

・開発手法
スクラッチ、カスタマイズなど、開発の手法について記載します。

9.性能要件

性能要件を記載します。

想定する最大量のデータで、どの程度の処理速度を想定するか、という点を記載します。

また、システムで扱うデータ量、PVなどについては、今後どのように増加することを予測するか、データ量が増加した場合に、今のこの性能(数値)なら大丈夫、ということを記載します。

この内容をもって、性能テストを行います。

10.セキュリティ要件

セキュリティに関する内容を記載します。

・認証
・権限制御
・データ暗号化
などについて記載します。

11.移行要件

システムを開発するにあたって、データを移行する場合は記載します。

12.運用要件

システムが稼働する時間などを記載します。
24時間常時稼働など。

定期メンテナンスを入れる場合は、日にちや時間などを記載します。

また、バックアップをどうやって取るかを記載します。

運用監視をするものがあれば記載します。

13.保守要件

個別にデータを保守するようなことがあれば記載します。

・データの更新
・コンテンツの更新
などを記載します。

問い合わせのフローについて記載します。
運用の各担当が誰で何をやるか、などを記載します。

まとめ

会社やプロジェクトでも、フォーマットや作り方は、まちまちだと思います。

こうやって記載する項目を並べてみると、たくさんあって大変という感じがします。
しかも、理解しやすければ良いですが、ドキュメントベースだと難しいのかもしれません。

そういう意味では、最低限のドキュメントは作るにしろ、アジャイル開発みたいに、ちょっと作って試して改善が良いのかもですね。
どちらもメリット、デメリットはあると思いますが。

僕も外部設計書を作る際には分かりやすいドキュメントになるように、頑張りたいと思います。

この記事が気に入ったらサポートをしてみませんか?