機能要件一覧

機能要件一覧

要件定義における機能要件を一覧化し、機能ID・変更区分・業務との紐付けを明確にすることで、関係者間の認識合わせと要件の抜け漏れを防止します。

🎯 概要


  • 目的: 追加・変更する機能を一覧化し、機能単位の概要・影響範囲・関連業務を明確にすることで、関係者間の認識合わせと要件の抜け漏れ防止を行う
  • スコープ: 要件定義で扱う 機能要件(FR) を対象とする。機能IDの付番、機能分類、変更区分(新規/変更/削除)、関連する業務(BR)や利用者区分、概要を整理する。画面レイアウトや内部設計の詳細は対象外

📄 成果物の定義


🧪成果物のサンプル
# 機能要件一覧

## 追加・変更する機能一覧

| 機能ID | 機能分類 | 機能名 | 変更区分 | 該当業務 | 利用者区分 | 概要 |
|--------|----------|--------|----------|----------|------------|------|
| F-001 | 認証 | ログイン機能 | 新規 | 全業務 | 全利用者 | ユーザーIDとパスワードによる認証を行う |
| F-002 | マスタ管理 | 商品マスタ登録 | 変更 | 商品管理 | 管理者 | 商品情報の登録・更新・削除を行う。画像登録機能を追加 |
| F-003 | 帳票出力 | 月次レポート出力 | 削除 | 経理業務 | 経理担当 | システム統合により不要となるため削除 |

## 将来的に追加予定の機能一覧

| 機能ID | 機能名 | 追加予定時期 | 概要 |
|--------|--------|--------------|------|
| F-100 | AI推奨機能 | Phase2 | ユーザーの行動履歴から商品を推奨 |
| F-101 | 多言語対応 | Phase3 | 英語・中国語のインターフェース提供 |

## 機能構成概念図

サービスの機能構成概念図を示す。なお、図の記載内容が過度に複雑化することを避けるため、機能分類に着目し、各機能の位置関係と情報フローに焦点を当てて表現する。

```mermaid
graph TB
    subgraph "プレゼンテーション層"
        A[Webブラウザ]
        B[モバイルアプリ]
    end
    
    subgraph "アプリケーション層"
        C[認証・認可]
        D[業務処理]
        E[帳票出力]
    end
    
    subgraph "データ層"
        F[マスタDB]
        G[トランザクションDB]
        H[ファイルストレージ]
    end
    
    subgraph "外部連携"
        I[外部決済API]
        J[メール配信サービス]
    end
    
    A --> C
    B --> C
    C --> D
    D --> F
    D --> G
    D --> H
    D --> I
    E --> G
    E --> J
```
---
✅ 品質基準
区分 観点 内容
必須 対象範囲の明確化 「追加・変更する機能一覧」に、今回スコープ内の機能が 漏れなく 記載されている(新規/変更/削除が明示されている)
必須 識別子の一貫性 機能IDが一意で、別成果物(画面一覧、API一覧、処理概要など)で参照可能な粒度・命名になっている
必須 業務との紐付け 各機能に「該当業務」および「利用者区分」が設定され、関係者が影響範囲を判断できる
推奨 将来機能の切り分け 将来的に追加予定の機能が、現スコープと混ざらないように別表で管理されている
👁️‍🗨️ レビュー観点
観点カテゴリ 質問例
スコープ整合 今回の対象(In/Out)と、機能一覧の内容は一致しているか。Out of scope が混入していないか
粒度・重複 機能が大きすぎないか、細かすぎないか。似た機能が重複登録されていないか
変更区分の妥当性 「新規/変更/削除」の判断は合意できるか。削除の場合、移行・代替機能の扱いが整理されているか
業務影響 該当業務・利用者区分から見て、影響範囲の説明が不足していないか

📚 参考資料・関連リンク


🚧 実例収集後、追記予定


テンプレートサイト: 📄Arrow icon of a page linkテンプレート集