requirement-review

要件レビュー

設計と開発を開始する前に、要件を体系的にレビューして品質を検証し、問題を特定します。要件が完全で、明確で、一貫性があり、テスト可能で、追跡可能であることを確認します。

レビューワークフロー

1. 準備

関連するすべてのドキュメントを収集します。

• 要件ドキュメント（BRD、SRS、ユーザーストーリー）
• 非機能要件と制約
• 要件トレーサビリティマトリクス（利用可能な場合）
• プロジェクトの背景（憲章、目標）
• 既存の受け入れ基準

2. 品質評価

6つの品質属性を使用して、各要件を評価します。

1. 完全性：すべてのニーズが網羅され、詳細の欠落やTBDがなく、依存関係が特定されている
2. 明確性：曖昧さがなく、具体的で、あいまいな用語（「使いやすい」「速い」「簡単」など）がない
3. 一貫性：矛盾がなく、用語と優先順位に一貫性がある
4. テスト可能性：測定可能な受け入れ基準と明確な合否判定によって検証できる
5. 追跡可能性：ビジネス目標、設計、テストに関連付けられている
6. 実現可能性：制約（予算、スケジュール、能力）の範囲内で技術的に実現できる

詳細な評価基準とドキュメント別チェックリストについては、quality-checklists.mdを参照してください。

3. 問題の特定

要件に共通する問題を特定します。

曖昧：「システムは高速でなければならない」→ 測定可能な基準を指定します：「リクエストの95%で応答時間が2秒未満」

テスト不能：「システムは安全でなければならない」→ パスワードの複雑さ、暗号化標準、監査ログなど、具体的な制御を定義します

不完全：「システムは通知を送信しなければならない」→ チャネル、タイミング、内容、受信者を指定します

矛盾：REQ-012「電話番号は必須」対REQ-089「電話番号は任意」→ ステークホルダーによる解決が必要な問題として指摘します

詳細な修正前後の例については、examples.mdを参照してください。

4. 品質スコアの算出

各品質属性のスコア（0～100%）を算出します。

• 90～100%：優秀 - 問題は最小限
• 75～89%：良好 - 軽微な改善が必要
• 60～74%：普通 - 目立った不足がある
• 60%未満：不良 - 大幅な手直しが必要

全体品質 = 6つの属性の平均
目標：本番環境に対応できる品質として90%以上

5. レポートの作成

以下の項目を含む、構造化されたレビューレポートを作成します。

エグゼクティブサマリー：品質評価、推奨事項、主な強み（2～3件）、重大な問題（2～3件）、優先度の高い対応事項

詳細な所見：品質スコア、重大度別の問題（クリティカル／メジャー／マイナー）、要件IDを含む具体例

アクション項目：担当者、期限、工数見積もり、承認条件を含む優先順位付きリスト

レポートの完全な構成とテンプレートについては、report-templates.mdを参照してください。

6. 推奨事項

明確な判断を提示します。

• 承認：要件の品質が90%以上
• 条件付き承認：設計の前に重大な問題を解決する必要がある
• 大幅な改訂：品質が60～74% - 大幅な手直しが必要
• 却下：品質が60%未満、または根本的な問題がある - 全面的な再設計が必要

ドキュメント別の重点項目

ビジネス要件ドキュメント（BRD）

ビジネス目標、ステークホルダーのニーズ、スコープの定義、ビジネスケース、制約に重点を置きます

ソフトウェア要件仕様書（SRS）

機能要件、非機能要件（パフォーマンス、セキュリティ、スケーラビリティ）、システムの動作、統合ポイント、IEEE 830への準拠に重点を置きます

ユーザーストーリーのバックログ

INVEST基準（Independent：独立性、Negotiable：交渉可能性、Valuable：価値、Estimable：見積もり可能性、Small：小ささ、Testable：テスト可能性）、受け入れ基準の形式（Given-When-Then）、ストーリーの形式、優先順位付けに重点を置きます

ドキュメント別の評価基準については、quality-checklists.mdを参照してください。

重大度の定義

• Critical：作業の進行を妨げるため、直ちに修正する必要があります（セキュリティ上の不備、根本的な矛盾、スコープの欠落）
• Major：品質に大きく影響するため、承認前に修正する必要があります（基準が曖昧、受け入れ基準が欠落）
• Minor：品質向上のための改善です。対応が望ましい項目です（書式、例、機能強化）

注意すべき一般的なアンチパターン

• Gold Plating：要求されていない機能を追加する
• Solution-Focused：「何を」ではなく「どのように」を指定する（要件はテクノロジーに依存しないものにする必要があります）
• Scope Creep：変更管理を行わずに変更を受け入れる
• Analysis Paralysis：要件をいつまでも過剰に完璧なものにしようとする
• Weak Acceptance Criteria：テスト条件が曖昧、または存在しない
• No Traceability：要件がビジネス目標と結び付いていない

曖昧な用語の置き換え

必ず測定可能な基準に置き換えてください。

• 「使いやすい」「直感的」「簡単」→ 使いやすさの指標を定義する
• 「速い」「すばやい」「応答性が高い」→ 応答時間の目標値を指定する
• 「安全」→ 具体的なセキュリティ対策を定義する
• 「スケーラブル」→ 容量と負荷の目標値を定義する
• 「信頼性が高い」→ 稼働率と復旧時間を定義する

標準への準拠

• IEEE 830：SRS の構成および内容に関する標準
• INVEST：ユーザーストーリーの品質基準（Independent、Negotiable、Valuable、Estimable、Small、Testable）
• ISO/IEC 25010：システムおよびソフトウェアの品質モデル
• 業界固有：HIPAA（医療）、PCI-DSS（決済）、SOC 2（SaaS）、FDA（医療機器）

標準への準拠の詳細については、quality-checklists.mdを参照してください

レポートの形式

次の構成でレビュー報告書を作成してください。

1. エグゼクティブサマリー（1ページ）：全体評価、主な所見、推奨事項
2. 品質指標（0.5ページ）：属性ごとのスコアと目標値
3. 詳細な所見（2～5ページ）：属性ごとに分類した問題、例、推奨事項
4. 対応項目（1ページ）：担当者と期限を含む、優先順位付けされた一覧
5. 承認判断（0.5ページ）：根拠と次のステップを含む推奨事項

報告書は事実に基づき、具体的で、実行可能な内容にしてください。問題を指摘する際は、必ず具体的な要件 ID を示してください。

レポートテンプレートの詳細については、report-templates.mdを参照してください