ハートテクノロジーズ株式会社 & メタバースアカデミー

システム開発において要件定義の後工程である基本設計と詳細設計について解説します

LINEで送る
Pocket

はじめに

 

この記事では、システム開発における要件定義の後の設計工程について解説します。

図において、要件定義の次の工程が基本設計、そのあとが詳細設計になります。基本設計と詳細設計に区分けするのが一般的です。それでは順番に基本設計、詳細設計について解説していきましょう。

 

基本設計について

基本設計とは?

システム設計、外部設計という場合もあります。前工程の要件定義で定義したWHAT、即ちシステムを実現するための内容を具体的にHOWに落とし込む工程が基本設計になります。

 

すなわち、要件定義で発注側が求めるものをシステムを作る側=開発委託側の立場で定義づけた内容を踏まえて、システム全体の設計を行うのが基本設計の工程になります。

 

著者の経験では、基本設計という場合と、システム設計という場合が半々かと思います。外部設計という言葉は、外部=発注側が見てもわかる部分の設計ということになるのですが、あまり使われません。

基本設計で行う作業

作業全体としていえることは、外部から見てこのシステムがどういう動きをするのかを出来る限り見える化するのが基本設計になります。

 

作業自体は開発委託側が行うわけですが、この基本設計の内容は発注側の立場でわかりやすくなっているのが良い設計ということになります。

 

具体的には、一番初めに要件定義でもまとめていることが多い機能一覧をブラッシュアップします。

 

その上で、機能のなかでの動作の流れ、データ構造の概要、組み込みシステムではシステム構成図、ブロック図、ネットワークが関係するシステムではネットワーク構成図などを作成していきます。

 

そして今後の詳細設計以降の工程に向けた開発スケジュールを詳細化するのも基本設計で行う作業になります。

 

基本設計での成果物

基本設計全体の成果物名としては、基本設計書、システム仕様書という場合が多いです。

 

この基本設計書、システム仕様書の中に以下のような記述をする必要があります。

 

機能一覧表、機能説明

ネットワーク構成図、システム構成図

(組込みシステムについては)ハードウエアブロック図

(画面があるものについては)画面表示遷移

動作の流れ概要

データ構造概要

開発スケジュール

 

詳細設計について

詳細設計とは

プログラム設計、内部設計という場合もあります。

 

筆者の経験では、詳細設計と言う場合とプログラム設計と言う場合が半々であり、内部設計と言う場合は少ないです。

 

詳細設計では、基本設計で検討した概要に基づいて、実際にソフトウエアのプログラムが作れるように設計を詳細化することが重要なポイントになります。

詳細設計で行うこと

 

発注側、即ち顧客の立場だと外側に見えない内容を設計する作業になります。

 

従って発注側がシステム、ソフトウエアの知識経験が少ない場合は、詳細設計の中身については理解しにくいものであることは否めません。

 

だからといって発注側が詳細設計をないがしろにすると、そのあとの実際のプログラミング=ソフトウエアの実装、製造の品質が低下しますので、詳細設計は非常に重要な工程になります。

 

具体的には、基本設計での成果物を元にして、データ構造の詳細化、制御内容の詳細化、OSを搭載したシステムの場合はタスク分割(OSレスの場合も機能分割)などを行います。

 

必要に応じて状態遷移図・状態遷移表 およびデータフローダイヤグラムの設計を行ったうえで、最終的には各タスクの中野モジュールの処理設計書やデータ(テーブルという場合の方が多いです)構造設計書などを作ることになります。

 

詳細設計での成果物一覧

以下のようなものを作る必要があります。

 

データ(テーブル)構造詳細設計書

状態遷移図、状態遷移表

タスク構成図

タスク毎の処理設計書(フローチャート等含む)

モジュール関連図

モジュール仕様書

 

まとめ

今回はシステム開発における基本設計、詳細設計について解説しました。

 

システム開発において、もっともよく考えてち密に行う作業がこの基本設計、詳細設計になるかと思います。

 

開発委託側の場合はまさに自分たちでこの工程をきちんと行ってそれを発注側に報告して次のソフトウエア実装工程に移る必要があります。

 

一方、発注側は、ここでの作業自体は完全に開発委託側に任すものの、この設計での完成度がどのくらい高いかをレビューの中で十分に検証する必要があります。

 

基本設計の成果物について十分にレビューをすることを強くおすすめします。

 

基本設計成果物であれば発注側でシステム、ソフトウエアの詳細がなかなか理解できない方でも十分に理解できる内容になっているはずです。

 

逆に理解できない内容になっているとしたら、委託側に修正を要求するべきです。

要件定義のレビューが重要であると共に、基本設計のレビューにも是非力を入れてください。

 

 

今回の記事が基本設計、詳細設計を進めるのに役立てば幸いです。

 

関連記事一覧

要件定義とは何か?MECEとの関係や、要求定義との関係を解説します

要件定義の流れと、要件定義書の作成の仕方

システムの要求定義~開発設計におけるレビューの重要性について

システム開発の要件定義~開発設計におけるレビューの具体的なやり方について

 

システム開発設計全体の流れ~要件定義、設計、実装、テストまで~および発注側と開発委託会社の役割分担について

システム開発での要件定義と基本設計の違い及び要件定義の作業内容について

システム開発において要件定義、設計と共に重要なテスト計画、テストの進め方について

システム開発で要件定義~設計を任せる開発委託会社の選択方法

要件定義~設計~テストというシステム開発プロジェクトを推進するうえで重要なこと

コメントは受け付けていません。

LINEで送る
Pocket

IoT関係でお悩みの企業様、独立して顧問へなりたい方、経験豊富な当社がサポートいたします!

お気軽にご相談下さい お気軽にご相談下さい arrow_right
PAGE TOP