新システムが業務要求をすべて満たし，機能的には問題がないとしても，例えばレスポンスタイムが遅く，画面遷移の度に10秒，20秒と掛かったのでは業務システムとしては使いものにはならない。あるいは1人2人のユーザーだとサクサク動くが，同時利用ユーザー数が増えるととたんに遅くなるというシステムも役に立たない。システムの適切なパフォーマンスとキャパシティを確保するために，RFPではこれらの要求を具体的に記述するべきである。
まず，パフォーマンスに関する技術要求の具体的な例とそのまとめ方について説明していこう（図4）。
（1）画面遷移のレスポンスタイム（通常時）
一般にエンドユーザーが業務としてシステムを利用する場合，ストレスを感じない画面遷移の時間は3秒以内といわれている。これが一つの目安となろう。ただし，業務によってはもっと速いレスポンスタイムが必要な場合もあるし，逆にもう少し遅くても許容されるケースもあろう。ここで記述すべき要求は通常の処理におけるレスポンスタイムに限定すべきであり，特殊な処理とは要求を分けた方がよい。
（2）特殊な処理を行った場合のレスポンスタイム
システムの処理によっては膨大なデータベースを検索したり，画像処理を伴ったりと，3秒どころか数十秒から数分（場合によってはそれ以上）必要なことがある。そのような処理に対して3秒を無理強いすることは正しい要求とはいえない。またそのような処理はシステムを作ってみないとレスポンスが分からない場合も多い。そのような処理に関しては，別途相談する旨を記載するとよい。
（3）日次の夜間バッチ処理の時間
システムのユーザーへの提供時間により，夜間のバッチ処理時間は限られてくる。例えば7時から23時までがサービスタイムとすれば，バッチに使える時間は8時間である。実際にはデータのバックアップやスナップショットの取得のタイミングもあり，バッチ処理に使える時間はもっと短い。その時間内に終了しないと翌朝のサービスタイム開始が遅延してしまうので，そこはきちんと要求として記述する必要がある。
（4）月次/四半期/年次などのバッチ処理の時間
上記同様に月次や四半期ごとのバッチ処理は時間が限られているので，それらの制約が明確な場合は，RFPにて記述すべきである。
次に，キャパシティに関する技術要求の具体的な例とそのまとめ方について説明していこう。
（1）システム利用を行うユーザーの総数
新システムの利用者であるユーザーの総数を提示する。このユーザーの総数は主に以下の二つに影響を与える。
［ソフトウエアライセンス数と料金］
パッケージソフトウエアの場合，ソフトウエア利用の料金体系がユーザー数によって決まる場合が多い。またユーザー数が多ければボリュームディスカウントなどのコスト的な恩恵があることも多い。
［システムの全体的な規模感をみる］
サーバーの処理能力は総ユーザー数ではなく同時利用ユーザー数の方が影響は大きいが，システム全体のスケールを見る上で総ユーザー数の情報は欠かせない。
（2）同時利用を行うユーザーの最大数
ソフトウエアの種類によっては総ユーザー数ではなく，最大同時利用者数で課金するものもある。またサーバーの処理能力の見積もりは同時利用ユーザー数で測ることが多い。同時利用ユーザーが多いと1台の本番機では処理できず，複数台のサーバーを連動させるなどの技術的な対応も必要となる。
（3）ネットワークの拠点ごとのユーザー数
例えば同じ100人のユーザーがシステムを利用するとしても，1カ所に100人いる場合と10カ所それぞれ10人ずつ分散している場合では，ベンダーが技術的に検討すべき課題は全く異なる。拠点が多いほどネットワーク設計やパフォーマンスに影響が出るので，正確に記述する必要がある。
（4）総データ量
旧システムから新システムへのデータ移行が行われる場合，移行方法や必要作業時間などの作業を見積もるのに必要な情報となる。
また，新システムに必要なディスク容量の下限を知るための情報ともなる。
続いて拡張性について考えたい。
新システムがカットオーバ―した時点で，既にそのシステムの性能の限界で稼働しているシステムではすぐに使いものにならなくなってしまう（図5）。一般的な業務システムであれば少なくとも5年以上は利用するので，それに耐えられる余裕をシステムに持たせるか，あるいは柔軟かつ簡易な拡張性が保証されている必要がある。ある程度，近い将来のユーザー数やデータ量，トランザクションなどの増加の予測が立つのであれば，ベンダーに余裕や拡張性を意識した提案をしてもらうために，予測値の記述を行いたい。
