架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事Aの本文で使った内容をまとめたもの。空欄版は requirements_template.md。
1. 聞取りメモの整理表
| 番号 | 聞いた言葉（そのまま） | 誰が言ったか（役割） | 現象か原因か希望か | 確認したいこと |
|---|
| M-1 | 「依頼の進捗が見えない」 | 総務課長（承認者） | 現象 | 「進捗」とは誰が何を知りたいことか。今どこで確認しているか |
| M-2 | 「承認を簡単にしたい」 | 総務課長（承認者） | 希望 | 何が面倒か（探す手間か、判断か、記録か） |
| M-3 | 「メールとチャットに依頼がばらばらに来る」 | 総務担当（依頼を受ける側） | 原因の仮説 | 実際の依頼経路と件数の目安（架空でも仮定として明記） |
| M-4 | 「誰が今の担当か分からず、二重に対応した」 | 総務担当 | 現象 | 担当割当のルールが今あるか |
| M-5 | 「承認したつもりが記録に残っていない」 | 総務課長 | 現象 | 承認の証拠を何で残しているか |
2. 確認事項と「勝手に決めてはいけないこと」
| 番号 | 確認する内容 | 誰に確認するか | 確認前に仮置きしてよいか | 回答・決定 |
|---|
| Q-1 | 承認者は依頼ごとに決まるか、部署で固定か | 総務課長 | 不可（権限の設計に直結） | 依頼ごとに1名を指定する（架空の決定） |
| Q-2 | 自分の依頼を自分で承認する場面はあるか | 総務課長・運用管理者 | 不可 | 禁止する。役割を兼ねる人も禁止（架空の決定） |
| Q-3 | 承認済みの依頼を後から直すことはあるか | 総務課長 | 不可 | 初期版では編集不可。取消は将来検討（架空の決定） |
| Q-4 | 差戻しに理由は必須か | 総務課長 | 可（仮置き：必須） | 必須にする（架空の決定） |
| Q-5 | 件名・内容以外に必須の項目はあるか | 総務担当 | 可（仮置き：なし） | 初期版はなし。希望日は任意（架空の決定） |
| Q-6 | 個人情報や社外秘を依頼に書くことがあるか | 運用管理者 | 不可（保存・権限・公開範囲に影響） | 未回答。要件確定前に確認する |
3. 利用者と役割
| 役割 | 誰か（架空） | できること | できないこと |
|---|
| 依頼者 | 各部署の社員 | 自分の依頼の作成・編集（下書き・差戻し中）・提出・閲覧 | 他人の依頼の閲覧・編集、承認 |
| 承認者 | 各課の課長 | 自分に割り当てられた提出済み依頼の閲覧、承認、理由付きの差戻し | 割当外の依頼の承認、自分の依頼の承認 |
| 運用管理者 | 総務の担当1名 | 利用者・役割・担当割当の管理、運用記録の確認 | 承認の無条件な代行 |
4. 対象データと状態
| データ | 主な項目 | 状態の種類 | 状態が変わるきっかけ |
|---|
| 依頼 | ID、依頼者、件名、内容、状態、承認者 | 下書き／提出済み／差戻し／承認済み | 提出、再提出、承認、差戻し |
| 履歴 | 依頼ID、操作、操作者、時刻、理由 | （状態なし。追記のみ） | 提出・再提出・承認・差戻しのたびに1件追加 |
5. 業務要件一覧
| 要件ID | 誰が | どの条件で | 何をできる／できない | 対象外・備考 |
|---|
| REQ-001 | 各役割 | 自分に許可された範囲の依頼について | 依頼を一意のIDで識別し、依頼者・件名・内容・状態・承認者を見分けられる | IDの採番方式は設計で決める。誰が何を見られるかはREQ-002 |
| REQ-002 | 依頼者・承認者・管理者 | 役割と対象データに応じて | 編集・閲覧・提出できる範囲が限られる | 全員に全件公開はしない |
| REQ-003 | 割り当てられた承認者（役割が承認者である人） | 対象が提出済みのときだけ | 承認・差戻しができる。自己承認はできない | 代理承認は対象外 |
| REQ-004 | 依頼者／承認者 | 件名・内容・承認者が欠けるとき／理由がないとき | 提出できない／差戻しできない | 希望日は任意 |
| REQ-005 | システム | 提出・再提出・承認・差戻しのたびに | 操作者と時刻を含む履歴を残す | 閲覧の履歴は初期版では残さない |
| REQ-007（業務上の条件） | システム | 承認・差戻しの処理が途中で失敗したとき | 「承認済みなのに承認の記録がない」といった片方だけの結果を正常完了として扱わない | 実現の仕組み（トランザクション）は記事B |
6. 受入条件一覧
| 受入条件ID | 対応要件ID | 前提（利用者・データ・状態） | 操作 | 期待結果 | 種類 |
|---|
| AC-001 | REQ-003, 005 | 承認者・鈴木が割当。依頼REQ-A01は提出済み | 鈴木が承認する | 状態が承認済みになり、履歴に「承認・鈴木・時刻」が1件残る | 正常 |
| AC-002 | REQ-003 | 承認者・高橋は割当外。REQ-A01は提出済み | 高橋が承認する | 拒否される。状態・履歴は変わらない | 権限なし |
| AC-003 | REQ-003 | REQ-A03は鈴木が依頼者かつ承認者に割当 | 鈴木が承認する | 拒否される（自己承認）。状態・履歴は変わらない | 権限なし |
| AC-004 | REQ-003 | REQ-A02は下書き。鈴木が割当 | 鈴木が承認する | 拒否される（対象外の状態）。下書きのまま | 状態外 |
| AC-005 | REQ-004 | 依頼者・佐藤。件名が空の下書き | 佐藤が提出する | 拒否され、何が足りないか表示される。下書きのまま | 入力不足 |
| AC-006 | REQ-004 | 提出済みのREQ-A01。鈴木が割当 | 鈴木が理由を空欄で差し戻す | 拒否される。提出済みのまま | 入力不足 |
| AC-007 | REQ-002 | 依頼者・佐藤。他人（田中）の依頼が存在 | 佐藤が田中の依頼を開く | 表示されない、または権限がない旨が示される | 権限なし |
| AC-008 | REQ-003, 006 | 承認済みのREQ-A04。高橋が割当 | 高橋がもう一度承認する | 2回目は効果がなく、承認履歴は1件のまま | 重複 |
| AC-009 | REQ-001 | 佐藤の依頼REQ-A01（提出済み）とREQ-A02（下書き）がある | 佐藤が許可された範囲の一覧を開き、下書きのREQ-A02の件名を編集して保存する | 2件は異なるIDで表示される。編集後もREQ-A02は同じIDのまま追える。REQ-A01には変更を加えない | 正常 |
| AC-010 | REQ-007 | REQ-A01は提出済み。鈴木が割当 | 鈴木が承認するが、記録の保存に失敗する | 承認済みにならず、承認の記録も増えない。失敗が利用者に伝わる | 途中失敗 |
記事Bのテストとの対応：AC-001→T1、AC-002→T2、AC-003→T3、AC-004→T4、AC-006→T7、AC-008→T5、AC-010→T6。AC-005・007・009は記事Bでは未検証（提出処理・閲覧権限・画面は後の工程）。
7. 今回は作らないこと（対象外）
| 項目 | 対象外にした理由 | 将来検討するか |
|---|
| 代理承認 | 誰がいつ代理できるかの社内ルールが未確認（Q-1関連） | する |
| 承認の取消 | 承認済みの扱いを初期版では固定（Q-3） | する |
| 提出済みの取り下げ | 状態を4つに固定するため | する |
| 通知メール | まず一覧で状況が見えることを優先 | する |
| 依頼への添付ファイル | 保存先・容量・機密性の確認が先（Q-6） | 確認後に判断 |
8. 次工程へ渡すもの
AI時代のシステム開発の基礎