*本記事は旧TechblogからCOLORSに統合した記事です。
こんにちは！
エンジニアリングソリューション事業部のS.Rです。
今回は客先常駐の現場で活躍されている方から、
各種設計書の目的と構成について説明してもらったものを紹介したいと思います。
なお、今回ここで挙げた内容は一例であり、
設計書の体系や構成、呼び名は、開発手法や会社・プロジェクトなどによって変わります。
顧客の文化や開発現場の方針・状況に沿って、臨機応変に対応しましょう。
基本設計書(BD: Basic Design)
目的
要件定義書などに基づき、システム全体の仕様を定義します。
構成
- はじめに
- 関係文書
要件定義書や顧客打ち合わせ時の議事録など、本設計書を作成するうえで 関連性をもつ文書の名前を記述します。 - 用語の定義
基本設計書～詳細設計書内で統一する用語と、その意味・内容について定義します。 これにより、類似する用語の違いを明確にしたり、読者の認識齟齬を回避します。
- 関係文書
- 概要説明
開発するシステムの役割や目的を定義します。 - 要件
- 要件一覧
要件定義書で示されている要件を更に細かく分析し、次のような項目とともに
具体的な要件として定義します。
・背景、予測規模、重要度、実現時期など - 概念化
開発するシステムにどのような情報が存在していてそれらがどのように結びついているのか、
どのような役割をもっているのかを把握するため、UMLのクラス図を使用して表します。
- 要件一覧
- ユースケースモデル
- ユースケース
システムが利用者に提供するサービス(利用方法、運用等)をUMLのユースケース図で記述します。 - ユースケース記述
利用者が目的を達成するための、システムとのやりとりを記述します。 具体的な操作や処理を示すため、UMLのアクティビティ図、もしくはフローチャートで記述します。
- ユースケース
- 補足事項
上記の要件やユースケースより更に深く表現したい内容があれば、ここで補足します。 - 非機能要件
非機能要件、すなわち本来の機能要件以外の要件全般（拡張性、保守性、使用性、信頼性など） について定義します。 内容によっては図示化したり、実装する際の優先度も決めます。 - 注意・制限事項
注意事項（条件によりできる事）、制限事項（できない事）について記述します。
機能設計書(FD: Function Design)
目的
基本設計書に基づき、システム機能実現の方式を定義します。
構成
- はじめに
- 関係文書
基本設計書や議事録・検討メモなど、本設計書を作成するうえで 関連性をもつ文書の名前を記述します。 - 動作環境
システムが動作するハードウェアやOS、開発のために使用するソフトウェアを記述します。 - 非機能要件の実現方針
基本設計書で定義した非機能要件を実現するための方針について記述します。 - システム構造
システムの論理的な構造を、UMLのクラス図、コンポーネント図、パッケージ図などで定義します。
また、動的な振る舞いを示すため、UMLのシーケンス図やアクティビティ図も記述します。 - 機能説明
機能を実現するための処理を明確化して、各機能毎に分かりやすい言葉や図で説明します。 - 他システムへの影響
本開発が既存の他システムに与える影響の有無を調べて記述します。 - 外部インターフェース
画面、帳票、コマンド、メッセージなどの説明や使用用途について記述します。 必要に応じて、それぞれに特化した設計仕様書を用います（「画面レイアウト仕様書」など）。 - 注意・制限事項
注意事項（条件によりできる事）、制限事項（できない事）について記述します。
詳細設計書(DD: Detail Design)
目的
機能設計書に基づき、プログラム実装に紐づく情報を定義します。
構成
- はじめに
- 関係文書
機能設計書や議事録・検討メモなど、本設計書を作成するうえで 関連性をもつ文書の名前を記述します。 - 構造
機能設計で定義した論理的な構造を詳細化して、モジュール分割、モジュール間の 関連について記述します。 - 機能
機能設計で説明した機能単位毎に、実装に必要な情報を記述します。
エラーや例外発生時の処理も明確化します。
必要に応じて、次のような設計書と連携します。
・データベース設計書
・ファイル設計書
・テーブル設計書
・マクロ設計書
・トランザクション設計書
まとめ
いかがでしょうか。
設計書はほとんどのシステム開発において、基準となる土台のような物です。
ぜひ今回の記事を元にしっかりとした「土台」を作っていきましょう。
また今回の記事作成に協力していただいた方々、誠にありがとうございました。
