しかしその後、次のような問題は解決できないことがわかってきた:
プロトタイプは、実際に動作する簡単なアプリケーションの場合もあるが、線画（ワイヤフレーム）の場合もある。線画では色をつけないようにして、最終的なシステムの見た目と混同させないようにするのがよいとされる。
ユースケース.
ユースケースはソフトウェアの挙動を説明する単純なツールである。ユースケースにはユーザーがインターフェイスを通してソフトウェアを動作させる全ての方法に関する文章による記述が含まれる。ユースケースはソフトウェア内部の動きは記述されないし、どう実装されるかも説明されない。単にユーザーが何かをソフトウェアにさせる際の手順を示すだけである。このような形で全てのユーザーとシステムのやり取りが記述されている。
ユースケースは、あるビジネス目標を達成する際の外部のアクターと対象システムの相互作用を定義する。アクターとはシステムの外にあってシステムとやり取りをするものであり、ユーザーだったり、別のシステムだったりする。
ユースケースではシステムを「ブラックボックス」として扱い、システム外から観測できるやり取りを扱う。これは意図的な方針であり、この方針によって要求仕様の記述が簡略化され、その機能がどのように実装されるかという前提（先入観）を排除することができる。
ユースケースは以下のように記述されるべきである。
ユースケースは機能的要求仕様にとってはよい手法だが、非機能的要求仕様には適さない。ただし、パフォーマンス・エンジニアリングでは、重要なユースケースにはそれに対応した非機能的要求が存在するとされる。
ソフトウェア要求仕様.
ソフトウェア要求仕様は、開発対象システムの振る舞いを完全に記述したものである。これには、そのソフトウェアとユーザーとのやり取りを全て記述したユースケースも含まれる。ユースケースは機能要求仕様とも呼ばれる。ユースケース以外に非機能的要求仕様も含まれる。非機能的要求仕様は、設計や実装に対する何らかの制限（性能要求、品質要求、設計上の制約など）である。
関係者の特定.
問題点.
関係者の問題.
このような要因によって要求仕様は開発が開始されてからも変更され続けることになる。
技術者/開発者の問題.
要求分析において技術者や開発者が次のような問題を引き起こすこともある:
解決の試み.