プロジェクト管理者ノート出来ない理由を鵜呑みにしない。出来ないと言った相手が良く調べていないのかも知れない。思考が停止し、考慮が不足しているのかも知れない。諦めず、食い下がろう。 仕様書は契約書のようなもの。詳細に記述し、委託者と受託者が十分な時間を取って確認する。 要件確認リストを使い、可能な限り要件漏れを無くす。 要件定義書をユーザと共にレビューする。 早期の段階でプロトタイプを作り、イメージを確認する。 変更が見込まれる機能は可変化する。 現場を見学し、現場の声を聞く。出来れば業務を体験させてもらう。 事前に技術検証をしておく。 不明点はユーザに必ず確認を取る。その際、解決策をいくつか用意しておく。 全体の整合性はレビューで防ぐ。 余裕があれば、仕様説明を兼ねて、レビュー会にプログラマーを参加させる。 依頼日 依頼者 システム名 処理名 機能名 変更理由 変更内容 想定リスク リスク対策 適用予定日 適用日
