主な目的は、「業務要件を明確にしてシステム要件に落とし込む」ことで、要件を漏れなく洗い出して明確にすることです。現実には「人間だもの」、すべてを完璧にこなせる訳ではなく、時間が経てば意見も見方も変わることがあるし、体制変更で上司の意見に振り回されることもあります。ウォーターフォール型の開発スタイルでは、そのような変更は大きな手戻りとなる訳です。そのため、「追加要件や要件変更は必ず起こるもの」と考えておくのが、無難です。言って、どうせ変更が入るから程々にしておいてもいいや、ではありません。確定した要件に対する追加要望であれば、概ね基本設計完了後は変更管理として、軽微な変更などの場合であればオンスケで実施するか、軽微な内容で済まないようであれば別費用(予算)&別スケジュールで進めるかなどの判断に持ち込むことができますし、それ以外であれば追加要件として振り分けることができます。良くないのは、グレーゾーンを作ってしまうことです。このような場合、ユーザーは(システム側の)要件漏れを主張してきますし、システム側は追加要件を主張することになりますが、原則として力関係はユーザーの方が上です。この事実については賛否両論あろうかと思いますが、そもそも資本主義社会では、お金は権力の高い方から低い方へ流れるという大原則があるので反論しても致し方ありません。身を守る意味でも要件定義はグレーゾーンを作らないようにきちんとやりましょう。ポイント後々追加や変更が入らないような完璧な要件定義は無理。月別アーカイブはてなブログをはじめよう!tsunetsune7さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。