AI時代のシステム開発の基礎架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「業務要件から、最初に作る機能と後回しにする機能を分ける」（02-02）の本文で使った内容をまとめたもの。空欄版は 02-02-feature-scope_template.md。
1. 機能一覧
| 機能 | 区分（最初に作る／後で／今回は作らない） | 関連要件ID | 理由 | 代替運用 |
|---|---|---|---|---|
| 依頼の作成（下書き） | 最初に作る | REQ-001 | 依頼を識別できなければ、他の操作が成立しない | — |
| 依頼の提出 | 最初に作る | REQ-004 | 必須項目（件名・内容・承認者）がそろっていることの確認が要件そのもの | — |
| 承認 | 最初に作る | REQ-003 | 割当承認者だけが承認できることが、この業務の中心の約束 | — |
| 差戻し | 最初に作る | REQ-003、REQ-004 | 理由付きの差戻しがなければ、不備のある依頼が承認済みになりかねない | — |
| 一覧閲覧 | 最初に作る | REQ-002 | 自分に関係する依頼が見えなければ、提出・承認のどちらも始められない | — |
| 提出済みの取り下げ | 後で | — | 誤って提出した場合の操作だが、差戻してもらう運用で当面代替できる | 承認者に差戻しを依頼する |
| 承認取消 | 後で | — | 承認済みの扱いを初期版では固定し、取消の影響範囲を先に確定させない | 誤承認が起きた場合は運用管理者が記録し、以後は手順を見直す（システムでは戻さない） |
| 代理承認 | 後で | — | 誰がいつ代理できるかという社内ルールが未確認 | 承認者が対応できない場合は、運用管理者が承認者の割当を変更してから承認者本人が承認する |
| 通知メール | 後で | — | まず一覧で状況が見えることを優先する | 依頼者・承認者が一覧をこまめに確認する |
| 依頼への添付ファイル | 今回は作らない | — | 社外秘の情報を含むかどうかが未確認 | 添付が必要な場合は、既存の共有フォルダのリンクを内容欄に文字で書く |
| 管理者による緊急の業務変更 | 今回は作らない | — | 設計書第5.2節の未採用テーマ。通常運用の振りをして曖昧に実装しない | 緊急時は運用管理者が関係者に直接連絡し、対応を記録に残す（システム上の特別な操作は用意しない） |
| 退職者データの詳細な保存期間 | 今回は作らない | — | 設計書第5.2節の未採用テーマ。保存期間の規程が確認できていない | 退職者の依頼・履歴は削除せずそのまま残し、保存期間の運用は別途確認してから設計する |
2. 完了条件の確認
- すべての機能に3区分のいずれかと理由がある
- 最初に作る機能が要件IDと対応している
- 未採用テーマ（設計書5.2）が「今回は作らない」に明記されている
- 「後で」「今回は作らない」の機能に代替運用が書かれている