Top Highlights

• プロジェクト計画時に要件変更に対処するための管理工数も見込む。最低限、外部設計工程の完了までは、定例会議のアジェンダに要件の追加・変更の検討を入れる。追加・変更については、とにかく見積もって、実施の可否や実施方法の選択肢を用意し、各々 メリット・デメリットをみんなで検討する（※４ 　こちらを参照）。他の要件との差し替えなんてそのあとだわ。あと要件定義工程と設計以降の工程を別に契約するのも有効
• それにケンカするなら早いほうがいい。要件定義のときに徹底的にやっておけば、あとは案外うまくいくもの
• ◎要件変更要望があった際には、そのメリット・デメリットをユーザに説明し、一緒に採否を検討する ◎追加要望の場合には必ず費用を見積もる ◎見積りの際には、要件変更の採否検討や要件変更の管理工数を予測して、プロジェクト管理費用に含んで
• ※３ 　経済産業省発行の「情報システム・モデル取引・契約書」では、外部設計検討会について記した第21条の３に「外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第33条（本契約及び個別契約内容の変更）の手続によるものとする」と記して
• 機能要件はシステムが何をするのかを一番具体的に明らかにする部分で、ここでのモレや誤解、理解不足は、直接ケンカの火種になるから要注意