業務要求の洗い出しといえば，ITエンジニアであれば真っ先に思い浮かべるのは要件定義であろう。RFPの業務要求と要件定義はどこが違うのか。結論から言えば，行う作業やアウトプットは基本的に同じ性質のものである。ただし，RFPと要件定義では目的が異なる。もちろん，RFPと要件定義どちらも最終の大目的は「システム構築を成功させ，そのシステムが経営戦略や事業目標の達成に寄与すること」であるが，短期的な目的で言えば，以下の違いがある。
RFP：提案内容と見積もりから最適なベンダーを選定し，調達を適正に行うこと
要件定義：システム開発の範囲と要求仕様を業務の観点から明確に定義すること
RFPは調達フェーズの作業の一つであることをあらためて認識したい（図2）。
また，しばしば「RFPは要件定義をきちんと終わらせてから書くものなのか」「RFPを書けば要件定義はやらなくてよいのか」といった質問を受けることがある。それは正しいとも間違っているとも一概にはいえない。
理想論的には，RFPの業務要求資料が完成された要件定義書であれば，ベンダーの見積り作業の精度は確かに向上するであろう。しかし，現実問題としてRFP作成の段階で発注側だけで要件定義作業を完全に終わらせることができるのは，情報システム部門に十分な人的リソースと上流工程スキルがあり，なおかつユーザー部門が積極的に参画し業務に関する問題点と改善案を提示できる体制が組めるような一部の大手企業だけであろう。
要件定義レベルの詳細さは捨てる決断
たいていの場合は限られた時間と人的リソースの中で，業務要求の洗い出しと整理を行わなければならない。つまり，どこかで割り切って要件定義レベルの詳細さは捨てる決断をする必要があるのだ。では，どこで割り切って線を引くのか。どのケースでも当てはまるような明確な線引きの基準はない。それは現実的には人的リソースと時間的な制約で決まってしまう。しかし，RFPの目的が調達であることをきちんと認識すれば，最低限押さえるべきポイントはおのずと決まってくる。
・詳細さよりも網羅性を重視し，大きな項目の漏れはないように洗い出す
・業務要求の優先順位を明確にし，必須の要求は何かを決める
・現行システムへの要望だけでなく，当たり前にできている基本機能を説明する
別の言い方をすれば，RFPの業務要求と要件定義は「幅は同じで，深さが違う」のである。
ベンダーが見積もりを作成するときに特に注意するのは，システムの対象範囲である。サブシステム単位や大きな機能単位で漏れがあれば，見積もりは大幅に狂ってしまう。また，要求の優先順位はベンダーでは判断できないものが多い。必須機能でも，あれば便利程度の機能であっても，ベンダーの立場ではプログラム作成に必要な労力だけで同じように見積もりを算出するしかない。
さらに，現行システムの問題点だけを羅列してベンダーに提示しても，それではベンダーはシステムの全体像を理解することはできず，提案や見積もりは作れない。「深さ」は要件定義の段階でリカバリ可能であるが，「幅」を誤ると大きくスコープが狂うということを忘れないでほしい。
