外部設計の3つの設計対象…機能・非機能・方式

こちらの記事では、外部設計について解説します。

外部設計とは

外部設計とは、ユーザーから見たシステムの振る舞いを決めることです。例えば画面や操作方法等です。

要件を達成できるように外部設計を行うため、外部設計の前に要件定義が行われます。しかし外部設計をする中で不足していた概念が発見されることはあるため、現実的には要件定義と外部設計は往復が起き得るでしょう。

IPAが要件定義の方法のベンチマークとして提供している「ユーザのための要件定義ガイド」において、「要件定義ドキュメント」として要件定義の成果物群が定められています。この中に一般に外部設計の成果物とされるものも一部含まれていますが、ここでは外部設計の一般的な定義の「ユーザーから見たシステムの振る舞いを決める」に当てはまるものについては、外部設計の成果物として取り扱います。

https://envader.plus/article/54

外部設計の設計対象は大きく分けて機能・非機能・方式です。

機能設計

機能要件を実現する挙動を決めます。

対象になるのは画面・バッチ・帳票・外部システムI/F・DBです。

• 画面設計

画面設計では、画面の仕様を決めます。

画面単体のみならず、画面間の遷移やUIのポリシー等の全体的な問題もここで取り扱います。

• バッチ設計

バッチとは、データ群を一括処理する機能です。画面からだとひとつひとつのデータについての操作をリアルタイムに行いますが、バッチでは複数のデータをあるタイミングでまとめて処理します。例えば月末にのみ利用するレポートがあり、そのレポートのためには常時利用されているデータ群をまとめて加工する必要がある時、バッチによって月末にそのデータ群をまとめて加工しレポートとして利用可能な状態にしたりします。

バッチ設計では処理の内容を決めることはもちろん、複数処理がある時はどういう単位でまとめるかやそれをいつ実行するのか等の運用面や、画面や他バッチからのDB更新と競合した場合にどうするかという排他制御検討、失敗した場合にどうするかという異常系の検討等もしなくてはなりません。

• 帳票設計

帳票とは、経営に関する書類です。伝票や売上表等です。BtoC向けWebサービス開発ではあまりかかわりのない概念かもしれませんが、業務システムでは重要な機能のひとつです。

帳票設計では帳票の表示の仕様を決めます。デザインや表示する情報等です。帳票はプリントアウトして業務で利用することもあり、それには業務の運用ルールも絡むため、ファイル形式や出力方法も問題になります。

• 外部システムI/F設計

外部システムI/Fとは、外部システムとのデータ連携のための接点です。I/Fはインターフェイスのことです。

開発対象のシステムは外部のシステムとやり取りをすることがあります。例えば決済部分だけ決済サービス事業者の機能を利用する等です。

外部システムI/F設計では、連携のためにタイミングやプロトコル、連携するデータ項目等を定めます。

• DB設計

DBの設計には段階があり、概念設計・論理設計・物理設計があります。基本設計では論理設計を行います。

論理設計では、概念設計で作成した概念モデルを論理モデルに変換します。概念設計では業務に必要な情報をエンティティ（DBで言えばテーブル）レベルで洗い出したものに過ぎず、論理設計でそれを、使用するDBに合わせた形式で属性（DBで言えばカラム）レベルも含めて詳細化します。

詳細は他記事をご参照ください。（参照先：DB分野におけるER図の書き方やツールについて＞論理モデル）

非機能設計

非機能要件を実現する仕組み・挙動・運用を決めます。

まずは仕組みです。非機能要件の多くはインフラレベルで実現される以上、インフラ周りの設計が中心となるでしょう。

次は挙動です。インフラレベルだけでは担保し切れない非機能要件もあります。特にセキュリティとパフォーマンスは、個々の機能レベルで検討する必要があり得ます。このように個別検討が必要な箇所の設計を行います。

最後に運用です。非機能要件の中には運用・保守性と移行性のように、システム面だけではなく、現実で人の動きとルールをどうするかも問題となります。要件レベルよりも具体度を高めて設計を行いましょう。

方式設計

方式設計では、アーキテクチャと開発規則を決めます。

アーキテクチャとはシステムの構造です。主にシステムの分割方法・分割されたコンポーネントの連携方法・分割されたコンポーネントの内部構造が問題になります。このアーキテクチャは、機能設計・非機能設計を、将来性を考慮した上でいかに効率的に実現するかが良し悪しの判断基準となります。

また、開発規則も問題となります。具体的にはコーディング規約等です。構造によって開発者側の行為を良い方向へ制御できるのが最も望ましい状態ではありますが、それにも限度があります。そのためルールによって開発者の行動を統制する面が現実的には必要です。