【基本的な考え方】
要件定義は、業務にとって「使える」、「役に立つ」、「運用できる」システムを定義することです。
発注者は、それまでのやり方にとらわれることなく、むだな業務や非効率な手順を客観的に評価し、新業務をゼロベースで再設計することが大切です。ともすると、業務の複雑な部分を複雑なままシステムに置き換えようとするので、そうならないように注意しなければなりません。
また、ビジネスニーズからシステムの実現機能に落とし込んだ後、その機能が本来のビジネス要求を満たしているものか、立ち戻って検証することが重要です。ＩＴ化が自己目的化して、何のために実現したかったのかを見失うこともよくあります。これに運用テスト段階で気が付くのでは悲劇です。業務要件があいまいであると判明した場合には、常に業務部門と調整し、システムの合目的性を高いレベルに保つことが必要です。
そして、定義した新たな業務、新たなシステムが運用できるのかどうかの検証も重要となってきます。
要件定義の場に参加して、議論が横道にそれたり、枝葉末節に陥らないよに助言するのは受注者の役割です。また、受注者は、要件として定義したものが、システム化計画で想定したコストや期間と比べて過剰なものや、逆にあまりに多くの費用を要さずとも実現可能な要件は勇気を持って変更を進言しなくてはなりません。
【行動規範】
・発注者は、常にビジネス要件の視点から、システム要件の妥当性を検証する。
・発注者は、シンプルな業務設計を心がける。
・発注者は、運用要件を要件定義のなかで定義する。
・受注者は、オーバースペックを是正し、コストショートを進言する。