1. 誰（アクター）
1.1. 客
1.1.1. プロジェクトオーナー
1.1.1.1. 自分は使わないがお金は払う
1.1.1.2. ざっくりの要望を言う
1.2. ベンダー
1.2.1. 営業
1.2.1.1. 費用調整
1.2.1.2. 支払者との調整
1.2.1.3. 決定者との調整
1.2.2. PM
1.2.2.1. レビュー
1.2.2.2. スケジュール調整
1.2.3. SE
1.2.3.1. 要望ヒアリング
1.2.3.1.1. 要望定義書
1.2.3.2. 機能まとめ
1.2.3.2.1. 要件定義書
1.2.3.3. お客様調整
1.2.3.3.1. 利用者との調整
1.2.4. 開発
1.2.4.1. プログラマー
1.2.5. 保守・運用
1.2.5.1. 不具合対応
1.2.5.2. 要望対応
1.2.5.2.1. 次期バージョンアップ
2. 後で
2.1. 稼働前
2.1.1. 仕様検討時
2.1.2. 仕様決定後
2.1.3. 結合テスト時
2.1.4. リハーサル時
2.2. 稼働後
2.2.1. 不具合対応
2.2.2. 要望対応
2.2.3. 定期バージョンアップ
3. こじれる
3.1. ユーザー
3.1.1. 要件に即してない
3.1.1.1. 機能要件？
3.1.1.2. 非機能要件？
3.1.1.3. 業務要件？
3.1.2. 要件が不明瞭
3.1.2.1. あいまいな記述
3.1.2.2. お互い分からないまま記載
3.1.3. やりたい事が途中で増える
3.1.3.1. 軽い気持ちであれもやって
3.1.3.2. 勉強会とかで新しい知見がはいる
3.1.4. 可能技術の理解が乏しい
3.1.4.1. 無理難題を言う
3.1.5. 環境の変化
3.1.5.1. 算定条件が変わる
3.1.5.2. オーナーの気分が変わる
3.2. ベンダー
3.2.1. 誤解が生まれる要件
3.2.1.1. 現場運用の不理解
3.2.1.2. あいまいな記述
3.2.2. スケジュール・見積が甘い
3.2.2.1. 納期ありきで考える
3.2.2.1.1. 客に物申せない
3.2.2.2. 根拠ある見積が作成できない
3.2.2.2.1. 価格ありきで見積もる
3.2.2.2.2. オーナーに折衝できない
3.2.2.3. 運用・保守フェーズ
3.2.2.3.1. 費用とリソースが確保できていない
3.2.3. 技術的制約や不具合の発覚
3.2.3.1. 設計が甘い
3.2.3.1.1. ドキュメント類を利活用できてない
3.2.3.1.2. 納期に追い詰められてちゃんと出来ない
3.2.3.1.3. 能力不足
3.2.3.2. 客へ代替案を提案できない
4. 要件定義
4.1. 上流工程
4.1.1. 要望定義書
4.2. ドキュメント
4.2.1. 要件定義書
4.2.1.1. 要件定義書
4.2.1.2. 業務一覧／フロー図
4.2.2. システム要件
4.2.3. 機能要件
4.2.4. 非機能要件
4.3. 下流工程
4.3.1. プロジェクト計画
4.3.2. 詳細設計
4.4. なぜ作らないといけないのか？
4.4.1. ドキュメントの目的は？
4.4.1.1. 多人数でのコミュニケーション齟齬を減らす
4.4.1.2. これが両者の「共通の頭の中」という大定義
4.4.1.3. 基本的にはレビュワーが必要
4.4.1.3.1. 網羅性
4.4.1.3.2. 妥当性
4.4.1.3.3. 整合性
4.4.1.3.4. 寧ろ正確性は不要
4.5. まずは作成手順の理解
4.5.1. 客は何がしたいか
4.5.1.1. 要望定義書が完成しているか
4.5.1.1.1. これは主に客が作る
4.5.1.1.2. ベンダーは作成を手伝う
4.5.1.2. 要望定義書のどれを実現させるか
4.5.1.2.1. 要望の選別
4.5.1.2.2. 次期システムへの要望候補
4.5.2. 運用理解
4.5.2.1. ベンダーと客の間での齟齬を減らす
4.5.2.2. シチュエーション
4.5.2.2.1. 誰が
4.5.2.2.2. どんなとき
4.5.2.2.3. どのタイミングで
4.5.2.2.4. どんな事を
4.5.2.2.5. 誰に対して
4.5.2.2.6. どの目的で
4.5.2.2.7. 何をする
4.5.2.3. 業務一覧
4.5.2.3.1. 業務の棚卸
4.5.2.4. 運用フロー図
4.5.2.4.1. 業務の流れ図
4.5.3. 要件定義書の作成
4.5.3.1. 客の日常の運用が理解
4.5.3.2. 客の要望と照合
4.5.3.3. 要望定義書の中からシステム化するものを列挙
5. 管理方法
5.1. 常々変更する前提
5.1.1. 他ドキュメントと密な関係がある
5.1.2. 他ドキュメントの変更が発生する
5.1.2.1. 影響個所を確認
5.1.2.1.1. 許容できれば修正
5.1.2.1.2. 許容できなければ報告し再度変更判断を仰ぐ
5.1.2.2. 関係部署への変更箇所の通知
5.1.2.2.1. 他ドキュメントも影響個所を確認
5.1.3. 関係部署への変更の通知
5.1.3.1. 関係者は変更箇所を確認
5.1.3.1.1. 自分の作業影響の有無を確認
5.1.3.1.2. 全体的な気づきがあれば連絡（レビュー要素）
5.1.4. 要件定義書派生の変更はない
5.1.4.1. 要件定義作成フェーズ後
5.1.4.2. よほどの事がない限り
5.1.4.3. 要件定義の変更は全てのドキュメントに影響する
5.2. 変更管理方法
5.2.1. 変更管理プロセスの導入とドキュメントの更新
5.2.2. スコープ管理とリソース・スケジュールの再評価
5.2.3. 運用状況のモニタリングと定期的なレビュー・改善
5.2.4. ドキュメント管理システムの導入と定期的な更新・監査
5.2.5. 維持・運用リソースの計画と確保
6. コミュニケーション
6.1. 会話
6.2. ボディランゲージ
6.3. 表情
6.4. 文章
6.4.1. チャット
6.4.2. メール
6.4.3. ドキュメント