設計書・仕様書の書き方が分かる!

 2023.02.10  株式会社システムインテグレータ

弊社では開発工程の上流である「要件定義、基本設計、詳細設計」において必要となるドキュメント標準が定義されております。本稿では「ドキュメント標準」の一部をご紹介しますので、是非ご参考にしてください。

各工程で必要なドキュメントを定義しましょう

下記のように工程ごとにドキュメント成果物、内容を定めております。
どの企業でも必要なドキュメント成果物になりますが、必要に応じて追加・削除頂ければと思います。
※業務系のシステム開発に照準を当てております。

設計書・仕様書の書き方が分かる! 0

要求分析(要件定義)

システム開発は要求分析(要件定義)というプロセスから始まります。要求分析(要件定義)は、顧客の要求を把握してシステム要件を確定することです。主に以下のような事項をまとめます。

  • 要求概要
  • システムの目的
  • 現状の課題と改善案
  • 基本要件と優先順位
  • 到達目標
  • システムの実現手段
  • システム化の範囲
  • 概略費用
  • 効果(定性/定量)
  • 体制図

設計書・仕様書の書き方が分かる! 1

大変な作業は要件を整理すること、可視化することです。そのためにブレーンストーミング、問題要因関連図やフィッシュボーンダイアグラム(魚骨図)の作成など様々な手法を使います。

要求仕様書の書き方は「IEEE830」で国際標準としても定義されています。しかし、標準規約のままだと網羅的で使いにくいので、これを参考にしながら実践的な内容のみを取り出し、上記のようなアウトプットを持つ「要求分析書」を標準ドキュメントとして定義しています。

基本設計

基本設計は主にユーザとの仕様確認を目的に、業務の整理やデータ、画面レイアウトなどの「枠組み」を設計する作業になります。こちらのドキュメントの作成にあたってのポイントを解説します。

業務フロー

業務システムを構築する際は、ユーザの 業務の流れを可視化して把握する必要があります。流れをイメージしないで断片の組み合わせで作成されたアプリケーションは、運用に大きな落とし穴がある場合が多いからです。業務に関して、自分の頭の中を整理し、ユーザと確認し、プロジェクトメンバーにも伝える、重要な役割を持ったドキュメントが業務フローです。

設計書・仕様書の書き方が分かる! 2

設計書記述様式

I/O 関連図や画面・帳票レイアウトのアイコン等に関する表記法を定めたものです。

設計書・仕様書の書き方が分かる! 3

機能一覧表

文字通り、開発対象となるアプリケーション機能を一覧にしたもので、 システム化の対象を明確に表す資料となります。

設計書・仕様書の書き方が分かる! 4

システム開発対象となる機能を洗い出して、大分類(サブシステム)、中分類(機能分類)ごとに整理して一覧表にまとめています。
また、機能ごとに画面入力、画面照会、帳票出力、バッチ処理の 4 種類に区分けをしています。機能一覧表は、システム化の対象を明確に表す資料となります。「機能一覧表」は、契約時に作成しておくドキュメントですが、下記のようにプロジェクトの段階でその情報が活用されますので、きちんと作成しましょう。

  • 見積:見積範囲の明確化と機能ごとの見積工数(金額)
  • 契約:開発範囲の明確化
  • 詳細設計:詳細設計書作業の進捗管理(担当者割当/予定・実績管理)

詳細設計

基本設計の後は、詳細設計を行います。基本設計は顧客向けにレイアウトなどの枠組みを作成したのに対し、詳細設計はプログラマへの説明向けにロジックなどの具体的な肉付けを行う作業になります。
詳細設計書の作成ポイントを解説します。

画面遷移図

文字通り画面の遷移(展開)を図で表したものです。下記は画面遷移図の記入例 です。
これを見ると各画面が、どのような遷移で呼び出されるかを直感的に理解できます。

設計書・仕様書の書き方が分かる! 5

詳細設計書

基本設計書で作成したドキュメントはそのまま(必要に応じて修正も加えて)利用され、さらに詳細機能を表すためのドキュメントを追加して「詳細設計書」となります。
まずは「項目説明書」を追加します。項目説明書は、基本設計で作成した画面/帳票レイアウトと対になるシートです。画面/帳票レイアウトは、 基本的にユーザのイメージ確認を主目的としますが、その情報だけでは画面を作成できません。そこで詳細設計フェーズで「項目説明書」を追加し、画面や帳票の各項目について必要な情報を記載します。

設計書・仕様書の書き方が分かる! 6

画面や帳票の項目名は、わかりやすい日本語名で記載します。これらの「項目名」は、実際の画面/帳票の「コントロール名」と対比します。この2つは、ER図におけるデータベース項目の論理名と物理名の関係に似ています。プログラミング設計書ではないので、設計書上にコントロール名までは記載しません。
コントロール名については、プログラミング規約を別途用意し、その中の命名規約に基づいてプログラマの裁量にまかせるという方針にしています。

本稿では抜粋したものを紹介しましたが、さらに詳しく確認したい場合、下記に「即活用できる!設計書の書き方講座」資料をご用意しましたので、是非ダウンロードして自社の生産性向上に役立ててください。

Object Browser 事業部


RELATED POST関連記事


RECENT POST「コラム」の最新記事


コラム

システム開発の手法とは?ウォーターフォールとアジャイル開発との違い

コラム

理想の設計書フォーマットを考える

コラム

これからのソフトウェア設計書に求められる書き方とは?

コラム

システム開発手順について押さえるべきポイント

設計書・仕様書の書き方が分かる!
新規CTA