また、アプリケーション・パッケージが何も手を加えない状態で動作可能であるという点に注目すれば、ユーザー要件定義などの局面でアプリケーション・パッケージの動作やユーザーインタフェースなどをユーザーに体験してもらうことにより、書類上の機能やユーザーインタフェースの記述によって要件定義を進める場合よりも具体的な意見を収集することができる。この方法は、システム開発手法で言うところのプロトタイピング手法(開発の初期にシステムの雛型＝プロトタイプを作成し、最終的な稼働のイメージを具体的にユーザーに示しながら、システムの仕様についての調整を行っていく手法)に該当すると考えられる。
さらに、アプリケーション・パッケージが、システム化された業務に対するパッケージベンダー自身の考え方や、導入済みのユーザーの意見を反映したものであるという点に注目すれば、同じ業務上の機能を実現するにも、ユーザーが全く考え付かなかった方法が採用されている可能性がある。
また、導入実績が多いほど、不具合が修正されてシステムとしての安定度が高まっていることが期待できる。
しかし、完成品としてのアプリケーション・パッケージの機能，インタフェース，業務の流れが受け入れがたい場合には、「必要な機能が欠如している」，「事務の流れと合っていない」という評価が下され、これを補うためのカスタマイズ作業により、開発期間・工数・コストの増大は避け難いものになる。そうした場合には、完成品としてのブラックボックス性が開発の自由度の低さにつながり、場合によっては一から開発した場合に匹敵するコストが必要になることも考えられる。また、プログラム構造やデータ構造などの内部仕様が適切に構造化されていない場合には、その形態で安定していることが裏目に出て、データ項目の迫力口や機能仕様の変更などの保守作業の負荷が高くなってしまう可能性が高い。
以上のとおり、アプリケーション・パッケージが完成品であるために発生する二面性をどのように評価するかが利用を検討する際のキーポイントになっている。
