システム開発の内部設計（機能設計）

内部設計では、開発するシステム自身をターゲットとした設計を行う。要件定義や外部設計とは違い、顧客企業や外部システム開発チームとの仕様調整は通常は行わない。外部システムと、開発するシステム（＝内部システム）との入出力インタフェースについては外部設計によって仕様が決定しているため、あとは内部システムの仕様を決めていくことになる。

内部設計の目的は、次フェーズの詳細設計を行うための仕様を決めることである。特に、機能設計やデータベース論理設計は、内部システムの仕組みや、取り扱うデータのあり方、管理方法などを決めることになり、これまでのシステムイメージを一気に具体化させる部分でもある。下流工程のエンジニアとしては、システム開発において、ここが一番の醍醐味になるかもしれない。

システムは、幾つかの機能に分割することが出来る。システムを機能によって分割することを、機能分割といい、次フェーズの詳細設計で行うプログラム分割の上位業務に当たる。　機能分割の単位は様々ではあるが、ある責任分解点に着目し、システムのメンテナンス性や障害の原因を特定しやすいように機能分割する必要がある。責任分解の観点は、機能分割に限った考え方ではなく、要件定義や詳細設計、ひいてはビジネスマンとしての基本的な行動基盤に通じるものである。　また、システムが非常に小規模で、システム自体が１機能と判断できる場合、機能分割を行わずに、詳細設計フェーズでプログラム分割を行えばよい。

1. 機能分割（内部設計）
2. プログラム分割（詳細設計）
3. モジュール分割（詳細設計）

機能設計書には、各機能の仕様を記述し、機能間のデータのやり取りや、システム内のデータの流れを示したデータフロー図を作成する。データフロー図を作成することによって、システム内の仕様の明確化と、矛盾（設計バグ）を洗い出すことが出来る。

画面設計を内部設計フェーズで行う場合があるが、そのやり方は今となっては古いと言わざるを得ない。当サイトでは、画面設計を外部設計フェーズで行うように解説している。これは、現在のシステム開発では、プロトタイピングが主流であり、リスクヘッジにもなるからである。内部設計フェーズで画面設計を行った場合、顧客と合意するタイミングはいつになるのだろうか。テストまで完了し、いざリリースしてみると、「こんな画面など使えない」などと言われても、クレームに返す言葉が無い。顧客との調整が必要な業務は、できるだけ早い段階で合意しておくことが重要である。

システム開発では、データ管理の方法としてデータベースを利用することが多い。データベースの代表的なパッケージとして、Oracleがあげられる。Oracleはデータベースのデファクト・スタンダードになりつつある。　データベース論理設計では、Oracleなどのようなパッケージに依存しない、データベースの論理構造に着目して設計を行う。設計の方法は主に、トップダウン・アプローチとボトムアップ・アプローチがある。

データベース論理設計を行う際は、トップダウンとボトムアップの双方向から設計を行う必要がある。これは、片方向だけでは見えない仕様を洩れなく汲み取れる効果がある。これらのアプローチから、ER図を作成する。　また、トップダウン・アプローチでは、要件定義や外部設計の記述に対して、言葉の解釈の仕方に個人差が生じるため、設計者によっては全く異なるデータベースモデルが設計される場合もある。一方、ボトムアップ・アプローチでは、画面や帳票などの具体的な仕様から言葉を抜き出すため、トップダウン・アプローチほどの個人差は生じない。 　なお、データベースモデルの正規化は、データベース物理設計で行う。正規化はデータベースの検索効率など、チューニングの側面を持っており、論理設計の段階では特に考慮する必要はない。