Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
✍️ 標準の定めるテンプレートを手に入れたい方は、こちら → サンエム上流工程標準
🧭実践ガイド
🐾具体的なステップ
以下に示すステップは、定義ではなく、おすすめのサンプルです。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
📘インプット
- 機能要件一覧
- 業務ルール定義書
- 制約条件一覧
- ToBe業務フロー
- 用語集
- 関連規格・法規制
✅すること
| タスク名 | 目的 | タスク内容（詳細） |
|---|---|---|
| 非機能要件項目の洗い出し | システム品質の要求を網羅 | 性能、可用性、信頼性、拡張性、保守性、セキュリティ、法規制などの観点から項目を抽出業務ルール・制約条件も参照 |
| 定量基準の設定 | 測定・評価可能な形で表現 | 応答時間、スループット、稼働率、信頼性指標など数値目標を設定法規制・標準規格の遵守レベルを明示 |
| 優先度・重要度の整理 | 実装・テスト・運用の優先順位を明確 | 必須／望ましい／オプションに分類業務影響度やリスクを考慮 |
| 非機能要件一覧作成 | 関係者が理解・合意できる形に整理 | 要件ID／名称／説明／測定基準／優先度／関連機能を一覧化トレーサビリティ確保 |
| レビューと合意形成 | 妥当性と実現可能性を確認 | 業務担当者、設計・運用担当でレビュー不整合や矛盾を修正し、承認記録を残す |
🚫しないこと
| NG項目 | 説明 | なぜ問題か |
|---|---|---|
| 漠然とした表現 | 「高速」「高可用性」など数値未定義 | テスト・設計で判断できず、議論が発生 |
| 個人経験則で設定 | 過去の体感値を流用 | 現行業務や環境に合わず、運用リスクが増加 |
| 機能要件混入 | 処理内容や操作手順を非機能要件に記載 | 目的が不明確になり、設計で誤解発生 |
| 非現実的目標 | 技術的に達成困難な数値目標を設定 | 開発・テスト段階で手戻りやコスト増 |
| レビュー省略 | 承認・合意なしで定義 | ステークホルダー間で認識齟齬、後工程で変更頻発 |
❤️🔥マインドセット（プロセスへの臨み方）
- 「非機能要件はシステム品質の契約条件である」
- 「測定可能な形で定義する」
- 「機能要件との整合を意識する」
- 「業務影響とリスクに基づき優先度を考える」
- 「関係者合意が品質保証の第一歩」
😵💫よくある失敗例
- 漠然とした表現 → 後工程で議論・認識齟齬
- 優先度不明 → 重要非機能要件が後回し、性能不足
- 業務条件無視 → 運用ボトルネック、障害発生
- レビュー不足 → ステークホルダー合意なし、手戻り多発
- 他要件との整合性欠如 → 機能要件やデータ要件と矛盾して開発滞る