# システム要件定義書

| 項目 | 内容 |
|------|------|
| 文書番号 | SRS-ECOM-001 |
| バージョン | 1.0 |
| 作成日 | 2025年12月1日 |
| ステータス | 承認済み |
| 作成者 | 田中 太郎（プロジェクトマネージャー） |
| レビュアー | 鈴木 一郎（技術部長） |

---

## 1. システム概要

ECサイト注文管理プラットフォームは、注文ライフサイクル管理（作成、決済処理、顧客通知）を行うマイクロサービスベースのシステムである。3つの独立デプロイ可能なサービスがREST APIで連携する。

### 1.1 サービス構成

| サービス | ポート | 責務 |
|---------|--------|------|
| 注文サービス (Order Service) | 8000 | 注文CRUD、ステータス管理、サービス間オーケストレーション |
| 決済サービス (Payment Service) | 8001 | 決済処理、返金、金額バリデーション |
| 通知サービス (Notification Service) | 8002 | メール/SMS通知、テンプレート管理 |
| フロントエンド管理画面 | 5173 | Web管理UI（React SPA）、3サービスに直接接続 |

### 1.2 ステークホルダー

| ステークホルダー | 役割 | 関心事 |
|-----------------|------|--------|
| 運用チーム | 注文管理 | 効率的な注文処理、ステータス追跡 |
| 開発チーム | システム保守 | クリーンなAPI、テスト可能性 |
| 顧客 | エンドユーザー | 正確な注文、適時な通知 |
| 経理チーム | 決済管理 | 正確な決済記録、返金追跡 |

---

## 2. 機能要件

### 2.1 注文サービス

| ID | 要件 | 優先度 |
|----|------|--------|
| FR-001 | 顧客情報（氏名、メール）と注文明細（商品名、数量、単価）を指定して、**1件の注文**を作成できること。 | P1 |
| FR-002 | 注文合計金額を明細の（数量×単価）の合計から自動計算すること。 | P1 |
| FR-003 | ページネーション（skip, limit）で注文一覧を取得できること。 | P1 |
| FR-004 | 注文IDにより注文詳細（明細含む）を取得できること。 | P1 |
| FR-005 | 注文ステータス遷移をサポートすること：保留中→決済処理中→決済済み→発送済み→配達完了。 | P1 |
| FR-006 | 注文キャンセル機能をサポートし、ステータスをキャンセル済みに遷移すること。 | P1 |
| FR-007 | 注文作成時、決済サービスに自動的に決済リクエストを送信すること。 | P1 |
| FR-008 | 注文作成時、通知サービスに自動的に確認メールを送信すること。 | P1 |
| FR-009 | 注文キャンセル時、決済サービスに返金リクエストを送信すること。 | P1 |
| FR-010 | 注文キャンセル時、通知サービスにキャンセル通知を送信すること。 | P1 |

### 2.2 決済サービス

| ID | 要件 | 優先度 |
|----|------|--------|
| FR-011 | 1件の注文に対して金額バリデーション付きの決済処理を実行すること。 | P1 |
| FR-012 | 最低決済金額100円を強制すること。 | P1 |
| FR-013 | **1回の取引あたり最大100万円**の上限を強制すること。 | P1 |
| FR-014 | 決済と注文の1:1関係を維持すること（1注文につき1決済）。 | P1 |
| FR-015 | 同一注文に対する重複決済リクエストを拒否すること。 | P1 |
| FR-016 | 完了済み決済に対する返金処理をサポートすること。 | P1 |
| FR-017 | 決済IDまたは注文IDにより決済詳細を取得できること。 | P1 |
| FR-018 | Webhookコールバックにより注文サービスに決済ステータス変更を通知すること。 | P2 |

### 2.3 通知サービス

| ID | 要件 | 優先度 |
|----|------|--------|
| FR-019 | テンプレートを使用して個別注文のメール通知を送信すること。 | P1 |
| FR-020 | テンプレートを使用して個別注文のSMS通知を送信すること。 | P2 |
| FR-021 | 3種類の通知テンプレートをサポートすること：注文確認、発送通知、キャンセル通知。 | P1 |
| FR-022 | Jinja2形式の変数置換を日本語コンテンツでサポートすること。 | P1 |
| FR-023 | 通知配信ステータス（保留中、送信済み、失敗）を追跡すること。 | P1 |
| FR-024 | 通知IDにより通知履歴を取得できること。 | P2 |
| FR-025 | 特定注文の全通知を取得できること。 | P2 |

---

## 3. 非機能要件

| ID | カテゴリ | 要件 | 目標値 |
|----|----------|------|--------|
| NFR-001 | 性能 | 注文作成スループット | 100件/分 |
| NFR-002 | 性能 | 決済処理レイテンシ | 30秒以内/件 |
| NFR-003 | 性能 | 通知配信レイテンシ | 5秒以内/件 |
| NFR-004 | 性能 | API応答時間（読取操作） | P95 200ms以内 |
| NFR-005 | 可用性 | システム稼働率 | 99.5% |
| NFR-006 | 信頼性 | サービス間データ整合性 | 結果整合性 |
| NFR-007 | セキュリティ | API入力バリデーション | 全エンドポイント |
| NFR-008 | スケーラビリティ | 通知レート制限 | 10件/秒 |

---

## 4. 現在のシステム制限事項

> **重要:** 以下の制限事項は現行システムの境界を定義する。これらを超える機能の追加には、複数サービスにまたがるアーキテクチャ変更が必要となる。

| ID | 制限事項 | 影響範囲 | 深刻度 |
|----|---------|---------|--------|
| LIM-001 | **注文作成は1件ずつのみ。** 一括・バッチ注文作成機能は存在しない。REST APIで1件ずつ作成する必要がある。 | 注文サービス | 高 |
| LIM-002 | **CSV/ファイルベースの注文インポート機能なし。** ファイルからの注文データ取込み機能は存在しない。 | 注文サービス | 高 |
| LIM-003 | **決済処理は1件ずつ。** バッチ決済APIは存在しない。各注文に個別の決済APIコールが必要。 | 決済サービス | 高 |
| LIM-004 | **通知は注文ごとに個別送信。** 一括通知機能は存在しない。 | 通知サービス | 中 |
| LIM-005 | **サービス間呼出しはシーケンシャル。** 注文→決済→通知の順次実行。並列処理なし。 | 全サービス | 中 |
| LIM-006 | **バッチ操作の進捗追跡なし。** バッチ操作自体が存在しないため、進捗追跡メカニズムもない。 | 全サービス | 中 |

### 4.1 制限事項の詳細

**LIM-001 & LIM-002 — 一括注文インポートなし：**
注文サービスのDBスキーマには `batch_id`、`csv_source`、`bulk_import_group` カラムが存在しない。`POST /api/v1/orders/` エンドポイントは1件の注文ペイロードのみ受付。1,000件の注文処理には1,000回の個別APIコールが必要。

**LIM-003 — バッチ決済なし：**
決済サービスは `order_id` にユニーク制約（1:1関係）を設定。1回の取引あたり最大100万円。集約決済エンドポイントなし。1,000件の注文処理には1,000回の個別決済コールが必要。

**LIM-004 — 一括通知なし：**
通知サービスは1APIコールにつき1通の通知処理。レート制限10件/秒。1,000件の注文確認メール送信には最低100秒（約1.7分）必要。

---

## 5. 将来の検討事項

1. **CSVからの一括注文インポート** — 法人顧客がCSVファイル（100〜10,000件）をアップロードしてバッチ処理。3サービス全てに変更が必要。
2. **バッチ決済処理** — 複数注文の決済を集約処理。
3. **キューベース通知** — 同期通知送信を非同期キューに置換。
4. **進捗追跡ダッシュボード** — バッチ操作の進捗をリアルタイム表示。

> **注記:** これらの機能は計画段階。設計書・実装ストーリーは未作成。