要件定義・設計プロセスの成果物生成

添付ファイルはある業務の流れをJSON形式で示したものです。

## 概要

{プロジェクト・システムの概要を記入してください}

## 依頼

添付した業務フローをしっかりと読み込み、業務要件一覧をCSV形式で作成してください。
各列は必ずダブルクォーテーションで囲むこと。また、出力ファイルがどれだけ大きくなっても構わないので、整合性を保ちつつ、添付内容を漏れなく全て考慮して出力してください。

業務要件一覧の項目は以下のとおりです。
- 業務ID
- 業務区分
    - 「注文」「決済」「在庫」などといったドメインを意識した内容を記載してください
- 要件概要
    - 「〇〇できる」という書き方にしてください
- 詳細内容
- 業務担当者
- 週あたり作業時間

添付ファイルはそれぞれ、業務の流れをJSON形式で示したもの、システム化した場合に想定される機能および画面一覧ファイルです。  

## 概要

{プロジェクト・システムの概要を記入してください}

## 依頼

添付したすべてのファイルをしっかりと読み込み、論理データモデルをmermaidで作成し、各エンティティの説明を添える形で出力してください。この論理データモデルをもとにデータベースの設計を行うことを前提とすること。
なお、概念データモデルの定義は以下のとおり。
- システムに必要なエンティティとそれらの関連を示すもの
- アトリビュートやカーディナリティを含む
- 出力ファイルがどれだけ大きくなっても構わないので、整合性を保ちつつ、添付内容を漏れなく全て考慮して出力すること
- 出力には各エンティティの説明文を併せて記載すること

添付ファイルはそれぞれ、業務の流れをJSON形式で示したもの、システム化した場合に想定される機能および画面一覧ファイルです。  

## 概要

{プロジェクト・システムの概要を記入してください}

## 依頼

添付したすべてのファイルをしっかりと読み込み、画面設計書をmarkdown形式で作成してください。
出力ファイルがどれだけ大きくなっても構わないので、整合性を保ちつつ、添付内容を漏れなく全て考慮して出力すること。

画面設計書の見出しは以下のとおりです。
- ## 概要・目的
    - 本ドキュメントの概要・目的を示す
- ## 画面遷移図
    - mermaid形式で各画面の遷移図を示す
- ## 各画面詳細
    - 画面ごとに見出しを分け、以下について示す
        - x-1 表示項目一覧
        - x-2 入力仕様
        - x-3 メッセージ仕様

添付ファイルはそれぞれ、業務の流れをJSON形式で示したもの、システム化した場合に想定される機能および画面一覧ファイルです。  

## 概要

{プロジェクト・システムの概要を記入してください}

## 依頼

添付したすべてのファイルをしっかりと読み込み、システムに必要となるバッチ設計書をmarkdown形式で作成してください。
出力ファイルがどれだけ大きくなっても構わないので、整合性を保ちつつ、添付内容を漏れなく全て考慮して出力すること。

バッチ設計書の見出しは以下のとおりです。
- ## 概要・目的
    - 本ドキュメントの概要・目的を示す
- ## バッチ一覧
    - 「機能名」「機能概要」「実行頻度」「実行時刻」「依存関係」をテーブル記法で示す
- ## 各バッチ詳細
    - バッチごとに見出しを分け、以下について示す
        - x-1 機能概要
        - x-2 処理フロー
        - x-3 入力データ仕様
        - x-4 出力データ仕様
        - x-5 エラー処理
        - x-6 実行条件
        - x-7 ログ出力仕様
        - x-8 リトライ設計

添付ファイルはそれぞれ、業務の流れをJSON形式で示したもの、システム化した場合に想定される機能および画面一覧ファイルです。  

## 概要

{プロジェクト・システムの概要を記入してください}

## 依頼

添付したすべてのファイルをしっかりと読み込み、システムに必要となる通知設計書をmarkdown形式で作成してください。
出力ファイルがどれだけ大きくなっても構わないので、整合性を保ちつつ、添付内容を漏れなく全て考慮して出力すること。

通知設計書の見出しは以下のとおりです。
- ## 概要・目的
    - 本ドキュメントの概要・目的を示す
- ## 通知一覧
    - 「通知名」「種別」「説明」「送信タイミング」「送信先」をテーブル記法で示す
    - なお「種別」は、例えば、メール、SMS、Slack、Teamsなどを想定
- ## 各通知詳細
    - 通知ごとに見出しを分け、以下について示す
        - x-1 通知テンプレート
        - x-2 通知処理フロー
        - x-3 例外処理

添付ファイルはそれぞれ、業務の流れをJSON形式で示したもの、システム化した場合に想定される機能および画面一覧ファイルです。  

## 概要

{プロジェクト・システムの概要を記入してください}

## 依頼

添付したすべてのファイルをしっかりと読み込み、本システムでの業務を滞りなく回すために必要な非機能要件定義書をmarkdown形式で作成してください。
出力ファイルがどれだけ大きくなっても構わないので、整合性を保ちつつ、添付内容を漏れなく全て考慮して出力すること。

非機能要件定義書の見出しは以下のとおりです。
- ## 概要・目的
- ## 可用性
- ## 性能・拡張性
- ## 運用・保守性
- ## 移行性
- ## セキュリティ
- ## 環境・エコロジー

添付した機能要件一覧から、要件を満たすWebアプリケーションの最適なインフラ構成を考え、設計書を作成してください。なお、最低限の要求として「AWSを中心としたインフラ構成とすること」をおさえてください。
出力はMarkdown形式でお願いします。

添付した機能要件およびインフラ設計をもとに、セキュリティ設計書を作成し、mdファイルとして出力してください。

あなたは要件定義の専門家アナリストです。
次に与える「業務フロー（ToBe）」を起点に、システムに必要な機能を**最小粒度の“機能ユニット”**へ分解してください。
**CRUD処理は必ず行を分けて定義**しますが、**機能名にCRUDは含めず**、CRUDは**機能概要**で明示してください。
**検索、非画面処理、メール送信、帳票出力**もすべて**独立行**で定義します。結果は**以下のCSV形式**で返してください。

---

## システム化対象

* **対象アクター**は **「見積受発注システム」** のみ。
* 出力する機能は、業務フロー上で **「見積受発注システム」** アクターのレーンに属する処理。
* **整合性基準による拡張は最低限のみ許容**。特に以下を対象に含める：

  * インプットファイルの登録処理
  * 登録後に必ず必要となる出力（例：登録データの確認、エクスポート、帳票生成）

---

## 入力

* 業務フロー（ToBe）：`[h_demo]B2B：見積、注文管理_toBe_20250926.json`
* JSON仕様：`JSON仕様.json`
* **画面一覧ファイル**：`画面一覧_7am4szepew129xcw.csv`

---

## 出力フォーマット（CSV列）

1. **"No."** — 1始まり連番
2. **"分類"** — ドメイン（例："見積"、"注文"、"配送"、"在庫"、"請求"、"入金"、"顧客"、"商品"、"価格・原価"、"通知"、"連携" など）
3. **"オブジェクト"** — 主対象（例："見積"、"見積明細"、"注文"、"顧客"…）
4. **"機能名・ファイル名"** — 自然な処理名（例："見積一覧"、"見積詳細"、"見積新規登録フォーム"、"見積削除"、"見積送付メール（顧客宛）"、"注文書PDF出力"）
5. **"機能区分"** — `画面|外部IF|バッチ|通知|帳票|その他`

   * **バッチは非同期のみ**。同期処理は「画面」または「その他」とする。
6. **"対象画面"** — **画面一覧ファイルに存在する画面名のみ**を記載。複数の場合は`/`区切り。該当がない場合は空欄。
7. **"機能概要"** — 目的、主要シナリオ、前提、異常系を簡潔に説明。

   * CRUDは本文内で明示（例："見積を新規登録する（Create）機能"）。
   * 検索は対象・検索項目（項目＋一致条件）・ソート・ページネーションを必須記載。
   * メールは**1通＝1行**、帳票は**1種＝1行**で詳細（宛先/テンプレ/フォーマット等）を記載。
   * 整合性基準で含めた場合はその理由を1文追加（例："インプットファイル登録のため必須"）。
8. **"関連業務フロー"** — 由来となる業務フローID（複数可、カンマ区切り）

---

## 「対象画面」抽出ルール

* **画面一覧ファイルに記載された画面名のみ利用**。記載がない場合は空欄。
* 照合手順：

  1. 厳密一致を優先
  2. 同義語正規化（新規＝登録＝作成／削除＝取消／編集＝更新／詳細＝参照 等）を許容
  3. 部分一致は「オブジェクト名＋画面種別語」の両方を含む行のみ候補
  4. 候補複数は「/」区切りで併記
* UIを持たない処理（バッチ・外部IF・通知・帳票等）は空欄

---

## 出力方針

* **機能単位で分割**：一覧、詳細、新規登録、編集、削除、検索、一括操作、状態遷移、インポート、エクスポート、各メール、各帳票は必ず別行。
* **CRUD網羅**：オブジェクトごとに Create / Read / Update / Delete が欠けないようにする。
* **検索は独立行**：対象・項目・一致条件・ソート・ページネーションを明記。
* **非画面処理も独立行**：バッチ（非同期のみ）、外部IF、通知、帳票、その他（採番/監査/権限チェック/重複排除/ウイルススキャン等）。
* **命名規則**：機能名は自然な名前（CRUDは含めない）。
* **トレーサビリティ**：各行に必ず関連業務フローIDを付与。
* **バリアント**（宛先違い・テンプレ違い・出力違い 等）は行を分ける。

---

## CSV仕様

* UTF-8（BOMなし）、LF改行、カンマ区切り

### CSVヘッダ

"No.","分類","オブジェクト","機能名・ファイル名","機能区分","対象画面","機能概要","関連業務フロー"

---

## 検証チェック（生成結果末尾に出力）

* CRUD網羅されているか
* 検索行に対象・項目・一致条件・ソート・ページネーションがあるか
* バッチは非同期のみか
* メール1通／帳票1種ごとに独立行になっているか
* 対象画面が画面一覧ファイルにある名称のみか（複数は「/」、該当なしは空欄）
* 整合性基準による追加は**最低限（インプット登録＋登録後出力など）**に留まっているか
* 全行に関連業務フローIDがあるか

前提
対象SaaS名：{SaaS名}

{SaaS名}の機能.tsvを参照し、各SaaSの機能を把握しなさい。
添付した業務フローから、システム開発に必要な「機能要件一覧.tsv」をTSVファイルとして作成してください。
機能要件一覧の項目は以下のとおりです。

- No.
    - 1から連番
- 大分類
    - 受注, 出荷, といった粒度です
- 分類
    - 商品検索, 商品一覧, 商品詳細, といった値が入ります
- 機能名・ファイル名
    - キーワード検索, カテゴリページ, 商品詳細ページ, といった値が入ります
- 機能区分
    - 画面, 外部IF, バッチ, といった値が入ります
- SaaSのカスタマイズ
    - 有 or 無を表示
    - ECフォースで導入した場合のカスタマイズの有無
- SaaSでの対応内容
- SaaSでの導入の参考工数（人日）
    - コンサバな工数
    - ポジティブな工数
- 備考

添付した機能要件の「見積管理」を対象に機能詳細設計書を作成し、mdファイルとして出力してください。

添付した機能要件をもとに、テスト方針書を作成し、mdファイルとして出力してください。

あなたは業務システムの受け入れテストを設計するQA担当です。
添付資料をもとに、次の2つのCSVをこの順番で出力してください。
出力結果はどれだけ大きくなっても構いません。

【必須条件】
1. 出力は必ず「①シナリオ一覧のCSV」→「②シナリオ詳細手順のCSV」の順にすること
2. 各CSVは1行目にヘッダーを含め、各列はダブルクォーテーションで囲むこと
3. 各シナリオには一意のIDを付与し、詳細手順側でもそのIDを参照すること
4. CSV以外の説明文は出力しないこと
5. 「テスト結果」「テスト実施日」は出力時は空欄にすること（後で人が埋める想定）
6. シナリオ詳細手順には「人が実施・確認する必要のある内容のみ」を出力し、システムが自動で行う処理だけの行は出力しないこと
7. 業務フローJSONに「パターン」「セクション」が含まれている場合、それぞれ「業務フローパターン」「区分」として出力すること
8. 「区分」は必ず埋めること（JSONに該当セクションがなければ最も近い階層の名称を使う）。「業務フローパターン」は該当がなければ空欄でよい
9 . シナリオ詳細手順には「人が実施・確認する必要のある内容のみ」を出力し、システムが自動で行う処理だけの行は出力しないこと

------------------------------------------------------------
① シナリオ一覧（CSV）

【IDの付け方】
- シナリオIDは「P<n>-SCN-<連番3桁>」の形式とする。
  - 例：P1-SCN-001, P1-SCN-002, … / 別パターンなら P2-SCN-001, P2-SCN-002, …
- パターンごとに連番をリセットすること（P1は001から、P2も001から）
- JSON内でパターンが複数ある場合は、JSONで出てきた順番でP1, P2, P3…と番号を振ること
- パターン情報が一切ないシナリオは「P0-SCN-001」のようにP0で始めてよい

【並び順】
- CSVの行はパターンが同じもの同士で固めること
- 並び順は「P0 → P1 → P2 → …」の昇順
- 各パターンの中ではシナリオIDの連番順に並べること

【ヘッダー】
シナリオID,業務フローパターン,区分,シナリオ名,シナリオ概要,前提条件,テスト結果,テスト実施日

【フィールド説明】
- シナリオID: 上記ルールで生成する
- 業務フローパターン: JSONのパターン情報を文字列のまま入れてよい（例：「標準」「返品」「特注」など）。なければ空欄
- 区分: JSONのセクション情報を入れる。ここは空欄にしない
- シナリオ名: 「新規受注を登録する」など短く
- シナリオ概要: そのシナリオで何を確認するかを1文で書く
- 前提条件: ログイン済み、テスト用マスタ登録済みなど
- テスト結果: 空欄で出力
- テスト実施日: 空欄で出力

------------------------------------------------------------
② シナリオ詳細手順（CSV）

【重要なルール】
- 人が操作・確認する手順のみを行として出力する
- 「システムが自動でメール送信する」など人が何もしない処理は行として出さない
- ただし人が結果を確認する場合（「通知メールが届いていることを確認する」など）は出力してよい
- ①でパターン別にシナリオIDを付けているので、ここでも同じIDを使うこと
- 1つのシナリオに複数パターンがひもづく場合は、同じシナリオIDの行が複数になってもよい

【ヘッダー】
シナリオID,業務フローパターン,区分,手順番号,操作実施者,操作内容,期待結果,補足,テスト結果,テスト実施日

【フィールド説明】
- シナリオID: ①で定義したIDをそのまま入れる（例：P1-SCN-001）
- 業務フローパターン: JSONのパターン情報を文字列のまま入れてよい。なければ空欄
- 区分: JSONのセクション情報を入れる。ここは空欄にしない
- 手順番号: 1,2,3,... の連番
- 操作実施者: その手順を行うロール（例：受注担当者, 管理者, 倉庫担当者）。JSONにアクターがなければ「担当者」でよい
- 操作内容: 人が行う操作を具体的に書く
- 期待結果: その操作後に人が確認すべきことを具体的に書く
- 補足: 自動処理の説明や事前に用意すべきデータなどがあれば書く。なければ空欄
- テスト結果: 空欄で出力
- テスト実施日: 空欄で出力

添付した業務フローから、システム運用マニュアルを作成し、mdファイルとして出力してください。