配布資料 61Keihi 要件定義 — 概要

status: active / 再現用ミニPJ（企業内でよく構築される経費精算システム）の要件。

実運用の製品ではなく、題材プロジェクトの設計パターンを安全に再現するための最小の題材として書いてあります。 読むときは「AI がそのまま実装に使える要件文書とはどういうものか」の見本として見てもらえると嬉しいです。

1. 目的とスコープ

社員が経費を申請し、上長が承認し、経理が支払処理する社内システムです。教材が目的なので、実運用の製品ではなく「題材プロジェクトの設計パターンを安全に再現する最小の題材」として設計しています。

• 初期スコープは承認1段階とする。これは意図的な設計であり、第2部 の大規模仕様変更演習で「事後承認の2段階制 + 代理申請」を追加する余白として機能する（→ chronicle/02 演習A)
• 決済事業者・銀行連携は扱わない（支払処理はステータス変更 + 支払予定日の記録まで）

2. ロール（3アクター）

アクター別プレフィックスと JWT の分離は題材プロジェクト規約の移植（→ catalog/02_rules.md backend）。

3. 経費申請（Expense）の構造

• ヘッダ: 申請ID・申請者・件名・申請日・状態・合計金額（明細から導出。直接編集不可）
• 明細行（1..n）: 利用日・費目・金額・摘要・領収書有無
• 費目マスタ: 交通費 / 会議費 / 消耗品費 / 出張費 / 通信費（上限ルールは 02_要件_金額計算.md）

4. 状態遷移（初期スコープ）

stateDiagram-v2
    [*] --> 下書き
    下書き --> 提出: 申請
    下書き --> 取下げ済み: 取下げ
    提出 --> 承認済み: 承認者が承認
    提出 --> 差戻し: 承認者が差戻し(理由必須)
    差戻し --> 提出: 修正して再申請
    差戻し --> 取下げ済み: 取下げ
    承認済み --> 支払済み: 経理が支払処理

• 提出後の編集は不可（差戻しを経由する）
• 承認済み・支払済みは取下げ不可
• 全状態遷移に操作者・日時の履歴を記録する（監査証跡）

5. 非機能規約（題材プロジェクトから移植する規約）

• 主キーは ULID（UUID 禁止）
• 物理削除禁止。deleteFlag による論理削除・全クエリで除外
• 監査5フィールド（createdAt / updatedAt / createdBy / updatedBy / deleteFlag）全エンティティ必須
• 日時列は最初からタイムゾーン付き（timestamptz）を選ぶ——題材プロジェクトが naive timestamp で払った9時間ずれの授業料（→ 事例 #09）を、正しい初期選択で回避する見本
• スタック: NestJS + Next.js + Prisma + PostgreSQL + Docker（Redis なし）