ＲＦＰは、なぜ、何をしたいのか（Ｗｈｙ、Ｗｈａｔ）を示し、提案書はどのように解決しいくらかかるのか（Ｈｏｗ、Ｈｏｗ Ｍｕｃｈ）を示すものだといえます。
ビジネスの課題をＩＴを活用することで解決したいが、その対応策を提案してほしいし、その実現の費用を知りたいために、ＲＦＰを作成するのですから、解決すべき課題と開発すべき情報システムに必要な機能を明確に示し、開発者（受注者）が開発費用を適切に見積もるための情報を提供する必要があります。
☆
- Ｗｈａｔ：業務での課題
- 情報システムはあくまで手段に過ぎません。その情報システムを活用することにより、業務をどう変えるのかを示すことにより、適切な提案を得ることができます。
- Ｗｈｅｒｅ：場所と対象範囲と場所
- これには二つがあります。その一つは対象範囲です。業務および情報システムの対象範囲を明確にしないと、提案が膨大なものになったり部分的なものになってしまいます。たとえば、在庫管理といっても、在庫状況を把握するだけでよのか、在庫を削減することを対象にするのかでは、解決の方法やシステム規模は大きく異なります。
他の一つは開発場所です。一般に受注者は受注企業で作業しますが、ハードウェアやソフトウェアの都合などにより、あるいは共同作業の都合により、発注企業で作業することもあります。そのとき、開発環境の提供をどう負担するかにより、費用が大きく異なります。 - Ｗｈｏ：外注作業と社内作業
- 自社の情報システム部門や利用部門が行う作業を明確にして、発注する範囲を明確にする必要があります。これがあいまいなために発生するトラブルが多いのです。
- Ｗｈｅｎ：予定時期
- その情報システムを用いた業務を、いつから開始するのかの予定です。それから逆算して、情報システムの納期、開発のスケジュールを提案させるのです。開発期間が短いと、要員の確保やプロジェクトの管理に多大なな費用がかかることがあります。
- Ｈｏｗ：情報システムでの実現方法
- これはベンダの任務なので通常はＲＦＰの範囲外ですが、レガシー環境／オープン環境、特定のソフトウェア、特定の開発方法論などの条件が重要ならば、それらを明示する必要があります。
- Ｈｏｗ Ｍｕｃｈ：費用
- 通常は提案を求めるため記述しません。しかし、概要を示すことにより、想定している規模が明確になり、予定していたものとかけ離れた提案になるのを予防することができます。
ＲＦＰにより提案書が作成されるのですが、内部検討が不十分なままに「販売システム一式」的なＲＦＰにしたのでは、ベンダはどのようなシステムにしてよいかわかりませんから、適切な提案は得られません。
ＲＦＰと提案書に基づいて相談し、それにより開発すべきシステムの外部設計書が作られ、それに基づいて契約が行われ、システム開発が行われるのですが、あいまいなＲＦＰや提案書では、外部設計書になるまでに大きな手間や費用が発生します。
外部設計書があいまいなままにシステムを開発したら、役に立たないシステムになる危険があります。
提案書には見積金額が記入されています。その後、契約にいたる段階で再見積が行われますが、提案書の金額がベースになるため、ＲＦＰの内容が、金銭的なトラブルの原因になることが多いのです。 ☆
その費用は開発費用に取り込まれることもありましょうし、発注者の能力を危惧して割高な見積をしたり、甘く見て開発に初心者を割りつけたりするかもしれません。
できることなら、そのまま外部仕様書となる程度まで検討しつくしたＲＦＰを作成できればよいのですが、自社に高い能力が求められますし、労力もかかります。コンサルタントの協力を得る場合でも、そのコンサルタントに適切な説明ができなければなりません。まして、発注を予定しているベンダに依頼するのでは、ベンダに都合のよいものになるのは当然ですので、絶対に避けるべきです。
ところが、現実には、自社でＲＦＰを作成しているのはむしろ少ない状態です。それどころか、発注先にＲＦＰ作成を依頼していることもあるのです。
システム開発を成功させるには，適切なＲＦＰを作成することが大切ですが，ＲＦＰの作成はかなり難しい要因があります。まして，情報化での成熟度が未熟なときは，次のような当惑があります。
- 実務ですら何をするべきかがわからない
☆
「情報化にあたって，目的を明確にすることが重要だ」というが，究極的な目的は明確だ。「儲けたい」のだ。もっと詳細にというのであれば，「今年中に期間損益をプラスにするために○○億円の利益，３年度には累積赤字を解消するために○○億円の利益」と数値的に示すことすらできる。でも，どうしたら儲かるかがわからないのだ（わかっていることは当然これまでにやってきた）。まして，どのようなシステムにすればよいのかなどは見当もつかない。ともかく販売が増加することが儲けることに直結するだろうから「販売システム一式」としたのだ。ベンダは「ソリューション」を売り物にしているのだから，情報化で儲ける算段を持っているのだろう・・・。
これはあまりにも極端な例ですが，これまで経営戦略や情報化構想などに関心を持っていなかった企業では，これに近い状況のようです。このような状況では，適切な情報化は期待できません。情報化検討以前に経営戦略の策定をする必要があります。経営戦略の策定やそれを受けた情報化戦略の策定にはいくつかの方法がありますが，その説明には膨大な紙面を要しますので，別の機会に譲ります。 - どのようなシステムにすればよいのかわからない
☆
当社は部品メーカーである。利益を上げるには，顧客の納期短縮の要求に応えて欠品を防止すること，コストダウンのために在庫の削減が重要である。それには需要が予測できればよい。ここまではわかるのだが，需要予測をするためにどのような情報システムが必要なのかわからない・・・。
コンピュータで需要予測ができればよいのですが，それを直接に解決する情報システムは現実には存在しません。そもそも需要予測をするには，需要を左右する要因は何か，その要因に関連する先行情報は何か（数値データだけでなない）などがわかっていなければなりません。需要予測のためのソフトもありますが，その多くは過去の実績を統計的な手法を用いて予測するものです。そのような単純な手段が現実に役立つことは稀でしょう。
それで，需要予測に直接応えるのではなく，それの前提の一つとして「受注状況や在庫を正確に把握する」ための受注システムや在庫システムを構築する必要があります。このように，ステップ・バイ・ステップで情報化を進める総合的な計画を考えることが肝要なのです。 - どのように説明すればよいのかわからない
☆
受注システムや在庫システムを構築することになった。現状の受注業務やそれの望ましい形態も検討した。しかし，それには受注の仕方，在庫の確認，伝票のデザイン，過去の受注の分析など，いろいろな改善提案があり，それをどうまとめるのかわからない。どのような情報システムがほしいのかがわかったが，情報技術に弱いので，どう説明すればベンダが理解できるのかわからない。ベンダが求める事項を聞き出してほしい。それで「委細面談」としたのだ・・・。
このような要件を調査分析して適切なシステム仕様を設計することは，情報技術のなかでも最も高度な技術ですし，豊富な経験を要求されます。情報システム部門すら存在しない企業に，このような能力を持つ人材がいるとは思えません。 - どんな条件を提示するのかがわからない
☆
たとえば「画面が出るまでの時間」が重要だということは，いわれれば成程と思うが，事前にそんなことまで気づかない。後になって文句をいったら「ＲＦＰで要求されていないから・・・」と逃げられては困る。また，応答時間は短いほうがよいのに決まっているから適当に１秒と書いたら，それを実現するために途方もない費用を請求されるのも困る・・・。
情報技術の経験や常識がないと，何を要件にする必要があるのか，どのレベルにしてよいかを示すことは困難ですし，開発に関する条件や契約事項に何をあげればよいのか当惑します。しかも，それらが明確になっていないために，後になって大きな問題になることが多いのです。