今回、まとめるにあたっては私の経験だけでは偏ってしまうため、システム設計のセオリー赤 俊哉 (著)をベースに、要件定義、設計工程の進め方を整理し、不足していると思われる工程を追加したり、各工程に対して私の解釈を交えたりして整理したいと思います。
システム開発における上流工程、とりわけ、要件定義から外部設計までの一例の流れを整理するとともに、どのタイミングで何を決め、どのような成果物を作成していくべきなのかを整理していきます。
参考文献は、システム設計のセオリー赤 俊哉 (著)になります。
本書に沿ったタスク及び成果物は黄色下線で表現し、筆者独自の内容については青色下線で表現しています。
今回の内容が、上流工程を実施するうえでの参考になれば嬉しいです。
上流工程（要件定義、外部設計）の進め方
まず、上流工程全体の工程定義をします。ここでは、本書で取り上げられている工程定義とよく一般的に言われるウォーターフォールモデルの進め方になぞって定義してみます。
本書では、上流工程を４つの分類に分けているのでまずはそちらを紹介します。
プロジェクトの工程定義は様々あるため、１つの物差しを用意しなければ、どのタイミングで何を決め、どのような成果物を作成していくべきなのかの前提が狂ってしまいます。本記事では、システム設計のセオリー赤 俊哉 (著)の上記の切り口を参考にして、それぞれのタイミングで何をすべきか整理したいと思います。また、各工程で作成すべき成果物についても、システム設計のセオリー赤 俊哉 (著)を基本としつつ、私の経験上、追加した方が良いと考える成果物についても挙げていきます。
システム設計のセオリー赤 俊哉 (著)では、ここで挙げる工程よりも多くの工程を設けて検討されていますが、私の経験と一致しない工程については省略し、最低限遵守すべき工程に特化した整理をしたいと思います。
今回の工程定義と、各工程における成果物を１つの図にまとめた図がこちらになります。
要件定義の進め方
まずは、要件定義工程、システム設計のセオリーでいうL1工程に当たります。この要件定義は誰がやるのかとしばしば議論になりますが、要件定義は発注者側が主体となって実施する工程です。
この工程では、開発するシステムの基本となる姿を形作ります。したがって、システムを作りたい側の発注者が責任をもってどんなシステムを開発したいか明確にします。システム開発ベンダーは、そのお手伝いをするというスタンスになります。
私の経験から強くお伝えしたいポイントは、いきなり本丸を作りこむのではなく、”まずは全体像をぼんやりとでも描いてみる”という姿勢が重要だということです。
要件定義工程の成果物
要件定義工程では、主に次のようなドキュメントを作成することで、開発するシステムの基本要件を整理します。
・システム全体図 （＝概観業務フロー（ビジネスプロセス関連図））
本書での当工程の定義、目的は次の通りです。
対象となりうるシステムの全体像を把握する
システム設計のセオリー赤 俊哉 (著) 2.1.2設計範囲全体を把握しよう！
この時点で、サブシステム単位に分けておくことの方が私の経験上は多いです。したがって、概観業務フロー（ビジネスプロセス関連図）とも呼ぶことができると思います。今回のプロジェクトのスコープに当たります。
サブシステム構成図の重要性はこちらも合わせてご覧ください。
・非機能要件定義書（信頼性、性能、セキュリティ要件も含むとする）
本書での当工程の定義、目的は次の通りです。
早い段階から非機能要件を検討し、方向性を確認する
システム設計のセオリー赤 俊哉 (著) 2.1.4非機能要件の概要定義
非機能要件要件は現行システムをベースに洗い出すことを私はお勧めします。発注者側の情報システム部門が主体となって洗い出しますことが通例です。
・概念データモデル （＝概念ER図）
本書での当工程の定義、目的は次の通りです。
概念データモデルを作成することにより、データ構造の「見える化」を実現するとともに、ビジネスの全体像と静的側面の概要を把握する
システム設計のセオリー赤 俊哉 (著) 3.1.1概念データモデルをつくろう！
システム開発の対象となるエンティティ（発注、受注、取引先etc）を洗い出します。
・ToBe概要業務フロー（＝業務フロー）
本書での当工程の定義、目的は次の通りです。
ToBe概要業務フロー図を作成することにより、新システム稼働時のプロセスモデルの全容を把握できるようにする
システム設計のセオリー赤 俊哉 (著) 4.1.1ToBe業務フローの概要を定義しよう！
業務フロー（プロセスフロー）とも呼ばれます。私としての定義は、システムという手段に縛られない、業務の本質的な流れを明確にすることとしています。
そもそも業務フローとは何か、どういう種類があるのか知りたい方はこちらも合わせてご覧ください。
・設計標準（開発標準）
本書での当工程の定義、目的は次の通りです。
設計を行う際の「標準規約」を定める
システム設計のセオリー赤 俊哉 (著) 2.1.3設計標準をつくろう！
システム全体にかかわる開発規約を事前に整理しておきます。
また、UI標準をはじめ、システム全体にかかわる挙動（検索画面から照会画面に遷移した時の動き、また戻った時の動き、タブ順、メッセージ表示ルールなど）を定義しておくイメージです。
・外部IF要件定義書
本書での当工程の定義、目的は次の通りです。
開発予定のシステムがカバーする範囲を明確にし、外部システム等とのインタフェース要件を把握する
システム設計のセオリー赤 俊哉 (著) 3.2.1外部インターフェースの要件を明確にしよう！
いまどきの開発するシステムが別のシステムと連携しないということはまずあり得ません。したがって、そのシステムが他システムと繋がる時の基本ルールを明確にします。ここでは、接続先システム、連携目的、連携の方向、主要項目(主キーや集約単位)）を明確にしておきます。
システム全体図と照らし合わせて、外部システムとの繋がりを確認していくと、抜け漏れを防ぐことができるためお勧めです。
・ハードウェア構成要件書、移行要件書（＝インフラ構成要件定義書）
本書での当工程の定義、目的は次の通りです。
システムの基本構成とシステム移行に関する要件を早い段階から明確にする
システム設計のセオリー赤 俊哉 (著) 2.2.2システムインフラの構成を考えよう！
非機能要件定義書に従って、ハードウェア、ネットワーク、ソフトウェア（ミドルウェア）として必要なスペック（仕様）を定義します。
また、本番移行に向けた移行要件を定義します。移行と言っても、業務移行、データ移行、システム移行と３つのレイヤーがあります。それぞれにおいて、方式、対象、回数などを決めます。また、本番稼働後の運用要件（運用体制、保守時間、運用手順書、運用ツールの必要性など）を整理します。
・運用要件書、信頼性要件書など
本書での当工程の定義、目的は次の通りです。
アプリケーション設計とはやや距離のある事柄について、早い段階から検討を行い、要件を明確にしていく
システム設計のセオリー赤 俊 (著) 2.2.3運用まわりの要件を考えよう！
特に、システム本番稼働後の運用方法について、運用要件書で定義しておくことが重要です。運用要件に沿った取り組みは以降では取り上げませんが、運用要件についても安定した本番稼働を見据えて、運用設計を後続で実施してくこととなります。
外部設計(前半)の進め方（論理設計）
続いては、外部設計工程、システム設計のセオリーでいうL2工程に当たります。
私の経験上も、この工程で実施する内容を、「要件定義」と位置付けるプロジェクトも、「外部設計」と位置付けるプロジェクトも両方ありました。システム設計や概要設計という名を付けて要件定義や外部設計とは別工程として切り出すプロジェクトもあります。もしくは、先ほどの要件定義工程を、要求分析および業務要件定義と位置づけ、この工程からシステム要件定義と呼ぶ場合もあります。
いずれにしても、先ほどの要件定義工程よりももう一段、システムよりの検討に入っていくこととなります。そして、システム開発における最重要工程だと言ってよいでしょう。
私の経験上、ここまでを要件定義工程と位置づけることが多いと感じます。そのため、この工程の目標として、最終的なプロジェクトの開発規模のブレ現時点が±10%に以内に収まるように開発するシステムの要件や仕様を詰めていくことを意識するとよいです。逆に、10%以上誤差がでる可能性がまだ残っている場合にはそれは、まだ検討が足りていないと判断するとよいです。
また、外部設計工程（前半）の中でも、特に先に実施すべきタスクと先んじて実施したタスクの成果物をもとに後ろで検討するタスクとに分けた方が実際のプロジェクトではうまく進むと私は考えるため更に細分化して整理してみます。
外部設計工程(前半)の成果物
外部設計（前半）の更に前半で実施する成果物
・ToBe業務フロー詳細（＝システム化業務フロー、システムフロー）
本書での当工程の定義、目的は次の通りです。
ToBe詳細業務フロー図を作成することにより、新システムのプロセスモデルを確定する
システム設計のセオリー赤 俊哉 (著) 4.1.2ToBe業務フローの詳細を定義しよう！
ここでいう業務フローとは、システム化業務フロー（システムフロー）です。この工程では、システムと業務の繋がりがわかるような業務フローを描きます。どの業務の時にどういう機能を使うかを明確にします。
私のプロジェクトでも再三注意を図っていますが、バッチ処理といった日次、週次、月次、四半期といった一定サイクルで動くような機能や、外部システムとのIFについても業務フローの中に描くことを忘れてはいけません。
業務フローの詳細について詳しく知りたい方はこちらをご覧ください。
・プロセス概要定義書（＝業務要件定義書）
本書での当工程の定義、目的は次の通りです。
プロセス概要を定義することにより、新システム稼働時の業務プロセスの存在意義を明確にする
システム設計のセオリー赤 俊哉 (著) 4.1.4業務プロセス個々の概要を定義しよう！
5W2Hで業務を整理します。業務の単位の切り方は様々ですが、ToBe業務フロー詳細で定義される各プロセスをある程度まとめた単位と考えると良いです。例えば、会社として販売価格はどのように決めるのかや、注文書の発行にかかる決裁ルール、品質管理上の点検ステータスといったシステムで実現したい業務のあるべき姿を定義します。これらは業務要件定義書という形でまとめていきます。
私の経験上、業務要件は、発注者側が整理する必要がありますが、その内容をまとめてベンダーがドキュメント化することが多いです。
・AsIs業務フロー図（＝AsIs分析）
本書での当工程の定義、目的は次の通りです。
AsIs業務フロー図を作成し、現状分析を行う
システム設計のセオリー赤 俊哉 (著) 4.1.3AsIs業務フローを分析しよう！
AsIs分析のやりすぎには要注意です。したがって、ポイントを絞って分析することが重要です。システム設計のセオリー赤 俊哉 (著)では、非機能要件、データ構造、コード体系に絞ってAsIs分析すると効果的だと述べられていますが、私も同意です。
ここに加えて、AsIs業務の中で、絶対に維持しなければいけない要件（法令順守要件、業界・会社規定のルールなど）がないか、刷新対象のシステムが現行どのシステムと連携しているかを分析、調査することもおすすめです。この内容をもとに、業務要件定義書の検討や、IF概要定義を進めることができます。
AsIs分析の活用方法についてもっと知りたい方はこちらをご覧ください。
・プロトタイプ検証（★筆者独自）
ToBe業務フロー詳細や業務要件定義を作成し、ToBeの業務の姿が明確になった後、プロトタイプ検証を行います。システム設計のセオリー赤 俊哉 (著)では謳われていませんが、ERPパッケージシステムを導入するような場合や、モック画面を作成した検討をする場合は、このタイミングで実施すると良いです。
業務フロー図や業務要件定義書といった文字面で確認した内容を実機画面を見ながら確認をし、追加要件がないかを確認していき、新たな要件として拾っていきます。
・画面UIラフデザイン（＝画面イメージ）
本書での当工程の定義、目的は次の通りです。
おおまかなUIを含む画面イメージを共有することにより、該当業務プロセス、機能のデザインイメージ、必要項目の早期把握を可能にする
システム設計のセオリー赤 俊哉 (著) 4.2.1画面のラフイメージを考えよう！
開発する画面をラフ図で描きます。この後の工程で、画面項目を確定させるための画面・帳票詳細定義は行う予定ですが、主要項目や主要イベント、画面遷移くらいは定義しておく感じでよいと思います。システムの骨子を形成します。
・プロセス詳細定義書（機能定義書） （＝業務プロセス詳細定義）
本書での当工程の定義、目的は次の通りです。
プロセスの詳細定義を行うことにより、必要とされる機能と使用項目を確定する
システム設計のセオリー赤 俊哉 (著) 4.2.2業務プロセス個々の詳細を定義しよう！
業務要件定義では業務を定義しましたが、業務プロセス詳細定義では機能を定義します。私の経験上、ベンダーが主体となって、発注者側が実現したい業務をシステムで実現するために必要となる機能を整理します。
この段階で、サブ画面や子画面も含めたすべての機能を洗い出します。そのため、私のプロジェクトでは、画面・バッチ一覧（システム機能一覧）を作成し、開発工数を見積もるための機能数の母数を明確にします。
・データフロー設計（★筆者独自）
システム設計のセオリー赤 俊哉 (著)では、謳われていませんが、データフロー設計もこのタイミングで実施するべきだといえます。データフロー設計とは、各機能同士のデータの流れを設計するものです。具体的には、例えば、親会社と子会社の２社にシステム導入する場合に、親会社で発注登録したデータは子会社側に連携され、子会社で受注データとして受信するといった場合に、どういったデータの繋がりとなるかを検討することです。
これ以降の工程になると、個別の機能（発注画面や受注画面）ごとの検討になるため、全体を俯瞰しての横断的な検討はこのタイミングで実施すべきと考えます。
外部設計（前半）のうち後半で実施する成果物
・外部IF概要定義書
本書での当工程の定義、目的は次の通りです。
外部インターフェースを項目単位まで確定し、連携方式を検討する
システム設計のセオリー赤 俊哉 (著) 3.3.2 外部インターフェースの概要を定義しよう！
外部IF要件定義書から更に詳細化していきます。ToBe業務フローや業務要件定義、AsIs分析の結果を受けて、外部システムとの必要な連携イメージを持つことができます。
したがって、業務上必要な連携タイミングや連携に必要な項目を定義すると記されています。さらに、連携項目をここで定義するため、論理データモデル上に不足があれば適宜追加を行い整合性を保ちながら整理が必要です。
・画面・帳票概要定義書（入出力定義書） （＝画面・帳票項目定義書）
本書での当工程の定義、目的は次の通りです。
画面・帳票の概要を定義することにより、画面・帳票の入力要件・出力要件を明らかにしていく
システム設計のセオリー赤 俊哉 (著) 5.1.1 画面・帳票の概要を定義しよう！
一般的に言われる外部設計工程にて画面定義する作業にあたります。後続の工程で、画面・帳票詳細定義もありますが、この段階で８割確定させ、後続では横断的な確認をするイメージとなります。
外部設計ですので、画面や帳票に対するインプット項目とアウトプット項目をそれぞれ定義します。画面項目はもちろんですが、インプットの仕方、アウトプットの仕方についても定義します。これらは、画面イメージをもとに作成します。画面項目や帳票項目に不足があれば、ここでも論理データモデルに追加をします。
画面・帳票定義で実施することを図解するとこのようになると考えられます。
もちろん、設計標準で決めたUI標準も考慮したうえで画面設計を行うこととなります。
システム設計のセオリー赤 俊哉 (著)では、編集仕様、導出項目の計算方法、チェックし様（フォーマット、必須、任意、最大最小、相関チェック）について定義するとされていますが、私も完全に同意です。
・バッチ概要定義 （＝バッチ処理定義書）
本書での当工程の定義、目的は次の通りです。
バッチ処理の概要を定義することにより、その入出力要件を明らかにしていく
システム設計のセオリー赤 俊哉 (著) 5.1.2 バッチ処理の概要を定義しよう！
画面・帳票定義と同じように、バッチ処理についてもインプット項目とアウトプット項目を定義します。
外部設計（前半）を横断して作成する成果物
・論理データモデル
本書での当工程の定義、目的は次の通りです。
論理データモデルを作成することにより、データ要求と静的ビジネスルールを把握する
システム設計のセオリー赤 俊哉 (著) 3.1.2 論理データモデルをつくろう！
このシステムで扱う全属性を定義します。
論理データモデルは、これ単体で検討するものではなく、画面・帳票定義やバッチ定義、プロトタイプ検証とった他の成果物と同時並行に進めます。例えば、画面・帳票定義で、必要な画面項目が増えたら、属性としては１つ追加しなければいけませんし、プロトタイプ検証で標準パッケージシステムでは装備していない項目が業務要件として必要となれば項目を追加しなければいけません。
したがって、ポイントは、他のタスクと並行しながらこの工程全体を通じて徐々に育てていくということだと意識してください。
外部設計(後半)の進め方（物理設計）
続いては、外部設計工程の後半に当たります。システム設計のセオリー赤 俊哉 (著)でいえば、ここからが物理設計と呼ばれています。つまり、どのようにシステムを実現していくかということを考えていきます。
この段階から早速、内部設計だと呼ぶ方も私が経験したプロジェクトの中にはいました。
この工程の基本スタンスは、要件定義及び、外部設計（前半）で検討した内容を確定していくことにあると考えると良いと思います。
この外部設計工程（後半）も、（前半）と同じく先んじて実施しておいた方が効率がよいタスクと、先行して実施したタスクの成果物を受けて検討した方がよいタスクとがあるため、私の方で更に細分化して整理してみました。
外部設計工程(後半)の成果物
外部設計（後半）の更に前半で実施する成果物
・コード設計
本書での当工程の定義、目的は次の通りです。
コード化が必要な属性を抽出し、コード体系を決定する
システム設計のセオリー赤 俊哉 (著) 3.1.4 コードを設計しよう！
外部設計工程(前半)で実施したAsIs分析の結果をもとに、ToBe（あるべき姿）におけるコード設計を行います。ここでいうコード設計とは、「コード」と「名称」で表現されるようなもので、画面内のリストボックスの選択肢やラジオボタンによる選択結果になりうるものです。
例えば、受注キャンセル理由などを選択する場合は、「1：営業の対応ミスの為」「２：納期遅延の為」などといったように、男女を選択する場合には「１：男」「２：女」「３：その他」といったようにコードとそれに伴う名称を決めます。都道府県などであれば、国土交通省が定めるPrefCodeが存在するため、そちらを活用します。
「コード」と「名称」に対して更に、何かしらの意味合いを持たせたり、従属項目が続き、選択肢によって挙動が更に変わるような設定をする場合には、そちらは、マスタ設定として実施することとなる解釈です。
以下、私の解釈に基づく、コード設計とマスタ設定の違い図解にて解説します。
・画面・帳票詳細定義書
本書での当工程の定義、目的は次の通りです。
画面・帳票およびUIの定義を確定する
システム設計のセオリー赤 俊哉 (著) 5.2.2 画面・帳票の詳細を定義しよう！
システム設計のセオリー赤 俊哉 (著)では、上記の通り「画面・帳票およびUIの定義を確定する」と記されており、「画面UI、画面遷移、項目、イベントを確定する」工程とし、後述する機能詳細定義書（BL設計）よりも後に実施することになっています。ただ、私は、機能詳細を確定させるより先に、画面項目などについては確定させておいた方が実施しやすと考えています。
画面遷移、イベントについてはこの時点ですべて確定させます。
項目についても、外部設計工程(前半)で８割確定させていましたので、全項目確定させつつ、チェック仕様や編集仕様に関しての抜け漏れがあれば、この工程で是正し、完全なものを作りこみます。
・バッチ詳細定義書
本書での当工程の定義、目的は次の通りです。
バッチ処理の詳細定義として、その入力要件と出力要件を具体的に定義する
システム設計のセオリー赤 俊哉 (著) 5.2.3 バッチ処理の詳細を定義しよう！
画面・帳票詳細定義と同じように、バッチ処理についても入出力項目について確定させます。
・共通機能定義書 （＝共通処理定義）
本書での当工程の定義、目的は次の通りです。
共通で使用する機能の詳細定義を行うことにより、処理パターンの共通化を実現する
システム設計のセオリー赤 俊哉 (著) 5.2.4 共通で使用する機能を定義しよう！
ビジネスロジック設計まで行われ、ここまでで各機能の処理が確定した状態になりました。したがって、共通的な処理をする部分については共通処理として抜き出すように、機能整理を行います。
私が経験した例でいれば、例えば、コールセンターの受付システムにて、電話受付でも、メール受付でも、受付システムに問合せ内容を登録するという処理は共通である場合は、受付処理は共通化するといったように整理します。
外部設計（後半）の更に後半で実施する成果物
・外部IF詳細定義
本書での当工程の定義、目的は次の通りです。
外部インターフェースを確定し、併せて、連携方式も確定させる
システム設計のセオリー赤 俊哉 (著) 3.2.3 外部インターフェースの詳細を定義しよう！
前工程までで連携項目の定義は完了しています。したがって、ここでは、論理名で確定した連携項目を、物理データモデルを作成するのに合わせて、物理名で確定させます。
また、csvファイルの授受による連携か、HUFLTを使った連携か、中間テーブルに書き込むことによる連携かなど、具体的な連携方法についても確定させるとよいと思います。
・機能定義書(詳細) （＝ＢＬ設計）
本書での当工程の定義、目的は次の通りです。
機能定義を確定させる
システム設計のセオリー赤 俊哉 (著) 5.2.1 機能の詳細を定義しよう！
システム設計のセオリー赤 俊哉 (著)では、上記の通り「機能定義を確定させる」と記されており、前述した画面・帳票詳細定義よりも先に実施することになっています。
私の解釈では、前工程までで機能に対するINとOUTは決まっているため、この工程では下図のようにINからOUTを導くための処理内容を定義する工程に当たると考えています。アプリケーションの中枢であたるため、システム設計のセオリー赤 俊哉 (著)でもビジネスロジック設計に当たるとの旨、記されています。
システム設計のセオリー赤 俊哉 (著)では、次のように記されていますので引用し、ご紹介しておきます。
IPOのＰ（プロセス）に相当するルールに対して別途、機能定義書に処理記述を定義していきます。
システム設計のセオリー赤 俊哉 (著)
外部設計工程(後半)を横断して作成する成果物
・物理データモデル
本書での当工程の定義、目的は次の通りです。
「物理データモデル」の作成を通じ、データ要求および静的ビジネスルールを最適に実現する実装を可能とする
システム設計のセオリー赤 俊哉 (著) 3.1.3 物理データモデルをつくろう！
外部設計工程(前半)にて論理データモデル設計を工程全体を通じて実施したのと同じように、物理データモデル設計についても、同じように工程前提を通じて実施します。
後半の外部設計ではビジネスロジック設計などを通じて、処理定義を行いました。したがって、システム処理の中で必要となる”フラグ”もわかっています。
したがって、システム上のフラグも追加します。
このタイミングで正規化を行いますが、逆に非正規化をするかどうかも合わせて検討します。
その他、マスタに対して履歴管理をするかどうか、またする場合にはどのようにするかについても検討します。マスタを履歴管理するかどうかによって、トランザクションデータを非正規化するかどうかの方針も変わり、ひいては処理内容が変わってきます。したがって、裏を返せば、外部設計までに、正規化/非正規化まで行ったテーブル設計が済んでいる必要があると解釈することができます。
上記内容を私の方で図解するとこのようになります。
内部設計
外部設計が完了し、ユーザーの業務、操作に直接関わるような内容についてはすべて定義することができました。
したがって、ここからはここまでに決めた内容をシステムに落とし込む為の作業となります。
ここまでで作るべきモノは決まっており、あとはどのようにシステムで実現するか次第です。そのため、ここからの工程を請負契約で実施する場合が増えると思います。実際、IPAの方でも、内部設計から請負契約で実施することが推奨されていたはずです。
システム設計のセオリー赤 俊哉 (著)でも内部設計工程についてはすべてを解説しているわけではなく、内部設計工程の冒頭部分のみの解説になっています。そこで、ここではその中でも更に重要で、現場のシステム開発でも必要となる工程に絞って解説します。
内部設計工程の成果物
・プログラム仕様作成、内部処理定義（★筆者独自）
システム設計のセオリー赤 俊哉 (著)では、定義されていませんが、私は、内部設計工程に入れば、これまで外部設計で記述した内容を、システムに処理できる形に変換していく必要があるため、プログラム仕様の記述は必要になると考えています。
外部設計で定義したIN/OUT項目、そしてビジネスロジック設計はユーザが読んで分かる内容で記述をしていました。ここでは、それらの内容を、システムが分かる内容で記述することを言います。
例えば、外部設計工程までは「10月に受注した承認済の受注情報を表示する（IN/OUT)」「受注日が20201001から20201031の間で、承認済の受注情報を表示する（ビジネスロジック）」といった形で定義しました。内部設計工程では、プログラム仕様に読み替える必要があるため、「20201001 <= 受注テーブル.受注日 <=20201031 & 受注テーブル.承認フラグ = 1の情報を抽出」といったように、システム処理に置き換えていくイメージとなります
・DB実装
本書での当工程の定義、目的は次の通りです。
「物理データモデル」を基に、実装可能なデータベース定義体を作成し、システムの「データ」に関する実装を確立する
システム設計のセオリー赤 俊哉 (著) 3.3.1 データベースに実装しよう！
正規化・非正規化、フラグの付与、マスタ有効期間の方針が決まり物理データモデルの作成まで完了していると思います。そのため、コーディングに向けてデータベースの実装を行います。
DMLの作成などを行い、データベースに対してテーブルを作成していくと考えてよいと思います。
内部設計工程自体は後続もさらに続いていく点はお忘れなきようにしていただければと思います。
まとめ：上流工程の進め方
システム設計のセオリー赤 俊哉 (著)をベースにしつつ、私の経験も交えて、要件定義から設計工程までの進め方、成果物、検討事項について整理していきました。
今回の内容が上流工程を上手に進めるためのヒントになれば幸いです。
今回要件定義、外部設計工程の整理の参考文献とさせていただいたシステム設計のセオリー赤 俊哉 (著)にはより詳しく、より多くの工程が定義されているため、ぜひ本書を手に取っていただければ、より理解が深まると思います。
コメント