Requirements Engineering
要求工学（Requirements Engineering）概要
1. はじめに — 要求工学とは
1.1 要求工学の定義
要求工学（Requirements Engineering, RE）とは、ソフトウェアシステムやプロダクトの開発において、ステークホルダーの要望・制約・前提条件を体系的に抽出（Elicitation）・分析（Analysis）・仕様化（Specification）・検証（Validation）・**管理（Management）**する一連の学問領域および実践プロセスを指す。
IEEE 610.12-1990 では「要求」を次のように定義している。
要求（Requirement）: ユーザーが問題を解決するため、または目的を達成するために必要な条件や能力。あるいは、契約・標準・仕様・その他の形式的に課せられた文書を満たすために、システムまたはシステムコンポーネントが備えなければならない条件や能力。
要求工学はこの「要求」を扱う工学であり、単なるヒアリングや文書作成にとどまらず、プロジェクト全体の成功を左右する基盤的活動として位置づけられる。
1.2 なぜ要求工学が重要なのか
ソフトウェアプロジェクトの失敗原因の多くが要求に関連していることは、数多くの調査で裏付けられている。
| 調査・報告 | 主要な知見 |
|---|---|
| Standish Group CHAOS Report (2020) | プロジェクト失敗の主要因トップ3に「不完全な要求」「要求の頻繁な変更」「ユーザー関与の不足」が含まれる |
| NASA JPL 調査 | 欠陥の約 40〜50% が要求フェーズに起因 |
| Boehm の研究 | 要求段階の欠陥を後工程で修正するコストは、初期修正の 50〜200 倍 |
| IBM Systems Sciences Institute | 保守フェーズで発見された欠陥の修正コストは、要求フェーズの 100 倍以上 |
この「欠陥修正コストの増幅」は、要求工学が開発ライフサイクル初期にいかに重要であるかを端的に示している。
修正コスト
^
| ● 保守
| ● テスト
| ● 結合テスト
| ● コーディング
| ● 設計
| ● 要求
+----------------------------------------------------> 開発フェーズ
1x 5x 10x 20x 50x 100x 200x
1.3 要求工学の適用範囲
要求工学は以下のような幅広い領域で適用される。
- エンタープライズシステム開発: ERP、CRM、基幹業務システム
- 組込みシステム: 自動車 ECU、医療機器、航空宇宙
- Web/モバイルアプリケーション: SaaS、スマートフォンアプリ
- AI/ML システム: 学習データ要求、公平性・説明可能性の要求
- 規制対象システム: 金融、医療、防衛（HIPAA、SOX、DO-178C 等）
1.4 要求工学と関連分野の関係
┌──────────────────────────────────────────────────┐
│ プロジェクトマネジメント │
│ ┌────────────────────────────────────────────┐ │
│ │ 要求工学 │ │
│ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │
│ │ │ 抽出 │→│ 分析 │→│ 仕様 │→│ 検証 │ │ │
│ │ └──────┘ └──────┘ └──────┘ └──────┘ │ │
│ │ ↕ ↕ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ 要求管理 │ │ │
│ │ └──────────────────────────────────┘ │ │
│ └────────────────────────────────────────────┘ │
│ ↕ ↕ ↕ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ ドメイン │ │ ソフトウェア│ │ システム │ │
│ │ 工学 │ │ アーキテク │ │ テスト │ │
│ │ │ │ チャ設計 │ │ │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
└──────────────────────────────────────────────────┘
1.5 本記事の構成
本記事では以下の構成で要求工学の全容を解説する。
- はじめに — 本章
- 歴史と発展 — 要求工学の成り立ち
- 要求のライフサイクル — 主要プロセスの全体像
- 要求の種類と分類 — 機能要求・非機能要求の体系
- 要求抽出 — ステークホルダーから要求を引き出す技法
- 要求分析とモデリング — 抽出した要求を構造化する手法
- 要求仕様化 — SRS の書き方とテンプレート
- 要求の検証と妥当性確認 — 品質を担保する手法
- 要求管理 — 変更管理とトレーサビリティ
- 非機能要求の体系化 — ISO 25010 に基づく品質モデル
- ユースケースとユーザーストーリー — 実践的記述手法
- アジャイルにおける要求工学 — 反復開発での要求の扱い
- 要求工学のツールとフレームワーク — 代表的ツールの比較
- 要求品質メトリクス — 定量的評価手法
- 実践的テンプレートと設定例 — すぐに使える成果物
- アンチパターンと対策 — 陥りがちな落とし穴
- ケーススタディ — 具体的な適用事例
- まとめと今後の展望 — AI 時代の要求工学
2. 要求工学の歴史と発展
2.1 黎明期（1960〜1970年代）
要求工学の起源は、1960年代のソフトウェア危機（Software Crisis）にまで遡る。大規模ソフトウェアプロジェクトの相次ぐ失敗を受けて、1968年のNATO Software Engineering Conference で「ソフトウェア工学」という概念が提唱された。この時期、要求は主にシステム仕様書として自然言語で記述されていたが、曖昧さや不整合が大きな問題となっていた。
1970年代に入ると、以下の重要な概念が確立された。
- 構造化分析（Structured Analysis）: Tom DeMarco（1978）がデータフロー図（DFD）を用いた体系的な要求分析手法を提唱
- 情報工学（Information Engineering）: James Martin がデータ中心のアプローチを提唱
- PSL/PSA: ISDOS プロジェクト（ミシガン大学）による初の要求仕様記述言語
2.2 確立期（1980〜1990年代）
1980年代から1990年代にかけて、要求工学は独立した学問分野として確立された。
主要なマイルストーン
| 年 | 出来事 |
|---|---|
| 1984 | IEEE 830 標準（SRS の推奨プラクティス）初版 |
| 1993 | 第1回 IEEE International Symposium on Requirements Engineering (RE) 開催 |
| 1993 | Jackson の Problem Frames アプローチ発表 |
| 1994 | ゴール指向要求工学（GORE）の本格的研究開始 |
| 1995 | Viewpoints フレームワーク（Finkelstein ら）の提案 |
| 1997 | i* フレームワーク（Eric Yu）の提唱 |
| 1998 | VOLERE 要求仕様テンプレートの公開 |
この時期の重要な貢献として、ゴール指向要求工学（Goal-Oriented Requirements Engineering, GORE） がある。KAOS（Knowledge Acquisition in Automated Specification）や i* フレームワークは、「なぜ」という意図レベルから要求を導出するアプローチを提供した。
2.3 発展期（2000〜2010年代）
2000年代以降、アジャイル開発の台頭により要求工学は大きな転換点を迎えた。
- ユーザーストーリー: XP（Extreme Programming）の実践から生まれた軽量な要求記述
- プロダクトバックログ: Scrum における要求管理の中心概念
- 継続的要求工学: DevOps と CI/CD の普及に伴う要求の反復的精練
- ドメイン駆動設計（DDD）: Eric Evans（2003）による、ドメインモデルと要求の密接な統合
また、モデル駆動型要求工学（Model-Driven RE）やフォーマルメソッドの実用化も進んだ。
2.4 現代（2020年代〜）
現在の要求工学は以下のトレンドに影響を受けている。
-
AI/ML による要求工学の自動化
- 自然言語処理（NLP）による要求文書の品質チェック
- 機械学習による要求の自動分類・優先順位付け
- 大規模言語モデル（LLM）による要求生成支援
-
データ駆動型要求工学
- ユーザー行動データからの要求推論
- A/B テスト結果に基づく要求の検証
- アプリストアレビューからの要求マイニング
-
規制・コンプライアンスの高度化
- GDPR、AI Act（EU）、個人情報保護法への適合要求
- AI システムの説明可能性・公平性の要求
- サプライチェーンセキュリティの要求
-
持続可能性要求（Sustainability Requirements）
- グリーンソフトウェア要求
- エネルギー効率・カーボンフットプリントの要求
- 社会的影響評価の統合
3. 要求工学のライフサイクル
3.1 全体プロセスモデル
要求工学のプロセスは反復的かつ並行的に実行されるが、概念的には以下の5つの主要活動に分解できる。
┌─────────────────────────────┐
│ 要求工学プロセス │
└─────────────────────────────┘
│
┌──────────┬─────────┬──────────┬──────────┐
↓ ↓ ↓ ↓ ↓
┌─────────┐┌─────────┐┌─────────┐┌─────────┐┌─────────┐
│ 抽出 ││ 分析 ││ 仕様化 ││ 検証 ││ 管理 │
│Elicit- ││Analysis ││Specifi- ││Valida- ││Manage- │
│ation ││ ││cation ││tion ││ment │
└────┬────┘└────┬────┘└────┬────┘└────┬────┘└────┬────┘
│ │ │ │ │
└──────────┴─────────┴──────────┴──────────┘
↕ フィードバックループ
3.2 各プロセスの関係性
これらの活動はウォーターフォール的に順序立てて実行されるものではなく、状況に応じて反復的・並行的に進められる。
時間軸 →
┌────────────────────────────────────────────────────────┐
│ 抽出 ████████░░░░░░████░░░░░████░░░░░░░░░░ │
│ 分析 ░░░░████████░░░░████░░░░░████░░░░░░░░ │
│ 仕様化 ░░░░░░░░████████░░░░████░░░░████░░░░░ │
│ 検証 ░░░░░░░░░░░░████████░░░░████░░░░████░ │
│ 管理 ░░██████████████████████████████████░░ │
└────────────────────────────────────────────────────────┘
████ = アクティブな活動
3.3 要求工学プロセスの入出力
各活動の入出力を明確にすることで、プロセス全体の流れを理解できる。
| 活動 | 主な入力 | 主な出力 |
|---|---|---|
| 抽出 | ステークホルダー、既存文書、ドメイン知識、レガシーシステム | 要求候補リスト、ステークホルダーマップ、ドメインモデル（草案） |
| 分析 | 要求候補リスト、ドメイン知識 | 整理された要求セット、競合分析結果、優先順位付き要求リスト |
| 仕様化 | 分析済み要求セット | 要求仕様書（SRS）、要求モデル（ユースケース図、状態遷移図等） |
| 検証 | SRS、要求モデル | レビュー報告書、検証結果、承認済み要求ベースライン |
| 管理 | 承認済みベースライン、変更要求 | 更新済み SRS、トレーサビリティマトリクス、変更履歴 |
3.4 プロセスモデルの種類
要求工学プロセスを組織内でどのように構成するかについて、複数のプロセスモデルが提案されている。
3.4.1 線形プロセスモデル
最も単純なモデルで、各活動を順番に実行する。小規模で安定した要求を持つプロジェクトに適している。
抽出 → 分析 → 仕様化 → 検証 → [ベースライン確定]
3.4.2 反復プロセスモデル
各活動を繰り返し実行し、段階的に要求を精緻化する。
┌─────────────────────────┐
↓ │
抽出 → 分析 → 仕様化 → 検証 ──┘
(ベースラインが安定するまで反復)
3.4.3 スパイラルプロセスモデル
リスク駆動で要求を段階的に詳細化する。Boehm のスパイラルモデルに対応。
リスク分析
╱ ╲
計画 抽出・分析
╲ ╱
仕様・検証
3.4.4 アジャイルプロセスモデル
要求を継続的に発見・精緻化する。各イテレーションで「ジャスト・イン・タイム」の要求工学を実施。
Sprint 1 Sprint 2 Sprint 3
┌───────────┐ ┌───────────┐ ┌───────────┐
│ 抽出→分析 │ │ 抽出→分析 │ │ 抽出→分析 │
│ ↓ │ │ ↓ │ │ ↓ │
│ 仕様→検証 │ │ 仕様→検証 │ │ 仕様→検証 │
│ ↓ │ │ ↓ │ │ ↓ │
│ 実装→テスト│ │ 実装→テスト│ │ 実装→テスト│
└───────────┘ └───────────┘ └───────────┘
↑ ↑ ↑
└── プロダクトバックログの継続的精緻化 ──┘
3.5 プロセステーラリング
実際のプロジェクトでは、上記のモデルをそのまま適用するのではなく、プロジェクトの特性に合わせてテーラリング（tailoring）する必要がある。
テーラリングの判断基準
| 要素 | 軽量プロセス | 重量プロセス |
|---|---|---|
| プロジェクト規模 | 小〜中 | 大 |
| ドメインの安定性 | 変化が頻繁 | 安定 |
| 規制の有無 | 規制なし | 厳格な規制あり |
| チームの分散度 | 同一拠点 | 分散・オフショア |
| 要求の明確度 | 不明確・探索的 | 比較的明確 |
| リスクの大きさ | 低〜中 | 高（人命・金融） |
4. 要求の種類と分類
4.1 基本的な分類体系
要求は大きく以下の3つの階層に分類される。
┌──────────────────────────────────────────────┐
│ ビジネス要求 │
│ （Business Requirements） │
│ ビジネス目標、ROI、市場ニーズ │
├──────────────────────────────────────────────┤
│ ユーザー要求 │
│ （User Requirements） │
│ ユーザーが達成したいタスク・目標 │
├──────────────────────────┬───────────────────┤
│ 機能要求 │ 非機能要求 │
│ （Functional Req.） │ （Non-Functional） │
│ システムが「何をするか」 │ システムが「どう │
│ │ あるべきか」 │
├──────────────────────────┴───────────────────┤
│ 制約条件 │
│ （Constraints） │
│ 技術的制約、ビジネス制約、法規制 │
└──────────────────────────────────────────────┘
4.2 ビジネス要求
ビジネス要求は、プロジェクトの存在理由を示す最上位レベルの要求である。
具体例: EC サイトプロジェクト
BR-001: 年間オンライン売上を前年比 30% 増加させる
BR-002: 顧客獲得コスト（CAC）を 20% 削減する
BR-003: 注文から配送までのリードタイムを 48 時間以内にする
BR-004: 海外市場（北米・欧州）からの売上比率を 15% にする
4.3 ユーザー要求
ユーザー要求は、エンドユーザーの視点から記述された要求である。
具体例
UR-001: 顧客は商品をカテゴリ別に閲覧できること
UR-002: 顧客は商品を名前・価格・人気度で並べ替えできること
UR-003: 顧客はクレジットカード・電子マネー・銀行振込で決済できること
UR-004: 店舗管理者は在庫状況をリアルタイムで確認できること
UR-005: 配送担当者は配送ルートの最適化提案を受けられること
4.4 機能要求（Functional Requirements）
機能要求は、システムが提供すべき具体的な機能・振る舞いを定義する。
記述のベストプラクティス: SHALL 文型
FR-001: システムは、ユーザーがメールアドレスとパスワードを入力して
ログインを要求した場合、認証サーバーに対して資格情報を検証
しなければならない（SHALL）。
FR-002: システムは、認証に成功した場合、JWT トークンを発行し、
有効期限を 24 時間に設定しなければならない（SHALL）。
FR-003: システムは、認証に 3 回連続で失敗した場合、当該アカウントを
30 分間ロックしなければならない（SHALL）。
FR-004: システムは、商品検索時に最大 1,000 件の結果を返却する
ことができる（MAY）。ただし、デフォルトでは 20 件を表示
するものとする（SHALL）。
RFC 2119 キーワードの使い分け
- SHALL / MUST: 必須の要求（実装しなければならない）
- SHOULD: 推奨の要求（特別な理由がない限り実装すべき）
- MAY: 任意の要求（実装してもよい）
- SHALL NOT / MUST NOT: 禁止事項
4.5 非機能要求（Non-Functional Requirements）
非機能要求は、システムの品質属性を定義する。詳細は第10章で解説するが、ここでは概要を示す。
| カテゴリ | 例 |
|---|---|
| 性能 | 応答時間 200ms 以内、同時接続 10,000 ユーザー |
| 可用性 | 稼働率 99.95%（年間停止 4.38 時間以内） |
| セキュリティ | OWASP Top 10 対策、暗号化（AES-256） |
| 保守性 | コードカバレッジ 80% 以上、循環的複雑度 15 以下 |
| 移植性 | Docker コンテナ化、マルチクラウド対応 |
| 使用性 | SUS スコア 70 以上、タスク完了率 90% 以上 |
4.6 制約条件（Constraints）
制約条件は、設計や実装の選択肢を制限する条件である。
## 技術的制約
CON-001: バックエンドは Java 21 (LTS) で実装すること
CON-002: データベースは PostgreSQL 16 を使用すること
CON-003: クラウド環境は AWS ap-northeast-1 リージョンを使用すること
CON-004: 既存の認証基盤（LDAP）との統合が必要
## ビジネス制約
CON-101: 初回リリースは 2025年6月30日 までに完了すること
CON-102: 開発予算は 5,000 万円以内とすること
CON-103: 開発チームは最大 8 名とする
## 法規制制約
CON-201: 個人情報保護法に準拠すること
CON-202: PCI DSS v4.0 に準拠した決済処理を実装すること
CON-203: 特定電子メール法に準拠したメール配信を行うこと
4.7 要求の属性
各要求には以下の属性を付与して管理する。
| 属性 | 説明 | 例 |
|---|---|---|
| ID | 一意の識別子 | FR-001, NFR-042 |
| タイトル | 簡潔な名称 | ユーザーログイン認証 |
| 説明 | 詳細な記述 | （本文） |
| 優先度 | 重要度と緊急度 | Must / Should / Could / Won't |
| ソース | 要求の出所 | ステークホルダー名、法規制 |
| ステータス | 現在の状態 | Draft / Approved / Implemented |
| バージョン | 変更履歴 | v1.0 → v1.1 |
| 受入基準 | 検証条件 | テスト条件の記述 |
| 関連要求 | 依存関係 | FR-002 に依存 |
4.8 MoSCoW 優先順位付け
要求の優先順位付けには MoSCoW 法が広く使われる。
┌─────────────────────────────────────────────┐
│ Must have (必須) │
│ - なければリリースできない要求 │
│ - 全体の約 60% 以下を目安 │
│ 例: ユーザー認証、決済処理、注文管理 │
├─────────────────────────────────────────────┤
│ Should have (重要) │
│ - なくてもリリースは可能だが、強く望まれる │
│ - 全体の約 20% 程度 │
│ 例: メール通知、検索フィルター、ダッシュボード │
├─────────────────────────────────────────────┤
│ Could have (あると良い) │
│ - あればユーザー体験が向上する │
│ - リソースに余裕があれば実装 │
│ 例: ダークモード、お気に入り、SNS 共有 │
├─────────────────────────────────────────────┤
│ Won't have (今回は対象外) │
│ - 将来のリリースで検討 │
│ 例: 多言語対応、AI レコメンド、AR 試着 │
└─────────────────────────────────────────────┘
5. 要求抽出（Requirements Elicitation）
5.1 要求抽出の概要
要求抽出は、ステークホルダーの明示的・暗黙的な要望を発見・収集する活動である。「要求を集める」のではなく「要求を引き出す」という能動的な性質を持つ。
5.2 ステークホルダー分析
要求抽出に先立ち、誰から要求を引き出すべきかを特定する。
ステークホルダーマップの例
影響力 高
│
┌────────────┼────────────┐
│ │ │
│ 経営層 │ プロダクト │
│ スポンサー │ オーナー │
│ │ │
関心低 ─┼────────────┼────────────┼─ 関心高
│ │ │
│ 法務部門 │ エンド │
│ セキュリティ│ ユーザー │
│ チーム │ サポート │
│ │ │
└────────────┼────────────┘
│
影響力 低
RACI マトリクス例
| ステークホルダー | 要求定義 | 要求レビュー | 要求承認 | 変更要求 |
|---|---|---|---|---|
| プロダクトオーナー | R | A | A | A |
| ビジネスアナリスト | A | R | C | R |
| エンドユーザー代表 | C | R | C | I |
| 開発リード | C | R | I | C |
| QA リード | I | R | I | C |
| 経営スポンサー | I | I | R | I |
R = Responsible, A = Accountable, C = Consulted, I = Informed
5.3 抽出技法
5.3.1 インタビュー
最も基本的かつ効果的な技法。構造化・半構造化・非構造化の3タイプがある。
半構造化インタビューのテンプレート例
# インタビューシート
## 基本情報
- 日時: 2025-04-15 14:00-15:00
- 対象者: 山田太郎（営業部 部長）
- インタビュアー: 佐藤花子（ビジネスアナリスト）
- 記録者: 鈴木一郎
## コンテキスト質問
1. 現在の業務プロセスを教えてください
2. 日常的に直面している課題は何ですか？
3. 理想的な状態はどのようなものですか？
## 具体的質問
4. 受注処理で最も時間がかかるステップはどこですか？
5. 月末の集計作業にどれくらいの時間を費やしていますか？
6. 現行システムで最も不満に感じる機能は何ですか？
## 優先順位
7. 改善したい項目を重要度順に3つ挙げてください
8. 新システムに最低限必要な機能は何ですか？
## オープン質問
9. 他に新システムに期待することはありますか？
10. 見落としていそうな課題はありますか？
5.3.2 ワークショップ（JAD: Joint Application Development）
複数のステークホルダーを一堂に集めて、共同で要求を定義する。
ワークショップ設計の例
# 要求定義ワークショップ計画
## 目的
EC サイトリニューアルの主要機能要求を特定・優先順位付けする
## 参加者（8-12名）
- プロダクトオーナー ×1
- ビジネス部門代表 ×3（営業、マーケ、CS）
- エンドユーザー代表 ×2
- 開発リード ×1
- UX デザイナー ×1
- ファシリテーター ×1
- 記録係 ×1
## アジェンダ（1日）
### 午前: 発散（Diverge）
09:00-09:30 アイスブレイク、目的共有
09:30-10:30 現状分析（As-Is プロセスマッピング）
10:30-10:45 休憩
10:45-12:00 ブレインストーミング（理想状態の定義）
### 午後: 収束（Converge）
13:00-14:00 要求の整理・グルーピング（親和図法）
14:00-15:00 優先順位付け（ドット投票 + MoSCoW）
15:00-15:15 休憩
15:15-16:30 ユーザーストーリーマッピング
16:30-17:00 まとめ、次のステップ確認
5.3.3 プロトタイピング
動作するモデルを用いて要求を可視化・検証する。
┌─────────────────────────────────────┐
│ プロトタイピングの種類 │
├──────────────┬──────────────────────┤
│ 使い捨て型 │ 進化型 │
│ (Throwaway) │ (Evolutionary) │
├──────────────┼──────────────────────┤
│ 目的: │ 目的: │
│ 要求の明確化 │ 段階的なシステム構築 │
│ リスク検証 │ │
├──────────────┼──────────────────────┤
│ 手法: │ 手法: │
│ ペーパー │ MVP │
│ Wireframe │ インクリメンタル開発 │
│ Figma モック │ │
├──────────────┼──────────────────────┤
│ プロト完成後: │ プロト完成後: │
│ 破棄する │ 本番システムに発展 │
└──────────────┴──────────────────────┘
5.3.4 観察（Ethnography）
ユーザーの実際の作業を観察して暗黙的な要求を発見する。
観察記録シートの例
# フィールド観察記録
## 観察情報
- 日時: 2025-04-16 09:00-12:00
- 場所: 営業部フロア
- 対象: 受注処理担当（3名）
- 観察者: 佐藤花子
## 観察記録
| 時刻 | 行動 | 使用ツール | メモ |
|------|------|-----------|------|
| 09:05 | メールで受注確認 | Outlook | FAX 注文書のPDF添付が多い |
| 09:15 | 注文内容を手入力 | Excel | 品番を目視で転記、ミスリスク |
| 09:30 | 在庫確認 | 基幹システム | 画面遷移が6回、30秒以上 |
| 09:35 | 在庫不足のため電話 | 電話 | 倉庫担当に直接確認 |
| 10:00 | 見積書作成 | Word | テンプレートをコピーして編集 |
## 発見した暗黙的要求
1. FAX/PDF からの自動データ抽出（OCR）の必要性
2. 在庫確認の画面遷移を最小化する UI 設計
3. 倉庫システムとのリアルタイム在庫連携
4. 見積書テンプレートの自動生成
5.3.5 その他の技法
| 技法 | 適用場面 | 特徴 |
|---|---|---|
| アンケート | 多数のステークホルダーから定量的データ収集 | 規模は大きいが深さに限界 |
| ドキュメント分析 | 既存文書・レガシーシステムからの要求抽出 | 現行仕様の理解に有効 |
| フォーカスグループ | ユーザーグループの嗜好・態度の把握 | ユーザー体験要求の発見 |
| ストーリーボーディング | ユーザー体験フローの可視化 | UI/UX 要求の発見 |
| カードソーティング | 情報アーキテクチャの設計 | ナビゲーション要求の発見 |
| ペルソナ分析 | ユーザー特性の具象化 | 異なるユーザー群の要求理解 |
| コンテキスト図 | システム境界とインターフェースの明確化 | スコープ定義に有効 |
5.4 抽出時の課題と対策
| 課題 | 原因 | 対策 |
|---|---|---|
| 暗黙知の表出困難 | ユーザーが当たり前と思っている知識 | 観察法、タスク分析 |
| ステークホルダー間の矛盾 | 立場の違いによる利害対立 | ワークショップ、交渉 |
| スコープクリープ | 要求の際限のない拡大 | スコープ定義、MoSCoW |
| コミュニケーションギャップ | 専門用語の相互不理解 | 用語集、プロトタイプ |
| 分析麻痺（Analysis Paralysis） | 過剰な分析による停滞 | タイムボックス、MVP |
6. 要求分析とモデリング
6.1 要求分析の目的
要求分析は、抽出した生の要求を整理・構造化し、矛盾や曖昧さを解消するプロセスである。
6.2 分析の主要活動
抽出された生の要求
│
↓
┌──────────────┐ ┌──────────────┐
│ 分類・整理 │───→│ 矛盾の検出 │
└──────────────┘ └──────────────┘
│ │
↓ ↓
┌──────────────┐ ┌──────────────┐
│ モデリング │←───│ 交渉・合意 │
└──────────────┘ └──────────────┘
│
↓
構造化された要求セット
6.3 ゴール指向分析（GORE）
ゴール指向要求工学は、「なぜこの要求が必要か」を明示的に扱うアプローチである。
6.3.1 ゴール分解ツリー
ビジネスゴール
「EC サイトの売上向上」
╱ ╲
サブゴール1 サブゴール2
「購買体験の向上」 「集客力の強化」
╱ ╲ ╱ ╲
「検索の 「決済の 「SEO 「リター
改善」 簡素化」 最適化」 ゲティング」
│ │ │ │
FR-010 FR-020 FR-030 FR-040
全文検索 ワンクリック 構造化 Cookie
エンジン 決済 データ ベースの
導入 マークアップ 広告配信
6.3.2 KAOS モデル
KAOS（Knowledge Acquisition in Automated Specification）は、形式的なゴールモデリング手法である。
<<ゴール>> <<ゴール>>
Achieve[注文が24h以内に発送] Maintain[在庫切れ率 < 2%]
│ │
┌────┴────┐ ┌──────┴──────┐
│ │ │ │
<<ゴール>> <<ゴール>> <<期待>> <<要求>>
注文の即時 配送手配の 仕入先が翌日 在庫自動
処理 自動化 納品可能 発注システム
│ │
<<エージェント>> <<エージェント>>
注文処理システム 在庫管理システム
6.4 ユースケース分析
6.4.1 ユースケース図
┌─────────────── EC システム ───────────────────┐
│ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ 商品を検索する │ │ 商品をカートに │ │
│ │ │ │ 追加する │ │
│ └──────┬───────┘ └────────┬─────────┘ │
│ │ <<include>> │ │
│ 顧客 ─┤─────────────────────┤ │
│ (Actor) │ │ │
│ │ ┌──────────────┐ │ │
│ ├──│ 注文を確定する │ │ │
│ │ └──────┬───────┘ │ │
│ │ │<<include>>│ │
│ │ ┌──────┴───────┐ │ │
│ │ │ 決済を行う │ │ │
│ │ └──────────────┘ │ │
│ │ │
│ │ ┌──────────────┐ │
│ └──│ 注文履歴を │ │
│ │ 確認する │ │
│ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ 在庫を管理する │ │ 売上レポートを │ │
│ │ │ │ 確認する │ │
│ └──────┬───────┘ └────────┬─────────┘ │
│ │ │ │
│ 管理者 ─┘ │ │
│ (Actor)────────────────────────┘ │
└───────────────────────────────────────────────┘
6.4.2 ユースケース記述の詳細テンプレート
# ユースケース記述: UC-003 注文を確定する
## 基本情報
- **ユースケースID**: UC-003
- **名前**: 注文を確定する
- **アクター**: 顧客（プライマリ）、決済ゲートウェイ（セカンダリ）
- **前提条件**: 顧客がログイン済み、カートに1つ以上の商品がある
- **事後条件（成功時）**: 注文が確定し、注文確認メールが送信される
- **事後条件（失敗時）**: カートの状態が維持される
## 基本フロー（Main Success Scenario）
1. 顧客がカート画面で「注文に進む」を選択する
2. システムがカート内商品の在庫状況を確認する
3. システムが配送先入力フォームを表示する
4. 顧客が配送先情報を入力する
5. システムが配送オプション（通常/お急ぎ/日時指定）を表示する
6. 顧客が配送オプションを選択する
7. システムが決済情報入力フォームを表示する
8. 顧客が決済情報を入力する
9. システムが注文サマリーを表示する
10. 顧客が「注文を確定する」を選択する
11. システムが決済ゲートウェイに決済要求を送信する
12. 決済ゲートウェイが決済を承認する
13. システムが注文を確定し、注文番号を発行する
14. システムが注文確認メールを送信する
15. システムが注文完了画面を表示する
## 代替フロー
### 2a. 在庫不足の場合
2a.1 システムが在庫不足の商品を表示する
2a.2 顧客が数量変更または商品削除を行う
2a.3 ステップ 2 に戻る
### 4a. 保存済み住所を使用する場合
4a.1 システムが保存済み住所一覧を表示する
4a.2 顧客が住所を選択する
4a.3 ステップ 5 に進む
### 12a. 決済が拒否された場合
12a.1 システムがエラーメッセージを表示する
12a.2 顧客が別の決済手段を選択する
12a.3 ステップ 8 に戻る
## 例外フロー
### E1. セッションタイムアウト
E1.1 システムがログイン画面にリダイレクトする
E1.2 ログイン後、カート画面に復帰する
### E2. 決済ゲートウェイ接続失敗
E2.1 システムが「しばらくしてからお試しください」を表示する
E2.2 カート状態を保持する
## 非機能要求
- ステップ 2 の在庫確認は 500ms 以内に完了すること
- ステップ 11-12 の決済処理は TLS 1.3 で暗号化すること
- ステップ 13 の注文データは即座に永続化すること（ACID 準拠）
6.5 データフロー図（DFD）
レベル 0（コンテキスト図）:
┌────────┐ ┌────────┐
│ 顧客 │──── 注文情報 ────→ │ 決済 │
│ │←─── 注文確認 ──── ┌───┐ │ ゲート │
└────────┘ │ EC │ │ ウェイ │
│ シ │ └────────┘
┌────────┐ │ ス │
│ 管理者 │──── 商品情報 ────→│ テ │ ┌────────┐
│ │←─── レポート ──── │ ム │ │ 配送 │
└────────┘ └───┘──→│ 業者 │
└────────┘
6.6 状態遷移図
注文のライフサイクル:
┌──────┐ 注文確定 ┌──────┐ 決済承認 ┌──────┐
│ カート│────────────→│ 仮注文│──────────→│ 確定 │
│ 中 │ │ │ │ │
└──────┘ └───┬──┘ └───┬──┘
│ 決済失敗 │ 出荷指示
↓ ↓
┌──────┐ ┌──────┐
│決済 │ │ 出荷 │
│エラー │ │ 準備 │
└──────┘ └───┬──┘
│ 発送完了
↓
┌──────┐ 返品受理 ┌──────┐ 配達完了 ┌──────┐
│ 返品 │←────────────│ 配達 │←──────────│ 配送 │
│ │ │ 済み │ │ 中 │
└──────┘ └──────┘ └──────┘
6.7 ドメインモデリング
ドメインモデルはビジネス概念とその関係を表現する。
┌──────────────┐ ┌──────────────┐
│ 顧客 │ │ 注文 │
│──────────────│ │──────────────│
│ 顧客ID │1 *│ 注文ID │
│ 名前 │────→│ 注文日 │
│ メール │ │ ステータス │
│ 住所 │ │ 合計金額 │
└──────────────┘ └──────┬───────┘
│1
│
│*
┌──────┴───────┐ ┌──────────────┐
│ 注文明細 │ │ 商品 │
│──────────────│ │──────────────│
│ 明細ID │* 1│ 商品ID │
│ 数量 │────→│ 商品名 │
│ 単価 │ │ 価格 │
│ 小計 │ │ 在庫数 │
└──────────────┘ │ カテゴリ │
└──────────────┘
7. 要求仕様化（Requirements Specification）
7.1 要求仕様書（SRS）の概要
要求仕様書（Software Requirements Specification, SRS）は、要求工学の主要な成果物である。IEEE 830-1998（後に IEEE 29148:2018 に統合）に基づく構造が広く採用されている。
7.2 SRS の品質特性
良い SRS が満たすべき品質特性（IEEE 830 準拠）:
| 特性 | 定義 | 悪い例 | 良い例 |
|---|---|---|---|
| 正確（Correct） | 実際のニーズを正しく反映 | 「高速に動作すること」 | 「応答時間 200ms 以内」 |
| 明確（Unambiguous） | 解釈が一つに定まる | 「適切なセキュリティ」 | 「TLS 1.3 + AES-256」 |
| 完全（Complete） | 必要な情報がすべて含まれる | 異常系の記述なし | 正常・異常・境界条件を網羅 |
| 一貫（Consistent） | 矛盾がない | FR-01 と FR-05 が矛盾 | 相互参照で整合性確認 |
| 検証可能（Verifiable） | テスト可能 | 「使いやすいこと」 | 「SUS スコア 70 以上」 |
| 追跡可能（Traceable） | 元の要求を辿れる | ID なし | BR→UR→FR の追跡可能 |
| 変更可能（Modifiable） | 変更が容易 | 要求が散在 | 要求ごとに独立した記述 |
| ランク付け（Ranked） | 優先度が明示 | 優先度なし | MoSCoW で分類 |
7.3 SRS テンプレート（IEEE 29148:2018 ベース）
以下に実践的な SRS テンプレートの全体構造を示す。
# ソフトウェア要求仕様書（SRS）
# プロジェクト名: [プロジェクト名]
## 文書情報
| 項目 | 内容 |
|------|------|
| 文書ID | SRS-PRJ-001 |
| バージョン | 1.0 |
| 作成日 | 2025-04-15 |
| 最終更新日 | 2025-04-15 |
| ステータス | Draft / Review / Approved |
| 作成者 | [氏名] |
| 承認者 | [氏名] |
## 変更履歴
| バージョン | 日付 | 変更者 | 変更内容 |
|-----------|------|--------|---------|
| 0.1 | 2025-03-01 | 佐藤 | 初稿作成 |
| 0.9 | 2025-04-01 | 佐藤 | レビュー反映 |
| 1.0 | 2025-04-15 | 田中 | 承認 |
---
## 1. はじめに
### 1.1 目的
本文書は [システム名] のソフトウェア要求を定義する。
対象読者は [プロダクトオーナー、開発チーム、QA チーム、...] である。
### 1.2 スコープ
[システムが何を含み、何を含まないか]
### 1.3 定義・略語・参考文書
| 用語 | 定義 |
|------|------|
| SRS | Software Requirements Specification |
| API | Application Programming Interface |
| JWT | JSON Web Token |
### 1.4 参照文書
- [ビジネス要求書] BRD-PRJ-001 v2.0
- [プロジェクト計画書] PP-PRJ-001 v1.0
- [ドメインモデル] DM-PRJ-001 v1.0
---
## 2. 全体的な説明
### 2.1 プロダクトの全体像
[コンテキスト図、システム境界の説明]
### 2.2 プロダクト機能の概要
[主要機能の一覧（詳細は第3章）]
### 2.3 ユーザー特性
[ペルソナまたはユーザークラスの定義]
### 2.4 制約条件
[技術的・ビジネス的・法規制的制約]
### 2.5 前提条件と依存関係
[プロジェクトの前提条件]
---
## 3. 機能要求
### 3.1 ユーザー認証機能
#### FR-AUTH-001: ユーザー登録
- **説明**: システムは、メールアドレス・パスワード・氏名を用いた
新規ユーザー登録機能を提供しなければならない
- **優先度**: Must
- **ソース**: UR-001
- **受入基準**:
1. メールアドレスの形式バリデーション（RFC 5322）
2. パスワード要件: 8文字以上、大文字・小文字・数字を含む
3. 確認メール送信、リンククリックで本登録完了
4. 登録済みメールアドレスの重複登録不可
- **関連要求**: FR-AUTH-002, NFR-SEC-001
#### FR-AUTH-002: ユーザーログイン
- **説明**: システムは、メールアドレスとパスワードによるログイン
機能を提供しなければならない
- **優先度**: Must
- **ソース**: UR-002
- **受入基準**:
1. 正しい認証情報でログイン成功
2. JWT トークンを発行（有効期限 24 時間）
3. 連続 5 回の認証失敗でアカウント 30 分間ロック
4. ログイン成功時にダッシュボードにリダイレクト
- **関連要求**: FR-AUTH-001, NFR-SEC-002, NFR-PERF-001
### 3.2 商品管理機能
[同様の形式で記述...]
### 3.3 注文管理機能
[同様の形式で記述...]
### 3.4 決済機能
[同様の形式で記述...]
---
## 4. 非機能要求
### 4.1 性能要求
#### NFR-PERF-001: 応答時間
- **説明**: システムは、すべての API エンドポイントについて、
95 パーセンタイルの応答時間が 200ms 以内であること
- **計測条件**: 同時接続 1,000 ユーザー時
- **優先度**: Must
#### NFR-PERF-002: スループット
- **説明**: システムは、ピーク時に毎秒 500 リクエストを
処理できること
- **優先度**: Must
### 4.2 セキュリティ要求
[同様の形式で記述...]
### 4.3 可用性要求
[同様の形式で記述...]
---
## 5. 外部インターフェース要求
### 5.1 ユーザーインターフェース
[UI 要求、画面一覧]
### 5.2 ハードウェアインターフェース
[該当する場合]
### 5.3 ソフトウェアインターフェース
[外部システム連携]
### 5.4 通信インターフェース
[プロトコル、API 仕様]
---
## 6. トレーサビリティマトリクス
[要求間の追跡表]
## 付録
[用語集、索引、参考資料]
7.4 要求の記述スタイル比較
要求を記述する方法には複数のスタイルがある。
7.4.1 自然言語（構造化）
FR-001: [優先度: Must]
条件: ユーザーがログインページでメールアドレスとパスワードを入力し、
ログインボタンをクリックした場合
動作: システムは認証サーバーに対して資格情報を検証し、
成功した場合は JWT トークンを発行する
制約: 応答時間は 500ms 以内とする
7.4.2 表形式
| ID | 名前 | 説明 | 優先度 | 受入基準 | ソース |
|---|---|---|---|---|---|
| FR-001 | ログイン | メール+PWでの認証 | Must | JWT発行、5回失敗でロック | UR-002 |
| FR-002 | ログアウト | セッション終了 | Must | トークン無効化 | UR-003 |
7.4.3 フォーマル仕様（Z 記法の例）
── LoginSystem ─────────────────────
users: ℙ USER
sessions: USER ⇸ SESSION
failedAttempts: USER → ℕ
────────────────────────────────────
∀ u: users •
failedAttempts(u) ≤ MAX_ATTEMPTS
dom sessions ⊆ users
────────────────────────────────────
── Login ───────────────────────────
ΔLoginSystem
user?: USER
password?: PASSWORD
result!: RESULT
────────────────────────────────────
user? ∈ users ∧
authenticate(user?, password?) = true ∧
failedAttempts(user?) < MAX_ATTEMPTS ⇒
sessions' = sessions ⊕ {user? ↦ newSession()} ∧
failedAttempts' = failedAttempts ⊕ {user? ↦ 0} ∧
result! = SUCCESS
────────────────────────────────────
7.4.4 Gherkin（BDD: Behavior-Driven Development）
Feature: ユーザーログイン
ユーザーとして、
安全にシステムにログインしたい、
自分のアカウント情報にアクセスするために。
Scenario: 正常なログイン
Given ユーザー "test@example.com" が登録されている
And パスワードが "P@ssw0rd123" である
When ログインページでメールアドレス "test@example.com" を入力する
And パスワード "P@ssw0rd123" を入力する
And ログインボタンをクリックする
Then ダッシュボードページが表示される
And JWT トークンが発行される
And トークンの有効期限が 24 時間後に設定される
Scenario: パスワード間違い
Given ユーザー "test@example.com" が登録されている
When 誤ったパスワード "wrong" でログインを試みる
Then エラーメッセージ "認証に失敗しました" が表示される
And 失敗回数が 1 増加する
Scenario: アカウントロック
Given ユーザー "test@example.com" の失敗回数が 4 である
When 誤ったパスワードでログインを試みる
Then エラーメッセージ "アカウントがロックされました" が表示される
And アカウントが 30 分間ロックされる
Scenario Outline: パスワードバリデーション
When パスワード "<password>" で登録を試みる
Then 結果は "<result>" である
Examples:
| password | result |
| abc | 失敗 |
| abcdefgh | 失敗 |
| Abcdefg1 | 成功 |
| P@ssw0rd123 | 成功 |
8. 要求の検証と妥当性確認（Verification & Validation）
8.1 検証と妥当性確認の違い
検証（Verification） 妥当性確認（Validation）
「正しく作っているか？」 「正しいものを作っているか？」
───────────────────── ─────────────────────
SRS が基準・テンプレートに SRS がステークホルダーの
準拠しているか 真のニーズを反映しているか
───────────────────── ─────────────────────
内部品質（形式、一貫性） 外部品質（有用性、適合性）
───────────────────── ─────────────────────
レビュー、チェックリスト プロトタイプ、ウォークスルー
静的解析 受入テスト定義
8.2 要求レビュー
要求レビューは最も広く実践されている検証手法である。
8.2.1 レビューの種類
| 種類 | 形式 | 参加者 | 目的 |
|---|---|---|---|
| インスペクション | 高度に形式化 | 4-6名、役割明確 | 欠陥の網羅的検出 |
| ウォークスルー | 中程度の形式化 | 3-5名 | 理解促進と欠陥検出 |
| ピアレビュー | 非形式的 | 2名 | 早期の欠陥検出 |
| デスクチェック | 個人 | 1名 | セルフレビュー |
8.2.2 インスペクションプロセス
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│計画 │───→│準備 │───→│会議 │───→│修正 │───→│追跡 │
│ │ │ │ │ │ │ │ │ │
│参加者 │ │個別に │ │欠陥を │ │著者が │ │修正 │
│選定 │ │要求を │ │議論 │ │欠陥を │ │確認 │
│資料 │ │レビュー│ │記録 │ │修正 │ │ │
│配布 │ │ │ │ │ │ │ │ │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘
8.2.3 要求レビューチェックリスト
# 要求レビューチェックリスト
## 1. 正確性（Correctness）
- [ ] 各要求は利害関係者の実際のニーズを反映しているか
- [ ] ドメイン知識と矛盾する記述がないか
- [ ] 計算式・数値に誤りがないか
## 2. 明確性（Unambiguity）
- [ ] 曖昧な表現（「適切な」「十分な」「高速な」等）がないか
- [ ] 一つの要求が複数の解釈を許さないか
- [ ] 専門用語が用語集で定義されているか
## 3. 完全性（Completeness）
- [ ] すべてのユースケースの正常系・代替系・例外系が記述されているか
- [ ] 非機能要求が具体的な数値で定義されているか
- [ ] 外部インターフェースが網羅されているか
- [ ] エラー処理が定義されているか
## 4. 一貫性（Consistency）
- [ ] 要求間に矛盾がないか
- [ ] 同じ概念に対して異なる用語が使われていないか
- [ ] 優先度のランク付けに矛盾がないか
## 5. 検証可能性（Verifiability）
- [ ] 各要求にテスト可能な受入基準があるか
- [ ] 「使いやすい」「高性能」等の主観的表現がないか
- [ ] 数値的な閾値が定義されているか
## 6. 追跡可能性（Traceability）
- [ ] 各要求に一意の ID が付与されているか
- [ ] ビジネス要求からシステム要求への追跡が可能か
- [ ] 要求のソース（出所）が記録されているか
## 7. 実現可能性（Feasibility）
- [ ] 技術的に実現可能な要求か
- [ ] 予算・スケジュールの制約内で実現可能か
- [ ] 必要なリソース（人員・インフラ）が確保可能か
8.3 プロトタイプ検証
# プロトタイプ検証計画
## 検証対象
- 注文フロー（UC-003）の UI/UX
- 検索機能の応答性
## 検証方法
1. Figma プロトタイプによるユーザビリティテスト
2. 参加者: 5名（ターゲットユーザー層）
3. タスク:
- タスク1: 特定の商品を検索して購入する（5分以内）
- タスク2: 注文履歴を確認する（2分以内）
- タスク3: 配送先を変更する（3分以内）
## 評価基準
| メトリクス | 目標値 |
|-----------|--------|
| タスク完了率 | ≥ 90% |
| 平均タスク完了時間 | 目標時間以内 |
| エラー率 | ≤ 10% |
| SUS スコア | ≥ 70 |
| ユーザー満足度 (1-5) | ≥ 4.0 |
## 結果の反映
- クリティカルな問題 → 要求の即時修正
- メジャーな問題 → 次回イテレーションで修正
- マイナーな問題 → バックログに追加
8.4 フォーマル検証
安全性が重要なシステム（航空宇宙、医療機器、金融）では、形式手法を用いた数学的検証が行われる。
モデル検査（Model Checking）の例: NuSMV
MODULE main
VAR
state : {idle, authenticating, authenticated, locked};
attempts : 0..5;
input_correct : boolean;
ASSIGN
init(state) := idle;
init(attempts) := 0;
next(state) :=
case
state = idle : authenticating;
state = authenticating & input_correct : authenticated;
state = authenticating & !input_correct
& attempts < 4 : authenticating;
state = authenticating & !input_correct
& attempts >= 4 : locked;
TRUE : state;
esac;
-- 安全性: ロック状態から認証状態に直接遷移しない
SPEC AG (state = locked -> AX state != authenticated)
-- 活性: いずれ認証状態に到達可能
SPEC EF (state = authenticated)
-- 不変条件: 試行回数は常に 5 以下
SPEC AG (attempts <= 5)
8.5 受入基準テスト（Acceptance Test）
要求の妥当性を確認する最終手段として、受入テストがある。
# 受入テスト仕様: FR-AUTH-002 ユーザーログイン
## テストケース AT-AUTH-001: 正常ログイン
- **前提条件**: テストユーザー（test@example.com / P@ssw0rd123）が存在
- **手順**:
1. ログインページにアクセス
2. メールアドレスを入力
3. パスワードを入力
4. ログインボタンをクリック
- **期待結果**:
- ダッシュボードに遷移する
- HTTP レスポンスに JWT トークンが含まれる
- トークンの有効期限が 24 時間後
- **判定**: PASS / FAIL
## テストケース AT-AUTH-002: アカウントロック
- **前提条件**: テストユーザーの失敗回数が 0
- **手順**:
1. 誤ったパスワードで 5 回連続ログインを試行
2. 正しいパスワードで 6 回目のログインを試行
- **期待結果**:
- 5 回目の失敗後にロックメッセージ表示
- 6 回目は正しいパスワードでもログイン不可
- 30 分後にログイン可能
- **判定**: PASS / FAIL
9. 要求管理（Requirements Management）
9.1 要求管理の目的
要求管理は、ベースライン確定後の要求の変更・追跡・維持を体系的に行う活動である。
9.2 要求ベースラインの確定
要求候補 → レビュー → 承認 → ベースライン確定
│
┌──────┴──────┐
│ ベースライン │
│ v1.0 │
│──────────────│
│ FR-001〜050 │
│ NFR-001〜020 │
│ 承認日: 4/15 │
└──────────────┘
│
変更管理プロセス
│
┌──────┴──────┐
│ ベースライン │
│ v1.1 │
│──────────────│
│ FR-001〜053 │
│ NFR-001〜022 │
│ 承認日: 5/20 │
└──────────────┘
9.3 変更管理プロセス
9.3.1 変更管理フロー
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 変更要求 │───→│ 影響分析 │───→│ CCB 審議 │
│ 提出 │ │ │ │ │
└──────────┘ └──────────┘ └────┬─────┘
│
┌─────────────┼─────────────┐
↓ ↓ ↓
┌────────┐ ┌────────┐ ┌────────┐
│ 承認 │ │ 却下 │ │ 保留 │
└───┬────┘ └────────┘ └────────┘
│
↓
┌──────────┐ ┌──────────┐
│ 要求更新 │───→│ 検証 │
│ 実装 │ │ ベースライン│
│ │ │ 更新 │
└──────────┘ └──────────┘
CCB（Change Control Board）: 変更管理委員会。変更要求の承認権限を持つ。
9.3.2 変更要求テンプレート
# 変更要求書（Change Request）
## 基本情報
| 項目 | 内容 |
|------|------|
| CR-ID | CR-2025-042 |
| 提出日 | 2025-05-10 |
| 提出者 | 田中太郎（営業部） |
| 対象要求 | FR-AUTH-002（ユーザーログイン） |
| 優先度 | 高 |
## 変更内容
### 現在の要求
連続 5 回の認証失敗でアカウントを 30 分間ロックする
### 変更後の要求
連続 5 回の認証失敗でアカウントをロックし、
管理者が解除するまでロック状態を維持する。
ただし、ユーザーはメールによるパスワードリセットでロック解除可能。
### 変更理由
セキュリティ監査で 30 分のロック時間が不十分と指摘された。
ブルートフォース攻撃対策として恒久的ロックが必要。
## 影響分析
### 影響を受ける要求
- FR-AUTH-002: ログイン機能の変更
- FR-AUTH-005: パスワードリセット機能の追加が必要
- NFR-SEC-001: セキュリティポリシーの更新
### 影響を受けるコンポーネント
- 認証サービス
- メール通知サービス
- 管理者画面
### 工数見積もり
- 設計: 2 人日
- 実装: 5 人日
- テスト: 3 人日
- 合計: 10 人日
### リスク
- パスワードリセットメールの配信遅延リスク
- 管理者の負荷増加
## CCB 審議結果
| 審議日 | 決定 | 理由 |
|--------|------|------|
| 2025-05-15 | 承認 | セキュリティ監査対応のため |
9.4 要求トレーサビリティ
9.4.1 トレーサビリティの種類
ビジネス要求 → ユーザー要求 → システム要求 → テスト
(BR) (UR) (FR/NFR) (TC)
│ │ │ │
│ 前方追跡 │ 前方追跡 │ 前方追跡 │
│─────────────→│────────────────→│───────────────→│
│ │ │ │
│ 後方追跡 │ 後方追跡 │ 後方追跡 │
│←─────────────│←────────────────│←───────────────│
9.4.2 トレーサビリティマトリクス
# 要求トレーサビリティマトリクス（RTM）
| BR | UR | FR/NFR | 設計 | 実装 | テスト | ステータス |
|----|-----|--------|------|------|--------|----------|
| BR-001 | UR-001 | FR-SRCH-001 | DD-010 | auth-svc | TC-001 | Implemented |
| BR-001 | UR-001 | FR-SRCH-002 | DD-011 | auth-svc | TC-002 | Implemented |
| BR-001 | UR-002 | FR-AUTH-001 | DD-020 | search-svc | TC-010 | In Progress |
| BR-001 | UR-002 | FR-AUTH-002 | DD-021 | search-svc | TC-011 | In Progress |
| BR-002 | UR-003 | FR-PAY-001 | DD-030 | payment-svc | TC-020 | Planned |
| BR-002 | UR-003 | NFR-SEC-001 | DD-031 | payment-svc | TC-021 | Planned |
| BR-003 | UR-004 | FR-ORD-001 | DD-040 | order-svc | TC-030 | Draft |
9.4.3 トレーサビリティの自動化設定例（JIRA + Confluence）
# JIRA カスタムフィールド設定
custom_fields:
- name: "Business Requirement"
type: "issue_link"
link_type: "is derived from"
- name: "Test Cases"
type: "issue_link"
link_type: "is verified by"
- name: "Design Document"
type: "url"
description: "Confluence ページへのリンク"
# JIRA フィルター（追跡漏れ検出）
jql_queries:
orphan_requirements: >
project = "EC" AND
issuetype = "Requirement" AND
issueFunction NOT IN linkedIssuesOf(
"issuetype = 'Test Case'", "is verified by"
)
untested_requirements: >
project = "EC" AND
issuetype = "Requirement" AND
status = "Approved" AND
issueFunction NOT IN linkedIssuesOf(
"issuetype = 'Test Case' AND status = 'Passed'"
)
9.5 要求のバージョン管理
要求文書のバージョン管理には、Git ベースのアプローチが効果的である。
# 要求リポジトリの構造
requirements-repo/
├── README.md
├── srs/
│ ├── SRS-v1.0.md
│ ├── functional/
│ │ ├── FR-AUTH.md
│ │ ├── FR-SEARCH.md
│ │ ├── FR-ORDER.md
│ │ └── FR-PAYMENT.md
│ └── non-functional/
│ ├── NFR-PERFORMANCE.md
│ ├── NFR-SECURITY.md
│ └── NFR-AVAILABILITY.md
├── models/
│ ├── use-cases/
│ ├── domain-model/
│ └── state-diagrams/
├── traceability/
│ └── RTM.csv
├── change-requests/
│ ├── CR-2025-001.md
│ └── CR-2025-002.md
└── reviews/
├── review-2025-04-15.md
└── review-2025-05-01.md
# Git ワークフロー
# 要求変更ブランチの作成
git checkout -b cr/CR-2025-042-auth-lockout
# 変更の実施
vim srs/functional/FR-AUTH.md
# コミット（変更要求 ID を含む）
git commit -m "CR-2025-042: 認証失敗時の恒久ロック機能を追加
- FR-AUTH-002 のロック仕様を変更
- FR-AUTH-005 パスワードリセットによるロック解除を追加
- NFR-SEC-001 セキュリティポリシーの更新
Approved by: CCB-2025-05-15"
# プルリクエストでレビュー
git push origin cr/CR-2025-042-auth-lockout
# → プルリクエスト作成 → レビュー → マージ
9.6 要求の状態管理
┌──────┐ ┌──────────┐ ┌──────────┐
│Draft │───→│ Proposed │───→│ Approved │
└──────┘ └──────────┘ └────┬─────┘
↑ │
│ ┌────┴─────┐
┌────┴────┐ │ │
│Rejected │ ↓ ↓
└─────────┘ ┌──────┐ ┌──────────┐
│Active│ │Deferred │
└──┬───┘ └──────────┘
│
┌────┴─────┐
↓ ↓
┌────────┐ ┌────────┐
│Implemen│ │Deleted │
│ted │ └────────┘
└───┬────┘
↓
┌────────┐
│Verified│
└────────┘
10. 非機能要求の体系化
10.1 ISO/IEC 25010 品質モデル
非機能要求は、ISO/IEC 25010:2011（2023年に改訂版発行）に基づくソフトウェアプロダクト品質モデルを用いて体系的に分類できる。
┌──────────────────────┐
│ プロダクト品質モデル │
│ (ISO/IEC 25010) │
└──────────┬───────────┘
│
┌──────┬──────┬──────┬─────┼──────┬──────┬──────┐
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
┌─────┐┌─────┐┌─────┐┌─────┐┌─────┐┌─────┐┌─────┐┌─────┐
│機能 ││性能 ││互換 ││使用 ││信頼 ││セキュ││保守 ││移植 │
│適合 ││効率 ││性 ││性 ││性 ││リティ││性 ││性 │
│性 ││性 ││ ││ ││ ││ ││ ││ │
└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘
│ │ │ │ │ │ │ │
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
完全性 時間 共存性 理解性 成熟性 機密性 モジュ 適応性
正確性 効率性 相互運用 学習性 可用性 完全性 ール性 設置性
適切性 資源 性 操作性 障害許 否認防 再利用 置換性
利用性 アクセ 容性 止 性
シビリ 回復性 責任 分析性
ティ 追跡 変更性
真正性 試験性
10.2 各品質特性の要求定義例
10.2.1 性能効率性（Performance Efficiency）
## 性能要求
### NFR-PERF-001: 応答時間
- Web ページの初回読み込み: 2 秒以内（LCP: Largest Contentful Paint）
- API 応答時間（P95）: 200ms 以内
- API 応答時間（P99）: 500ms 以内
- 検索クエリ応答: 100ms 以内（10万件のデータセット）
- 計測条件: 同時接続 1,000 ユーザー
### NFR-PERF-002: スループット
- 通常時: 500 リクエスト/秒
- ピーク時（セール期間）: 5,000 リクエスト/秒
- バッチ処理: 100 万レコード/時間
### NFR-PERF-003: リソース使用率
- CPU 使用率: 通常時 40% 以下、ピーク時 80% 以下
- メモリ使用率: 70% 以下
- ディスク I/O: 書き込みレイテンシ 5ms 以下
10.2.2 信頼性（Reliability）
## 信頼性要求
### NFR-REL-001: 可用性
- サービス稼働率: 99.95%（年間停止時間 4.38 時間以内）
- 計画停止: 月1回、日曜 02:00-06:00（事前通知 72 時間前）
- 計画外停止: 月間 30 分以内
### NFR-REL-002: 障害許容性
- 単一ノード障害時のサービス継続（N+1 冗長構成）
- データベースのマルチ AZ 構成
- メッセージキューの永続化（ゼロメッセージロス）
### NFR-REL-003: 回復性
- RTO（Recovery Time Objective）: 1 時間以内
- RPO（Recovery Point Objective）: 5 分以内
- 自動フェイルオーバー: 30 秒以内
- データバックアップ: 日次フルバックアップ + 5分間隔の WAL アーカイブ
### SLA 定義例
| メトリクス | Bronze | Silver | Gold |
|-----------|--------|--------|------|
| 可用性 | 99.5% | 99.9% | 99.95% |
| 応答時間（P95） | 500ms | 300ms | 200ms |
| RTO | 4 時間 | 1 時間 | 15 分 |
| RPO | 1 時間 | 15 分 | 5 分 |
| サポート対応 | 営業時間 | 12x5 | 24x7 |
10.2.3 セキュリティ（Security）
## セキュリティ要求
### NFR-SEC-001: 認証・認可
- 多要素認証（MFA）対応（TOTP, WebAuthn）
- OAuth 2.0 / OpenID Connect 準拠
- RBAC（Role-Based Access Control）の実装
- セッション管理:
- アクセストークン有効期限: 1 時間
- リフレッシュトークン有効期限: 7 日
- 同時セッション数: 最大 5
### NFR-SEC-002: データ保護
- 通信の暗号化: TLS 1.3 以上
- データベースの暗号化: AES-256（保存時暗号化）
- PII（個人識別情報）のマスキング（ログ出力時）
- パスワードハッシュ: bcrypt（コスト 12 以上）
### NFR-SEC-003: 脆弱性対策
- OWASP Top 10 (2021) のすべての項目に対策
- 依存ライブラリの脆弱性スキャン（週次）
- ペネトレーションテスト（年 2 回）
- セキュリティヘッダー設定:
- Content-Security-Policy
- X-Content-Type-Options: nosniff
- Strict-Transport-Security
- X-Frame-Options: DENY
### NFR-SEC-004: 監査ログ
- すべての認証イベントの記録
- データ変更操作の監査証跡
- ログの改竄防止（追記のみ、WORM ストレージ）
- ログ保持期間: 最低 3 年
10.2.4 保守性（Maintainability）
## 保守性要求
### NFR-MAINT-001: コード品質
- テストカバレッジ: 80% 以上（ライン、ブランチ）
- 循環的複雑度（Cyclomatic Complexity）: メソッドあたり 15 以下
- 重複コード率: 3% 以下（Sonarqube DRY ルール）
- 技術的負債比率: 5% 以下（Sonarqube SQALE）
### NFR-MAINT-002: ドキュメント
- API ドキュメント: OpenAPI 3.0 仕様で自動生成
- アーキテクチャ決定記録（ADR）の維持
- 運用手順書（Runbook）の維持
### NFR-MAINT-003: デプロイ
- デプロイ頻度: 週 5 回以上（ビジネス日毎）
- デプロイ所要時間: 15 分以内
- ロールバック所要時間: 5 分以内
- ブルー/グリーンデプロイメント対応
10.3 FURPS+ モデル
ISO 25010 の代替として、FURPS+ モデルも広く使われる。
FURPS+:
F - Functionality（機能性） : 機能、セキュリティ
U - Usability（使用性） : UX、ヘルプ、ドキュメント
R - Reliability（信頼性） : 頻度、回復性、予測可能性
P - Performance（性能） : スループット、応答時間、リソース
S - Supportability（サポート性）: 保守性、テスト容易性、拡張性
+ - 制約条件 : 設計、実装、インターフェース、物理
11. ユースケースとユーザーストーリー
11.1 ユースケースの詳細
ユースケースは Ivar Jacobson が 1992 年に提唱した要求記述手法であり、UML の中核的な構成要素である。
11.1.1 ユースケースの粒度
┌─────────────────────────────────────────────┐
│ サマリーレベル（Cloud Level） │
│ 例: 商品を販売する │
│ → 複数のユーザーゴールを包含 │
├─────────────────────────────────────────────┤
│ ユーザーゴールレベル（Sea Level）★最も重要 │
│ 例: 注文を確定する │
│ → 1つのセッションで完了するユーザーの目標 │
├─────────────────────────────────────────────┤
│ サブ機能レベル（Fish Level） │
│ 例: 住所をバリデーションする │
│ → ユーザーゴールの一部として実行される │
└─────────────────────────────────────────────┘
11.1.2 ユースケースの関係
<<include>> : 必ず含まれるサブ機能
例: 「注文確定」は必ず「決済処理」を include する
<<extend>> : 条件付きで追加される機能
例: 「注文確定」は条件次第で「クーポン適用」を extend する
汎化（Generalization）: 親ユースケースの特殊化
例: 「オンライン決済」は「決済する」の汎化
11.2 ユーザーストーリー
11.2.1 ストーリーの構造
As a [ロール],
I want [機能/行動],
So that [ビジネス価値/理由].
日本語テンプレート
[ロール] として、
[機能/行動] したい。
なぜなら [ビジネス価値/理由] だから。
11.2.2 具体例（EC サイト）
# エピック: 商品購入体験
## ストーリー US-001: 商品検索
顧客として、
キーワードで商品を検索したい。
なぜなら、膨大な商品カタログから目的の商品を素早く見つけたいから。
### 受入基準（Acceptance Criteria）
- [ ] 商品名、説明文、カテゴリ名でキーワード検索ができる
- [ ] 検索結果は関連度順にソートされる
- [ ] 検索結果が 0 件の場合、「結果が見つかりません」と表示する
- [ ] 検索は 500ms 以内に結果を返す
- [ ] 検索結果をカテゴリでフィルタリングできる
### ストーリーポイント: 5
### 優先度: Must
---
## ストーリー US-002: カートへの追加
顧客として、
気に入った商品をショッピングカートに追加したい。
なぜなら、複数の商品をまとめて購入したいから。
### 受入基準
- [ ] 商品詳細ページから「カートに追加」ボタンで追加できる
- [ ] 数量を指定してカートに追加できる（デフォルト: 1）
- [ ] 在庫数以上の数量は追加できない
- [ ] カートアイコンに現在のアイテム数が表示される
- [ ] 同じ商品を再度追加すると数量が加算される
- [ ] ゲストユーザーでもカート機能を利用できる
### ストーリーポイント: 3
### 優先度: Must
---
## ストーリー US-003: ワンクリック決済
リピート顧客として、
保存済みの決済情報でワンクリック決済したい。
なぜなら、毎回カード情報を入力する手間を省きたいから。
### 受入基準
- [ ] 過去の決済で使用したカード情報を保存できる
- [ ] 保存済みカードの一覧から選択してワンクリックで決済できる
- [ ] カード番号は下4桁のみ表示（マスキング）
- [ ] 決済前に確認ダイアログが表示される
- [ ] PCI DSS v4.0 準拠のトークン化で保存
### ストーリーポイント: 8
### 優先度: Should
11.2.3 INVEST 基準
良いユーザーストーリーは INVEST 基準を満たす。
| 基準 | 意味 | チェック |
|---|---|---|
| Independent | 他のストーリーと独立 | 単独で実装・テスト可能か |
| Negotiable | 交渉可能 | 詳細は実装時に議論余地があるか |
| Valuable | 価値がある | ユーザーに価値を提供するか |
| Estimable | 見積もり可能 | チームが工数を見積もれるか |
| Small | 小さい | 1 スプリント内で完了可能か |
| Testable | テスト可能 | 受入基準が明確か |
11.3 ユーザーストーリーマッピング
Jeff Patton が提唱したユーザーストーリーマッピングは、ストーリーを視覚的に整理する手法である。
ナラティブフロー（左→右）
─────────────────────────────────────────→
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 商品を │ │ カートに │ │ 注文を │ │ 注文を │ ← アクティビティ
│ 探す │ │ 追加する │ │ 確定する │ │ 追跡する │ (Backbone)
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │ │
─────┼────────────┼────────────┼────────────┼───── Release 1
│ │ │ │ (Walking
┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ Skeleton)
│ キーワード│ │ カートに │ │ 配送先 │ │ 注文状態 │
│ 検索 │ │ 追加 │ │ 入力 │ │ 確認 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │
─────┼────────────┼────────────┼────────────┼───── Release 2
│ │ │ │
┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐
│ カテゴリ │ │ 数量変更 │ │ クレジット│ │ 配送 │
│ フィルタ │ │ │ │ カード決済│ │ 追跡 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │
─────┼────────────┼────────────┼────────────┼───── Release 3
│ │ │ │
┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐
│ AI レコメ │ │ お気に入り│ │ コンビニ │ │ 返品 │
│ ンド │ │ リスト │ │ 決済 │ │ 申請 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
11.4 ユースケースとユーザーストーリーの比較
| 観点 | ユースケース | ユーザーストーリー |
|---|---|---|
| 詳細度 | 詳細（シナリオベース） | 簡潔（会話のプレースホルダー） |
| 形式 | 構造化テンプレート | 自由度が高い |
| 適用場面 | 契約ベース、大規模開発 | アジャイル、反復開発 |
| メリット | 網羅性が高い | 軽量、変更容易 |
| デメリット | 作成コストが高い | 暗黙知に依存しやすい |
| 非機能要求 | 含めることが可能 | 別途管理が一般的 |
12. アジャイルにおける要求工学
12.1 伝統的 RE とアジャイル RE の比較
| 観点 | 伝統的 RE | アジャイル RE |
|---|---|---|
| タイミング | 開発前に網羅的に定義 | 反復的に段階詳細化 |
| 成果物 | 詳細な SRS 文書 | プロダクトバックログ |
| 変更 | 変更管理プロセスで制御 | 常時歓迎 |
| ステークホルダー関与 | 定義時とレビュー時 | 継続的（毎スプリント） |
| ドキュメント | 包括的な文書化 | 必要最小限 |
| 検証 | フォーマルレビュー | スプリントレビュー |
12.2 スクラムにおける要求工学
プロダクトビジョン
│
↓
┌──────────────────────────────────────┐
│ プロダクトバックログ │
│ ┌─────────────────────────────────┐ │
│ │ エピック → ストーリー → タスク │ │
│ │ │ │
│ │ 優先度順に並べ替え │ │
│ │ 上位は詳細、下位は粗い │ │
│ └─────────────────────────────────┘ │
└────────────┬─────────────────────────┘
│
│ スプリントプランニング
↓
┌──────────────────────────┐
│ スプリントバックログ │ Sprint (2週間)
│ ┌────────────────────┐ │ ┌──────────────┐
│ │ 選択されたストーリー │ │───→│ デイリースクラム│
│ │ + タスク分解 │ │ │ 実装 │
│ └────────────────────┘ │ │ テスト │
└──────────────────────────┘ └──────┬───────┘
│
↓
┌──────────────┐
│ スプリント │
│ レビュー │
│（要求の検証） │
└──────┬───────┘
│
↓
┌──────────────┐
│ レトロスペク │
│ ティブ │
│（プロセス改善） │
└──────────────┘
12.3 バックログリファインメント
バックログリファインメントは、アジャイルにおける要求工学の中核活動である。
# バックログリファインメント会議
## 頻度: 週1回（木曜日 15:00-16:00）
## アジェンダ
1. 新しいストーリーの確認と議論（20分）
2. 既存ストーリーの詳細化（20分）
3. 受入基準の明確化（10分）
4. 見積もり（プランニングポーカー）（10分）
## リファインメントの基準
### Ready の定義（Definition of Ready）
- [ ] ユーザーストーリーが INVEST 基準を満たしている
- [ ] 受入基準が明確に定義されている
- [ ] ストーリーポイントが見積もられている
- [ ] UI モックアップが準備されている（該当する場合）
- [ ] 依存関係が特定されている
- [ ] チームが実装方法を理解している
### 詳細化レベルの目安
| バックログ位置 | 詳細度 | 例 |
|--------------|--------|-----|
| 次スプリント | 詳細 | 受入基準、UI モック、API 仕様 |
| 2-3 スプリント先 | 中程度 | ストーリー文、主要な受入基準 |
| それ以降 | 粗い | エピック/テーマレベル |
12.4 SAFe における要求の階層
大規模アジャイル開発フレームワーク SAFe（Scaled Agile Framework）では、要求が複数の階層で管理される。
┌─────────────────────────────────────────────┐
│ Portfolio Level │
│ ┌──────────┐ ┌──────────┐ │
│ │ Strategic │ │ Portfolio │ │
│ │ Themes │ │ Epics │ │
│ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ Program Level (ART) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Program │ │ Features │ │ Enablers │ │
│ │ Epics │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ Team Level │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ User │ │ Tasks │ │ Acceptance│ │
│ │ Stories │ │ │ │ Criteria │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────┘
12.5 プロダクトバックログの管理設定例
JIRA での設定
# JIRA プロジェクト設定
## イシュータイプ階層
issue_types:
- name: "Epic"
description: "大規模な機能群"
color: "#904ee2"
- name: "Story"
description: "ユーザーストーリー"
color: "#63ba3c"
custom_fields:
- "Story Points"
- "Acceptance Criteria"
- "Definition of Ready Checklist"
- name: "Bug"
description: "不具合"
color: "#e5493a"
- name: "Spike"
description: "技術調査"
color: "#2684ff"
custom_fields:
- "Time-box (hours)"
## ボード設定
board:
name: "EC Platform"
type: "scrum"
sprint_duration: "2 weeks"
columns:
- "To Do"
- "In Progress"
- "In Review"
- "Done"
## バックログフィルター
quick_filters:
- name: "Must Have"
jql: "priority = Highest"
- name: "Current Sprint"
jql: "sprint in openSprints()"
- name: "Unestimated"
jql: '"Story Points" is EMPTY'
12.6 継続的要求工学
DevOps の普及により、要求工学も継続的に実施される。
┌─────────────────────────────────────────────────┐
│ 継続的要求工学サイクル │
│ │
│ 発見 ─→ 定義 ─→ 実装 ─→ デプロイ ─→ 計測 ──┐ │
│ ↑ │ │
│ └──── フィードバック ←── 分析 ←─────────────┘ │
└─────────────────────────────────────────────────┘
データソース:
- アプリストアレビュー
- カスタマーサポートチケット
- ユーザー行動データ（Analytics）
- A/B テスト結果
- NPS（Net Promoter Score）
- 競合製品分析
13. 要求工学のツールとフレームワーク
13.1 ツール分類
┌─────────────────────────────────────────────┐
│ 要求工学ツールの分類 │
├──────────────┬──────────────────────────────┤
│ 専用RM ツール │ IBM DOORS, Jama Connect, │
│ │ Helix RM, Visure, ReqIF │
├──────────────┼──────────────────────────────┤
│ ALM ツール │ JIRA, Azure DevOps, │
│ │ GitLab, Linear │
├──────────────┼──────────────────────────────┤
│ モデリング │ Enterprise Architect, │
│ │ PlantUML, draw.io, Mermaid │
├──────────────┼──────────────────────────────┤
│ 文書管理 │ Confluence, Notion, │
│ │ Google Docs, SharePoint │
├──────────────┼──────────────────────────────┤
│ NLP/AI │ QualityCheck (Fraunhofer), │
│ │ Requirements AI, ChatGPT/LLM │
└──────────────┴──────────────────────────────┘
13.2 主要ツール比較
| ツール | 適用規模 | トレーサビリティ | モデリング | アジャイル対応 | コスト |
|---|---|---|---|---|---|
| IBM DOORS | 大〜超大 | ★★★★★ | ★★★☆☆ | ★★☆☆☆ | 高 |
| Jama Connect | 中〜大 | ★★★★★ | ★★★☆☆ | ★★★★☆ | 高 |
| JIRA + Confluence | 小〜大 | ★★★☆☆ | ★★☆☆☆ | ★★★★★ | 中 |
| Azure DevOps | 小〜大 | ★★★★☆ | ★★☆☆☆ | ★★★★★ | 中 |
| Linear | 小〜中 | ★★☆☆☆ | ★☆☆☆☆ | ★★★★★ | 低 |
| Notion | 小〜中 | ★★☆☆☆ | ★☆☆☆☆ | ★★★☆☆ | 低 |
13.3 IBM DOORS 設定例
DOORS（Dynamic Object-Oriented Requirements System）は、航空宇宙・防衛・自動車産業で標準的に使用される要求管理ツールである。
// DOORS DXL スクリプト: トレーサビリティレポート生成
Module m = current
Object o
string report = ""
for o in m do {
string id = o."Absolute Number" ""
string title = o."Object Heading" ""
string priority = o."Priority" ""
string status = o."Status" ""
// 下位要求へのリンクを確認
Link outLink
int linkCount = 0
for outLink in o -> "*" do {
linkCount++
}
// 上位要求からのリンクを確認
Link inLink
int inLinkCount = 0
for inLink in o <- "*" do {
inLinkCount++
}
// 孤立要求の検出
if (inLinkCount == 0 && outLinkCount == 0) {
report = report id "\t" title "\t ORPHAN\n"
}
}
print report
13.4 PlantUML によるモデリング例
@startuml
' ユースケース図
left to right direction
actor "顧客" as customer
actor "管理者" as admin
actor "決済GW" as payment
rectangle "EC システム" {
usecase "商品を検索する" as UC1
usecase "カートに追加する" as UC2
usecase "注文を確定する" as UC3
usecase "決済を処理する" as UC4
usecase "在庫を管理する" as UC5
usecase "レポートを閲覧する" as UC6
customer --> UC1
customer --> UC2
customer --> UC3
UC3 ..> UC4 : <<include>>
UC4 --> payment
admin --> UC5
admin --> UC6
}
@enduml
@startuml
' 要求図（SysML Requirements Diagram）
package "認証要求" {
rectangle "<<requirement>>\nFR-AUTH-001\nユーザー登録" as R1 {
Text: "メールとパスワードで\n新規登録が可能なこと"
Priority: Must
}
rectangle "<<requirement>>\nFR-AUTH-002\nユーザーログイン" as R2 {
Text: "メールとPWで\nログイン可能なこと"
Priority: Must
}
rectangle "<<requirement>>\nNFR-SEC-001\nパスワード強度" as R3 {
Text: "8文字以上、大小英数\n含むこと"
Priority: Must
}
R1 ..> R3 : <<deriveReqt>>
R2 ..> R3 : <<deriveReqt>>
}
@enduml
13.5 OpenReq フレームワーク
OpenReq は EU Horizon 2020 プログラムの資金提供を受けて開発されたオープンソースの要求工学プラットフォームである。
# OpenReq コンポーネント構成
components:
- name: "Requirements Intelligence"
description: "NLP ベースの要求分析"
capabilities:
- 要求の自動分類（機能/非機能）
- 曖昧性検出
- 依存関係の推定
- name: "Stakeholder Management"
description: "ステークホルダー分析支援"
capabilities:
- ステークホルダーマッピング
- 利害関係の可視化
- name: "Decision Support"
description: "優先順位付け支援"
capabilities:
- マルチクライテリア分析
- トレードオフ分析
- name: "Quality Assessment"
description: "要求品質の自動評価"
capabilities:
- 完全性チェック
- 一貫性チェック
- テスト容易性チェック
13.6 AI/LLM を活用した要求工学
大規模言語モデル（LLM）の登場により、要求工学の自動化が急速に進んでいる。
13.6.1 LLM の活用場面
## LLM × 要求工学の活用マトリクス
| 活動 | 活用方法 | 精度 | 人間の関与 |
|------|---------|------|-----------|
| 抽出 | インタビュー議事録の自動要約・要求抽出 | 中〜高 | レビュー必須 |
| 分析 | 要求間の矛盾・重複検出 | 中 | 判断は人間 |
| 仕様化 | 自然言語からGherkin/ユースケースへの変換 | 高 | 微調整必要 |
| 検証 | 品質チェック（曖昧性、完全性） | 中〜高 | 最終判断は人間 |
| 管理 | 変更影響分析の支援 | 中 | 検証必須 |
13.6.2 プロンプトエンジニアリングの例
## 要求品質チェックプロンプト
あなたは要求工学の専門家です。以下の要求仕様を IEEE 29148:2018 の
品質基準（正確性、明確性、完全性、一貫性、検証可能性）に基づいて
レビューしてください。
### 入力
[要求仕様テキスト]
### 出力フォーマット
各要求について以下を評価してください:
1. **品質スコア** (1-5): 全体的な品質
2. **問題点**: 検出された問題のリスト
3. **改善提案**: 具体的な修正案
4. **カテゴリ**: 問題のカテゴリ
(曖昧性 / 不完全 / 矛盾 / 検証不能 / 追跡不能)
14. 要求品質メトリクス
14.1 メトリクスの目的
要求品質メトリクスは、要求の成熟度を定量的に測定し、改善を促進する指標である。
14.2 プロセスメトリクス
| メトリクス | 定義 | 目標値 |
|---|---|---|
| 要求安定度 | 変更された要求数 / 総要求数 × 100 | < 15% / スプリント |
| 要求カバレッジ | テスト済み要求数 / 総要求数 × 100 | ≥ 95% |
| 要求欠陥率 | レビューで発見された欠陥数 / 総要求数 | < 0.5 |
| トレーサビリティカバレッジ | 追跡可能な要求数 / 総要求数 × 100 | 100% |
| 孤立要求率 | 上位・下位リンクのない要求数 / 総要求数 × 100 | 0% |
| 要求承認サイクルタイム | 要求起草から承認までの平均日数 | < 10 営業日 |
14.3 プロダクトメトリクス
## 要求仕様書のプロダクトメトリクス
### 完全性メトリクス
- TBD（To Be Determined）数: 0 を目標
- 未定義例外処理数: 0 を目標
- 未定義インターフェース数: 0 を目標
### 曖昧性メトリクス
- 曖昧語彙数: 0 を目標
(「適切な」「十分な」「速い」「使いやすい」等)
- 測定不能な品質要求数: 0 を目標
- 受入基準のないストーリー数: 0 を目標
### 一貫性メトリクス
- 矛盾する要求ペア数: 0
- 同義語の使用数: 0 を目標（用語統一）
- バージョン不整合数: 0
14.4 品質ダッシュボード設定例
# Grafana ダッシュボード設定（例）
dashboard:
title: "要求品質ダッシュボード"
panels:
- title: "要求安定度（スプリント別推移）"
type: "graph"
query: |
SELECT sprint,
COUNT(CASE WHEN status = 'Changed' THEN 1 END) * 100.0
/ COUNT(*) as stability_index
FROM requirements
GROUP BY sprint
thresholds:
- value: 15
color: "yellow"
- value: 30
color: "red"
- title: "トレーサビリティカバレッジ"
type: "gauge"
query: |
SELECT COUNT(CASE WHEN has_trace = true THEN 1 END) * 100.0
/ COUNT(*) as coverage
FROM requirements
WHERE status = 'Approved'
thresholds:
- value: 90
color: "yellow"
- value: 95
color: "green"
- title: "要求ステータス分布"
type: "pie"
query: |
SELECT status, COUNT(*) as count
FROM requirements
GROUP BY status
- title: "優先度別進捗"
type: "stacked_bar"
query: |
SELECT priority, status, COUNT(*) as count
FROM requirements
GROUP BY priority, status
14.5 GQM（Goal-Question-Metric）アプローチ
GQM は、メトリクス定義を体系化するフレームワークである。
ゴール（Goal）:
要求品質を改善し、開発後工程での手戻りを 50% 削減する
質問（Question）:
Q1: 要求は十分に詳細に定義されているか？
Q2: 要求間の矛盾はどの程度あるか？
Q3: 要求のテスト容易性は十分か？
Q4: ステークホルダーの満足度はどうか？
メトリクス（Metric）:
Q1 → M1: TBD 数（目標: 0）
M2: 受入基準定義率（目標: 100%）
Q2 → M3: 矛盾検出数（目標: レビューごとに減少）
M4: 用語不整合数（目標: 0）
Q3 → M5: 検証不能な要求の割合（目標: 0%）
M6: テストケース対応率（目標: ≥ 95%）
Q4 → M7: ステークホルダー NPS（目標: ≥ 40）
M8: 変更要求の平均処理時間（目標: < 5 営業日）
15. 実践的テンプレートと設定例
15.1 要求管理ツール選定ガイド
## ツール選定チェックリスト
### プロジェクト特性
- [ ] チーム規模: ___名
- [ ] 開発手法: ウォーターフォール / アジャイル / ハイブリッド
- [ ] 規制要件: あり / なし
- [ ] 分散チーム: あり / なし
- [ ] 既存ツール連携: JIRA / Azure DevOps / GitLab / その他
### 必要機能（優先度付け）
| 機能 | Must | Should | Could |
|------|------|--------|-------|
| 要求の CRUD | ✓ | | |
| トレーサビリティ | | ✓ | |
| バージョン管理 | ✓ | | |
| レビューワークフロー | | ✓ | |
| レポート生成 | | | ✓ |
| API 連携 | | ✓ | |
| インポート/エクスポート | ✓ | | |
| RBAC | ✓ | | |
15.2 要求仕様 Markdown テンプレート
Git リポジトリで管理する軽量 SRS テンプレートの例。
# 要求仕様: [機能名]
## メタデータ
---
id: FR-XXX
title: [機能名]
priority: Must | Should | Could
status: Draft | Review | Approved | Implemented | Verified
author: [作成者]
created: YYYY-MM-DD
updated: YYYY-MM-DD
source: [UR-XXX or ステークホルダー名]
---
## 概要
[1-2文での機能概要]
## ユーザーストーリー
[ロール] として、
[機能/行動] したい。
なぜなら [ビジネス価値] だから。
## 詳細要求
### 基本フロー
1. [ステップ 1]
2. [ステップ 2]
3. [ステップ 3]
### 代替フロー
- [条件]: [代替動作]
### 例外フロー
- [エラー条件]: [エラー処理]
## 受入基準
- [ ] [基準 1]
- [ ] [基準 2]
- [ ] [基準 3]
## 非機能要求
- **性能**: [数値指標]
- **セキュリティ**: [要件]
## 関連要求
- 上位: [BR-XXX, UR-XXX]
- 関連: [FR-YYY]
- 下位: [テストケース ID]
## UI モックアップ
[画面イメージまたはリンク]
## 変更履歴
| 日付 | 変更者 | 内容 |
|------|--------|------|
| YYYY-MM-DD | [名前] | 初稿作成 |
15.3 Definition of Done / Ready テンプレート
# Definition of Ready（着手可能の定義）
## ストーリーレベル
- [ ] ユーザーストーリーが INVEST 基準を満たしている
- [ ] 受入基準が最低 3 つ定義されている
- [ ] ストーリーポイントが見積もられている
- [ ] 依存関係が特定され、ブロッカーがない
- [ ] チームメンバーの 80% 以上が内容を理解している
- [ ] 必要な UI モックアップが準備されている
- [ ] API インターフェース仕様が合意されている（該当する場合）
# Definition of Done（完了の定義）
## ストーリーレベル
- [ ] すべての受入基準をパスしている
- [ ] コードレビューが完了している
- [ ] ユニットテストカバレッジ ≥ 80%
- [ ] 結合テストが実施されている
- [ ] UI テスト（該当する場合）が実施されている
- [ ] セキュリティスキャンが通過している
- [ ] API ドキュメントが更新されている
- [ ] ステージング環境にデプロイされている
- [ ] PO による受入確認が完了している
16. アンチパターンと対策
16.1 要求工学の代表的アンチパターン
16.1.1 「Yes Man」パターン
問題: すべてのステークホルダーの要求を無批判に受け入れる
結果: スコープクリープ、実現不可能な要求セット
┌─────────────────────────────────────────┐
│ ステークホルダー A: 「AI チャットボット欲しい」│
│ ステークホルダー B: 「AR 試着機能欲しい」 │
│ ステークホルダー C: 「ブロックチェーン決済」 │
│ │
│ BA: 「全部やりましょう！」 ← NG │
└─────────────────────────────────────────┘
対策:
✓ MoSCoW 優先順位付けを徹底する
✓ ビジネスケース（ROI）で評価する
✓ プロダクトビジョンとの整合性を確認する
✓ 「Won't have」カテゴリを明確にする
16.1.2 「Moving Target」パターン
問題: 要求が頻繁に変更され、ベースラインが安定しない
結果: 開発の混乱、品質低下、納期遅延
Sprint 1: 要求 A → Sprint 2: 要求 A' → Sprint 3: 要求 A'' → ...
対策:
✓ 変更管理プロセス（CCB）の導入
✓ 変更コストの可視化
✓ スプリント内の変更凍結（Sprint Goal の保護）
✓ 要求の安定度メトリクスの監視
16.1.3 「Gold Plating」パターン
問題: 要求にない機能を勝手に追加する
結果: 工数の浪費、テスト範囲の拡大、複雑性の増加
要求: 「ユーザーリストを表示する」
実装: 「ユーザーリスト + ソート + フィルタ + エクスポート
+ グラフ + リアルタイム更新」 ← 過剰
対策:
✓ 受入基準の厳密な定義
✓ YAGNI（You Ain't Gonna Need It）原則の徹底
✓ コードレビューでの要求逸脱チェック
✓ Definition of Done の遵守
16.1.4 「Assumption Driven」パターン
問題: ステークホルダーへの確認なしに要求を推測する
結果: 的外れなシステム、大規模な手戻り
開発者: 「ユーザーは当然この機能を望んでいるだろう」← 危険
対策:
✓ 仮説検証アプローチ（Lean Startup 的思考）
✓ MVP / プロトタイプによる早期検証
✓ ユーザーインタビューの定期実施
✓ 仮定ログ（Assumption Log）の維持
16.1.5 「Analysis Paralysis」パターン
問題: 完璧な要求定義を目指して分析が終わらない
結果: 着手の遅延、市場機会の喪失
6ヶ月間 要求分析 → まだ着手できず → 市場が変化 → 最初からやり直し
対策:
✓ タイムボックスの設定（分析期間に上限を設ける）
✓ 段階的詳細化（Progressive Elaboration）
✓ 80/20 ルール: 80% 確実なら着手する
✓ リスクベースの優先順位付け
16.2 要求ドキュメントの品質改善例
Before（悪い要求）:
REQ-01: システムは高速に動作すること
REQ-02: システムは使いやすいこと
REQ-03: 適切なセキュリティ対策を施すこと
REQ-04: データは正確に処理されること
REQ-05: システムは安定していること
After（良い要求）:
NFR-PERF-001: すべての API エンドポイントの応答時間は、
同時接続 1,000 ユーザー時に P95 で 200ms 以内であること。
計測: New Relic APM で月次レポート。
NFR-USE-001: 初回ユーザーが主要タスク（商品検索→注文完了）を
マニュアルなしで 5 分以内に完了できること。
計測: ユーザビリティテスト（月次、5名以上）で
タスク完了率 90% 以上。
NFR-SEC-001: 通信は TLS 1.3 以上で暗号化し、
保存データは AES-256 で暗号化すること。
OWASP Top 10 (2021) 全項目に対策を実装し、
四半期ごとのペネトレーションテストで重大脆弱性ゼロ。
FR-DATA-001: 注文処理トランザクションは ACID 特性を満たし、
データベースの整合性制約違反時にロールバックすること。
受入基準: 同時 100 トランザクションで不整合ゼロ。
NFR-REL-001: サービス稼働率 99.95%（年間停止 4.38 時間以内）。
単一ノード障害時 30 秒以内に自動フェイルオーバー。
計測: CloudWatch + PagerDuty で月次 SLA レポート。
17. ケーススタディ
17.1 ケース1: EC サイトリニューアルプロジェクト
プロジェクト概要
| 項目 | 内容 |
|---|---|
| プロジェクト名 | オンラインストアリニューアル |
| 期間 | 6ヶ月（2025年1月〜6月） |
| チーム | 10名（PO×1、BA×1、Dev×5、QA×2、UX×1） |
| 手法 | スクラム（2週間スプリント） |
| 予算 | 5,000万円 |
要求工学プロセスの適用
フェーズ1: ディスカバリー（2週間）
## 実施内容
1. ステークホルダーインタビュー（12名）
2. 現行システム分析（ドキュメント + ソースコード）
3. 競合分析（5社）
4. ユーザー行動データ分析（Google Analytics 6ヶ月分）
## 成果物
- ステークホルダーマップ
- ペルソナ（3タイプ）
- カスタマージャーニーマップ
- 競合機能比較表
フェーズ2: 要求定義（4週間）
## 実施内容
1. ユーザーストーリーマッピングワークショップ（2日間）
2. 非機能要求定義セッション
3. アーキテクチャ方針決定
4. プロトタイプ作成・検証
## 成果物
- プロダクトバックログ（137ストーリー）
- Must: 52 ストーリー
- Should: 41 ストーリー
- Could: 29 ストーリー
- Won't: 15 ストーリー
- 非機能要求仕様書
- ワイヤーフレーム（主要25画面）
- アーキテクチャ決定記録（ADR）5件
フェーズ3: 反復開発（20週間 = 10スプリント）
Sprint 1-2: 認証・ユーザー管理（Must）
Sprint 3-4: 商品カタログ・検索（Must）
Sprint 5-6: カート・注文（Must）
Sprint 7-8: 決済・配送連携（Must）
Sprint 9: メール通知・管理画面（Should）
Sprint 10: 最適化・バグ修正
成果と学び
## 定量的成果
- 納期: 予定通り（6月30日リリース）
- 予算: 4,800万円（予算内）
- 要求カバレッジ: Must 100%, Should 85%, Could 31%
- 欠陥率: 要求起因の欠陥は全体の 12%（業界平均 40-50% から大幅改善）
- 要求安定度: Sprint 5 以降 10% 以下で安定
## 学び（レトロスペクティブ要約）
1. ディスカバリーフェーズの投資は回収された
→ 後工程での大きな手戻りがゼロ
2. プロトタイプ検証が効果的
→ UI 関連の手戻りを 70% 削減
3. バックログリファインメントの定期実施が重要
→ Ready の定義導入後、Sprint 失敗率 0%
17.2 ケース2: 医療機器ソフトウェア（規制対象）
プロジェクト概要
| 項目 | 内容 |
|---|---|
| プロジェクト名 | 患者モニタリングシステム |
| 規制 | IEC 62304（医療機器ソフトウェアライフサイクル） |
| リスク分類 | クラスC（生命に関わるリスク） |
| 期間 | 18ヶ月 |
要求工学の特徴
## 規制要件による追加プロセス
1. リスク分析（ISO 14971）との連携
- 各要求にリスク分析結果を紐付け
- ハザード分析→安全性要求の導出
2. トレーサビリティの完全性
- ユーザーニーズ → ソフトウェア要求 → 設計 → 実装 → テスト
- 双方向のトレーサビリティが必須
3. 要求の形式的レビュー
- インスペクションによる全要求レビュー
- レビュー記録の保持（監査対応）
4. バリデーション計画
- 要求定義段階でバリデーション計画を策定
- 臨床的妥当性の確認
リスク分析との連携例
| ハザード | リスク評価 | 安全性要求 |
|---------|----------|-----------|
| 心拍数の誤表示 | S:5 P:3 → 高 | SR-001: 心拍数測定精度 ±2 bpm |
| アラーム不発動 | S:5 P:2 → 高 | SR-002: アラーム応答時間 < 1秒 |
| データ通信遅延 | S:4 P:3 → 中 | SR-003: データ送信遅延 < 500ms |
| 電源断時データ喪失 | S:3 P:2 → 低 | SR-004: UPS 搭載、30分バックアップ |
(S: 重大度 1-5, P: 発生確率 1-5)
17.3 ケース3: マイクロサービスアーキテクチャ移行
プロジェクト概要
モノリシックな Java アプリケーションからマイクロサービスアーキテクチャへの移行プロジェクト。
要求工学の課題と解決策
## 課題: 既存システムからの要求抽出
問題:
- ドキュメントが古く、現行仕様と乖離
- 暗黙的なビジネスルールが大量に存在
- ドメイン知識がベテラン開発者に集中
解決策:
1. ソースコード考古学（Code Archaeology）
- 静的解析ツールで依存関係を可視化
- テストコードからビジネスルールを抽出
2. イベントストーミング
- ドメインイベントの特定→ bounded context の導出
- 既存のビジネスプロセスの可視化
3. ストラングラーフィグパターン
- 段階的移行のため、要求も段階的に定義
- サービスごとに SRS を作成
## イベントストーミングの結果例
ドメインイベント:
[注文作成] → [在庫確認] → [決済処理] → [出荷指示]
↓ ↓ ↓ ↓
注文サービス 在庫サービス 決済サービス 配送サービス
サービス間インターフェース要求:
- 非同期メッセージング（Apache Kafka）
- 結果整合性（Eventual Consistency）
- サーキットブレーカーパターン
18. まとめと今後の展望
18.1 本記事のまとめ
本記事では要求工学の全容を体系的に解説した。主要なポイントを以下に整理する。
┌─────────────────────────────────────────────────────┐
│ 要求工学の全体像 │
├─────────────────────────────────────────────────────┤
│ │
│ 【基本プロセス】 │
│ 抽出 → 分析 → 仕様化 → 検証 → 管理 │
│ (反復的・並行的に実行) │
│ │
│ 【要求の階層】 │
│ ビジネス要求 → ユーザー要求 → システム要求 │
│ (機能要求 + 非機能要求 + 制約条件) │
│ │
│ 【品質モデル】 │
│ ISO/IEC 25010: 機能適合性、性能効率性、互換性、 │
│ 使用性、信頼性、セキュリティ、保守性、移植性 │
│ │
│ 【記述手法】 │
│ ユースケース、ユーザーストーリー、SRS、Gherkin、 │
│ フォーマル仕様 │
│ │
│ 【管理手法】 │
│ 変更管理（CCB）、トレーサビリティ、バージョン管理 │
│ メトリクス、品質ダッシュボード │
│ │
│ 【開発アプローチとの統合】 │
│ ウォーターフォール: 包括的 SRS │
│ アジャイル: プロダクトバックログ + 反復精緻化 │
│ SAFe: 階層的要求管理 │
│ DevOps: 継続的要求工学 │
└─────────────────────────────────────────────────────┘
18.2 要求工学の成功要因
長年の実践と研究から明らかになった要求工学の成功要因を示す。
## 成功要因トップ10
1. **ステークホルダーの早期かつ継続的な関与**
→ 要求の源泉であるステークホルダーを常にプロセスに巻き込む
2. **明確なスコープ定義**
→ 「何をやらないか」を「何をやるか」と同じくらい明確にする
3. **複数の抽出技法の組み合わせ**
→ インタビューだけでなく、観察、プロトタイプ、ワークショップを併用
4. **要求の優先順位付け**
→ MoSCoW、WSJF 等の手法で客観的に優先度を決定
5. **テスト可能な受入基準**
→ すべての要求に検証可能な基準を定義
6. **トレーサビリティの維持**
→ ビジネス要求からテストケースまでの一貫した追跡
7. **変更管理プロセスの確立**
→ 変更を拒否するのではなく、制御する仕組み
8. **要求レビューの実施**
→ 早期に欠陥を検出し、修正コストを最小化
9. **適切なツールの選択**
→ プロジェクト規模と特性に合ったツールを使用
10. **継続的な改善**
→ メトリクスに基づくプロセス改善
18.3 AI 時代の要求工学
AI・大規模言語モデル（LLM）の急速な発展は、要求工学に変革をもたらしつつある。
18.3.1 AI による自動化が期待される領域
┌─────────────────────────────────────────┐
│ AI 自動化の成熟度マップ │
├─────────────────────────────────────────┤
│ │
│ 高い自動化可能性（現在利用可能） │
│ ├─ 要求文書の品質チェック（曖昧性検出） │
│ ├─ 要求の自動分類（機能/非機能） │
│ ├─ テンプレートベースの要求生成 │
│ └─ 用語の一貫性チェック │
│ │
│ 中程度の自動化可能性（研究段階） │
│ ├─ ステークホルダー発言からの要求抽出 │
│ ├─ 要求間の矛盾・依存関係の検出 │
│ ├─ トレーサビリティリンクの自動生成 │
│ └─ テストケースの自動生成 │
│ │
│ 低い自動化可能性（人間が主導） │
│ ├─ ステークホルダーとの交渉・合意形成 │
│ ├─ ビジネス戦略に基づく優先順位付け │
│ ├─ 創造的な要求の発見 │
│ └─ 倫理的・社会的影響の評価 │
└─────────────────────────────────────────┘
18.3.2 AI システムに対する新たな要求カテゴリ
AI/ML システムの普及により、従来の要求工学では扱われなかった新しい要求カテゴリが重要性を増している。
## AI システム特有の要求
### 公平性要求（Fairness Requirements）
- 性別、年齢、人種等による偏りの排除
- 公平性メトリクス（統計的パリティ、均等化オッズ等）の定義
- バイアステストの定期実施
### 説明可能性要求（Explainability Requirements）
- モデルの意思決定根拠の提示機能
- 説明の粒度（グローバル / ローカル説明）
- 対象者（専門家 / 一般ユーザー）別の説明
### データ品質要求
- 学習データの品質基準（完全性、正確性、代表性）
- データリネージ（出所の追跡可能性）
- データの鮮度と更新頻度
### ロバスト性要求
- 敵対的入力（Adversarial Input）への耐性
- 分布シフトへの対応
- 性能劣化の検出と対処
### 倫理的要求
- EU AI Act の規制分類への適合
- プライバシー by Design
- 人間による監視・介入の仕組み
18.4 今後の研究・実践の方向性
## 要求工学の将来展望
1. **自然言語処理の高度化**
- LLM による要求の自動生成・検証の精度向上
- マルチモーダル入力（音声、画像）からの要求抽出
2. **データ駆動型要求工学**
- ユーザー行動データからの自動要求推論
- A/B テスト結果に基づく要求の継続的最適化
3. **デジタルツインと要求工学**
- シミュレーションによる要求の早期検証
- IoT データに基づく要求の動的更新
4. **量子コンピューティングへの対応**
- 量子アルゴリズム固有の要求定義手法
- ハイブリッド（古典+量子）システムの要求管理
5. **持続可能性要求の標準化**
- グリーンソフトウェア要求の体系化
- カーボンフットプリントの要求指標化
6. **要求工学教育の進化**
- AI 支援による学習体験の個別最適化
- 実践的シミュレーション環境の普及
18.5 結語
要求工学は、ソフトウェア開発の基盤であり続ける。技術が進化し、開発手法が変化しても、「ステークホルダーの真のニーズを理解し、それを実現可能な仕様に変換する」という本質的な課題は変わらない。
AI の進歩は要求工学の自動化を促進するが、同時に AI システム自体の要求定義という新たな課題を生み出している。要求工学の実践者には、従来の体系的知識に加え、AI・データサイエンスのリテラシーと、倫理的・社会的な視点がますます求められるようになるだろう。
本記事が、要求工学の理解と実践の一助となれば幸いである。
参考文献
- IEEE 29148:2018 - Systems and software engineering - Life cycle processes - Requirements engineering
- ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE)
- Pohl, K. (2010). Requirements Engineering: Fundamentals, Principles, and Techniques. Springer.
- Wiegers, K. & Beatty, J. (2013). Software Requirements, 3rd Edition. Microsoft Press.
- Robertson, S. & Robertson, J. (2012). Mastering the Requirements Process, 3rd Edition. Addison-Wesley.
- Leffingwell, D. (2011). Agile Software Requirements. Addison-Wesley.
- Patton, J. (2014). User Story Mapping. O'Reilly Media.
- Cockburn, A. (2001). Writing Effective Use Cases. Addison-Wesley.
- van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley.
- IREB (International Requirements Engineering Board). CPRE Foundation Level Syllabus.