C.システムの発注者と受注者が同一の会社のケース

このケースはパッケージベンダーなどをイメージしているが、一番一般化して語るのが難しいものである。

ここでの想定は要件定義者とその開発者が同じ会社であるという想定で述べる。

この場合要件定義者と開発者の間には契約関係が存在しないので要件定義としてドキュメントを明確に記述する必要性があまり無い。
従って、要件定義としてドキュメント作成に時間とコストをかける価値は無いが、立場の異なる要件定義者と開発者の間の合意事項を記述した物として要件定義が存在する。

つまりシステムとして実現する範囲を明確にするということよりも、要件定義行程での要件分析（どのような機能が必要なのかを思案する）としての意味合いが大きい。
つまり、コードに落とす前段階において、どのような機能が必要なのか、そしてなぜそれが必要なのかを表現する手段として要件定義が存在する。

また、このケースのような場合、開発と要件定義が平行して行われ、繰り返し開発の中で徐々に要件が固まって行く進め方をしている所が多い。要件を固めそれを実装し、その結果を評価して、再度要件の見直しと新たな要件の組み立てを繰り返して行う方式である。

上記のようなことを想定しこのケースの場合の要件定義は以下のような意味合いを持つ

　・定義することよりも最低限度の分析を重視したドキュメント
　・全体を広く浅く扱った物と繰り返し毎のキーポイントの詳細な記述の２つに分かれたドキュメント
　・網羅的ではなく必要最低限度の合意のためのドキュメント

以上３回に渡って立場の相違による要件定義の意味合いの違いを見てきた。

要件定義をどのようにするかを考える時は、これらの立場の違いを意識してその内容を考える必要がある。