要件定義より前の上流工程に関して、色々記事を読んだので備忘。
全体を通してのポイント
◎ システム化の対象についての知識領域の整理
⇛ ドメイン・エンジニアリングにおける「ドメイン分析」を利用する。システム化の対象となる領域について知識の整理を行い、ドメインモデルを作成する。
◎ 開発環境に寄せた業務分析を行う
⇛ ドメインモデルをINPUTに、開発環境に合わせた業務分析（POA, OOA, DOA）を行う。
システム化の対象についての知識領域の整理
ドメイン分析を行う
開発者が最初に行う作業です。システム化に伴って、開発者はシステム化の対象となるものについて、ある程度の知識が必要です。
例として、ステークスホルダがどう絡んでいるか・業界についての常識や規則、慣習・関連法規・業務フロー等があります。業界全ての知識を漏れなくINPUTすることは不可能なので、要所要所を必要に応じて理解していきます。
のシステム化の対象となる知識や活動領域を、当記事では「ドメイン領域」とよびます。
また、ドメイン領域以外の業界全ての知識を、当記事では「ドメイン知識」と呼びます。
補足①：ドメインについて
ドメインの言葉の意味は「知識または活動の領域」です。ここから、ソフトウェア工学におけるドメインの意味を掘り下げると、「アプリケーションが適用される対象領域」を指します。
例えば、企業Ａの基幹業務システムを作りたい場合、ドメインは「企業Ａ」になります。社内業務だけにとどまらず、取引先や顧客の管理も行えるシステムにしたい場合ドメインは「企業Ａ」の他に「取引先全体」「一般ユーザー」なども追加されます。
補足②：ドメイン領域について
ドメイン領域については、三好 康之さんの「ITエンジニアのための【業務知識】がわかる本」の「４つのビジネスルール」を参考に説明できるかと思います。
【４つのビジネスルールレイヤ】
１．法令遵守（Must）
⇛法律・規則により規制がある知識領域。
開発者は最低限知っておくべき知識で、顧客は「知ってて当然」と思っている。
具体例：関連法規、社内規則、社内の業務フロー等
２．ISO,JIS,その他基準（Best）
⇛規制はないが、準拠したほうが良い知識領域。
開発者は最低限知っておくべき知識で、顧客は「知ってて当然」と思っている。
具体例：???
３．業界慣習, 業界標準（Better）
⇛何かしらのメリットがあるので準拠している。
開発者は知っていたほうが良い知識で、顧客は「できれば知っていてほしいな」と思っている。
具体例：食品業界だとFDA、IT業界ではW3Cとか？
４．該当企業の創意工夫部分（????）
⇛他社との差別化のために行っている創意工夫, 効率化など。
顧客の企業秘密的なものなので、開発者は知らなくて当然。顧客も「知ってたらすごい」と思っている。
三好 康之さんの本👇
ドメインモデルの作成を行う
上記で説明した「４つのビジネスルール」や、顧客・有識者からの聞き取り、調査内容を始めとした情報を元に、「ドメインモデル」を作成します。
ドメインモデルの成果物は主に「業務フロー図」「ミニスペック」「データディクショナリ（用語集・辞書）」があります。
業務フロー図
名前の通り、企業の業務を図式化したものです。作成の際は、以下種類のものが使われます。
・日本工業規格（JIS）
・BPMN形式
・データフロー図（DFD）
・NOMA方式フローチャート
・産能大式
・アクティビティ図（UML）
・独自・自由形式（独自に記述ルールを決める方式）
色々種類がありますが、大体に共通しているのは、フローチャート形式ということです。
フロー形式（手続き型）はシステムをよく知らない人でも直感的に理解できるので、顧客に説明しやすい、現実の業務がフロー形式（手続き型）なものが多い等の理由で使用しているのだと思います。
ミニスペック
業務フロー図で書ききれない複雑な条件や、処理の詳細をここで記載します。主に、以下の表現方法を使います。
・構造化言語
・デシジョンツリー（決定木）
・デシジョンテーブル
データディクショナリ（用語集・辞書）
顧客と開発者の間の用語の使い方が違うことにより、認識齟齬が発生することがあります。
それを防ぐために、企業で使っている言葉と、システムで扱うデータの言葉を紐づけて定義をします。
これにより、多義語・類義語・派生語などの整理、誤解・思い込みによる手戻り作業の防止等を防止します。データディクショナリは特に決まった形式はないようです。
ミニスペックとデータディクショナリについて
本来は構造化分析手法でつかわれるものですが、フローチャートと同じく、顧客が直感的に理解できるという私見から、ドメインモデルの成果物に含めています。
業務フロー関連について👇
ミニスペック・データディクショナリについて👇
「開発環境に寄せた業務分析」を行う
ドメイン分析によって出来上がった成果物であるドメインモデルは、特定の開発言語や実行環境に依存しません。
これをINPUTに、開発環境に寄せた業務分析でアプローチを行います。開発環境に寄せた業務分析手法には、有名どころで３つあります。
◎ POA（プロセス指向アプローチ）
◎ OOA（オブジェクト指向アプローチ）
◎ DOA（データ指向アプローチ）
POA（プロセス指向アプローチ）
POA（プロセス指向アプローチ）は３つのアプローチのうち、最も古くからある手法で、開発言語が手続き型言語（ストアドやバッチ、シェル等）である場合に採用されます。
POAでは「DFD（データフロー図）」を使ってデータの関連性や、処理の流れを整理することが多いです。
OOA（オブジェクト指向アプローチ）
OOA（オブジェクト指向アプローチ）は、POAから派生して出来たものです。開発言語がオブジェクト指向型の言語（Java、Ruby等）である場合に採用されます。
OOAでは「クラス図」「シーケンス図」等のUMLを使ってデータの関連性や、処理の流れを整理することが多いです。
DOA（データ指向アプローチ）
DOA（データ指向アプローチ）は、大量のデータを扱う業務アプリケーションで適用される方法論で、機能や処理を中心に考えるのではなく、データを中心に考えていくアプローチです。
主にDBMS製品を利用する場合に採用されます。DOAにおけるデータの関連性の整理方法は、主に３つの流派があるようです。
◎ ピーター・チェンの「実体関連モデリング」
◎ 佐藤正美の「T字形ER手法（TM法）」
◎ 渡辺幸三の「三要素分析法」
現実の開発では、アプリ・DB・ストアドを組み合わることが多いので、POA, OOA, DOAの３種類を組み合わせて成果物を作成します。
👇実体関連モデリング
👇三要素分析法
👇T字形ER手法（TM法）
「ドメイン知識」「メタ知識」「ITの知識」
上流工程を行うには、「ドメイン知識」「メタ知識」「ITの知識」が大切です。
ドメイン知識
当記事で説明した内容です。開発の対象となる企業や業界についての幅広い知識を持つことで、顧客とスムーズなコミュニケーションがとれます。
メタ知識
ドメイン知識を論理的、数学的に扱うための知識。例として、離散数学や述語論理（DB設計等で利用）があります。
IT知識
ITテクノロジー全般に関する知識です。エンジニアの目的は「より良い社会を実現すること」です。既存の技術にとらわれずに、新しい技術や、別分野の技術を柔軟に使ってその目的を達成します。そのために、IT全般の幅広い知識が必要になります。
建築学で例えると、
ドメイン知識 ⇛ その土地に関する歴史・環境・風土、その地域特有の条例・規則に対する理解
メタ知識 ⇛ 構造力学的な理解
IT知識 ⇛ 建築計画、デザイン等の建築そのもののに対する理解
みたいな感じ・・・？🤔
その他
今回紹介した内容は、会社やプロジェクトによってフェーズの名前が違っていたり、フェーズの分け方が異なることがあります。
例えば、以下の「システム開発地図」の資料では、「業務分析」の中に「ドメイン分析」と「開発環境に寄せた業務分析（概念クラス図）」があったりします👇
その上で、ポイントとして「顧客寄りの業務分析」「開発環境に寄せた業務分析」の２つのフェーズがあるということを抑えておこうと思います。
もうひとつのポイントとして、両者は成果物を作成したら終了ではなく、一方を作成する上で、必要に応じて手戻りして再度分析・整理を繰り返すことです。上流工程は、形が全くないところから、何かを生み出す作業なので、このような方法で、成果物の精度を上げていくのです。
以上