情報システムは、要件定義に従って開発されるのですから、それが不適切だったり、あいまいだったりすれば、大きなトラブルになります。
これは、家を建てることを考えればわかるでしょう。間取りの変更を要求しても、設計図を作成している段階ならば、たいしたことではありません。ところが、土台を作り棟上げ式を行うころにいわれたら、振り出しに戻るので膨大な費用と時間がかかります。
ベーム（Barry w. Boehm, “Software Engineering Economics,” Prentice-Hall, 1981.）は、要件定義が確定した段階で、要求の誤りを発見して修正する場合のコストを１としたとき、後の段階で発見して修正するコストは、
設計段階 ５
プログラミング段階 １０
稼働開始後 １００
になると指摘しています。また、全体の欠陥のうち、プログラミングのエラーによるものは３５％程度で、６５％は、それ以前の要件定義や設計の上流工程で埋め込まれるとの指摘もあります。
また、納期遅れの理由のうち、要件定義に関連することが多いとの調査結果もあります（図示）。
ところが現実には、「人により要求が異なる」、「要求がいつになっても決まらない」、「後になってから要求が変わる」など、要求分析段階での利用部門への苦情が多いのです（図示）。
要求仕様が決まらないとか後になって変更になることは、開発プロジェクトの費用増加、納期遅れに大きく影響します。特に納期遅れは、成果を享受する時期が遅れることになります。納期を守ろうとすると、最終工程でのテストが手抜きになり、実動してから大きなトラブルが発生する原因になります。