# 要件定義書・受入条件サンプル

文書ID: REQ-DOC-001 / 版: 1.0 / 案件: EXPENSE-DEMO / 状態: 記入例・未承認

架空の経費申請システムの文稿。ここでの要件と数値は例示です。実際の合意記録は未登録です。

## 工程定義

- 目的: 業務目的を、実装と受入テストに使える明確な条件へ変換する。
- 入力: 現行業務資料、関係者、課題、対象範囲、制約。
- AIの作業: 資料から要件候補を抽出し、曖昧さを質問、要件IDと受入条件を付与する。
- 成果物: 要件定義書、業務フロー、要件一覧、受入条件、未決事項一覧。
- 完了条件: 業務責任者が対象・対象外・成功条件を合意。未決事項に担当と期限を設定。

## 1. 背景・目的・範囲

メールによる経費承認では、本人による承認と変更履歴を確認しにくい。承認者が申請を確認し、自己承認をシステムで拒否、操作の追跡情報を保持する。

対象は申請済み経費の単一承認。代理承認、多段階承認、会計仕訳連携は今回の対象外。

## 2. 業務フロー

申請者が申請 → 承認者が一覧から内容を確認 → 承認要求 → 権限・自己承認・状態を検査 → 承認と監査記録を同一トランザクションで保存 → 結果を画面に表示。

例外: 自己承認または権限不足は拒否し状態を変えない。既に承認済みの場合も二重更新しない。

## 3. 要件一覧

| ID | 要件 | 優先度 | 根拠 | 受入条件 |
| --- | --- | --- | --- | --- |
| REQ-014 | 申請者は自分の申請を承認できない | 必須 | 職務分離の社内ルール例 | AC-014-02 |
| REQ-015 | 承認権限を持つ別利用者が申請済み経費を承認できる | 必須 | 現行承認手続 | AC-014-01 / 03 |
| REQ-016 | 承認と監査記録が一体で保存される | 必須 | 操作追跡 | AC-014-04 / 05 |

## 4. Given / When / Then受入条件

| ID | Given（前提） | When（操作） | Then（期待結果） |
| --- | --- | --- | --- |
| AC-014-01 | U001の申請E100、申請済み、U002に承認権限あり | U002が承認 | 承認済みとなり、承認者・日時・申請IDの監査記録が1件作成 |
| AC-014-02 | E100の申請者U001に承認権限もある | U001が自己承認 | 403 SELF_APPROVAL、状態は申請済み、承認記録は増えない |
| AC-014-03 | U003に承認権限なし | U003が承認APIを直接呼ぶ | 403 FORBIDDEN、状態は不変 |
| AC-014-04 | E100は承認済み | 再び承認要求 | 409 ALREADY_PROCESSED、二重の承認記録なし |
| AC-014-05 | 監査記録の保存に失敗する | U002が承認 | 503 SAVE_FAILED、承認状態もロールバック |

## 5. 制約・非機能・未決事項

認証済み利用者をサーバーで検証し、画面のボタン非表示だけに依存しない。性能の例示目標は50同時利用者で承認APIのp95応答時間2秒以内。実際の負荷条件は運用担当と合意する。

| 課題ID | 未決事項 | 担当ロール | 期限 | 決定内容 |
| --- | --- | --- | --- | --- |
| Q-001 | 監査ログ保存期間 | 業務責任者 | 要件承認前 | 未決・自社規程を参照 |
| Q-002 | 部門ごとの承認可能範囲 | 業務責任者 | 要件承認前 | 本例はテスト用単一部門。実案件は要確定 |

## 6. 自社用追記・承認欄

企業: {{COMPANY_NAME}} / 業務: {{PROJECT_NAME}} / 対象ロール: {{ROLES}}

自社の業務フロー: {{BUSINESS_FLOW}}

追加要件はID、根拠、優先度、受入条件を同じ表形式で記入。多段階承認を追加する場合は基本設計・状態モデル・全テストの影響を確認する。

レビュー担当: {{BUSINESS_OWNER}} / 判定: 未承認 / 指摘: {{REVIEW_NOTES}} / 承認日時: 未登録