要求分析は時間のかかる忍耐を要するものとなる場合もあり、微妙な心理学的スキルを要することもある。新たなシステムは人間関係や環境を変えることもあるので、関係者全てを特定しておくことも重要であり、関係者全員のニーズを聞き出すと共に、彼らがシステムとどう関わるかを理解していることを確認する必要がある。アナリストは顧客から要求を聞きだすためにいくつかの技法を活用する。インタビューやフォーカスグループ（要求ワークショップ）から要求リストを作成するのは古くからある技法である。やや新しい技法としてプロトタイピングとユースケースがある。必要に応じてアナリストはこれらの手法を駆使し、関係者の要求を正確に把握する。それによってビジネスの必要性に合ったシステムが開発される。
関係者インタビュー

関係者インタビューは要求分析の典型的な手法である。工数との兼ね合いで関係者の選択が一般に必要とされる。インタビューによってプロジェクトの開始時点で想定していなかった要求が明らかとなり、個々の要求の間で矛盾が生じることがある。
要求ワークショップ

場合によっては関係者を集めた「要求ワークショップ」を開くのが有効である。ワークショップは関係者が集中できる環境で行うのが望ましい。司会役は議論が逸れないよう注意する。また、書記役が議論を記録しておくのがよい。司会役はプロジェクターと図作成ソフトウェアを使ったり、紙とマーカーによる資料を使ったりする。司会役の重要な仕事として、個々の要求の優先順位付けが参加者の個性にあまり依存しすぎないように注意しなければならない。
契約型要求リスト

要求を文書化する方法として契約型要求リストがある。複雑なシステムでは、この要求リストが数百ページにもなることがある。
検証可能な目標

最善のプロジェクトでは、要求リストを単なる手掛かりとして扱い、繰り返し「何故このような要求が出てきたか」を問いかけて真のビジネスの目的を明らかにする。そして関係者と開発者で各目標の達成状況を測るための基準を設ける。これら目標は個別の（基準のない）要求リストよりも変化しない。重要な目標が達成されたとき、手早いプロトタイピングと開発によってプロジェクトの途中であっても関係者に成果として提供することがある。
プロトタイプ

1980年代中ごろ、要求分析問題の解決策として「プロトタイピング」が注目された。プロトタイプとは、開発前にユーザーに対してアプリケーションを視覚化してみせるための画面表示などである。プロトタイプによってユーザーはシステムがどのようなものかを具体的に描くことができるようになり、開発前に設計上の決定を行うことが容易になる。プロトタイプの導入によってユーザーと開発者の対話が大いに改善された。最初に画面の見え方を示しておけば後工程での変更が少なくなり、全体としてコスト削減につながる。

しかしその後、次のような問題は解決できないことがわかってきた:

マネージャから見れば、プロトタイプが即座に出来てきたのに、実際の開発に時間がかかる理由が理解できない。

設計者は実際の開発にあたって一からやり直すことになるのを恐れて、プロトタイプのコードをつぎはぎして実システムを作ることを強制されているように感じる。

プロトタイプはユーザーインターフェイスの設計などには有効である。しかし、本来の要求が何だったのかということとは無関係である。

設計者とユーザーがユーザーインターフェイスの設計に重点を置きすぎて、実際にビジネスを行うシステムがおろそかになる。

プロトタイプは、実際に動作する簡単なアプリケーションの場合もあるが、線画（ワイヤフレーム）の場合もある。線画では色をつけないようにして、最終的なシステムの見た目と混同させないようにするのがよいとされる。
ユースケース詳細は「ユースケース」を参照

ユースケースは、新システムやシステムの改善にあたっての要求を文書化する技法である。各ユースケースは1つ以上の「シナリオ」を提供し、その中でシステムやエンドユーザーや他のシステムがどのように相互作用を行ってビジネスの目標を達成するかを描く。ユースケースでは技術的な専門用語を排し、エンドユーザーやその分野の専門家にわかる用語を使うのが望ましい。ユースケースはソフトウェア開発者とエンドユーザーが共同で執筆することも多い。

ユースケースはソフトウェアの挙動を説明する単純なツールである。ユースケースにはユーザーがインターフェイスを通してソフトウェアを動作させる全ての方法に関する文章による記述が含まれる。ユースケースはソフトウェア内部の動きは記述されないし、どう実装されるかも説明されない。単にユーザーが何かをソフトウェアにさせる際の手順を示すだけである。このような形で全てのユーザーとシステムのやり取りが記述されている。

1990年代、ユースケースは機能的要求仕様を捉える手法として急速に広まった。特にその起源となったオブジェクト指向の世界で顕著であるが、その利用はオブジェクト指向システムに限られたものではなく、ユースケース自体はオブジェクト指向に縛られた手法ではない。

各ユースケースは1つのビジネス目標/タスクを達成する方法を描いている。従来からのソフトウェア工学の観点からすれば、1つのユースケースはシステムの1つの機能を描いていると言える。多くのソフトウェアプロジェクトでは、システム全体を記述するのに数十から数百のユースケースが必要であることを意味する。特定のソフトウェアプロジェクトの形式化の度合いやそのプロジェクトの工程によってユースケースをどこまで詳細に記述すべきかが決まる。

ユースケースは、あるビジネス目標を達成する際の外部のアクターと対象システムの相互作用を定義する。アクターとはシステムの外にあってシステムとやり取りをするものであり、ユーザーだったり、別のシステムだったりする。

ユースケースではシステムを「ブラックボックス」として扱い、システム外から観測できるやり取りを扱う。これは意図的な方針であり、この方針によって要求仕様の記述が簡略化され、その機能がどのように実装されるかという前提（先入観）を排除することができる。

ユースケースは以下のように記述されるべきである。

ビジネスの目標を達成するためのビジネスタスクを記述する。

適切な詳細さで記述される。

ソフトウェア開発者が一回のリリースで実装出来る程度の量である。

ユースケースは機能的要求仕様にとってはよい手法だが、非機能的要求仕様には適さない。ただし、パフォーマンス・エンジニアリングでは、重要なユースケースにはそれに対応した非機能的要求が存在するとされる。
ソフトウェア要求仕様

ソフトウェア要求仕様は、開発対象システムの振る舞いを完全に記述したものである。これには、そのソフトウェアとユーザーとのやり取りを全て記述したユースケースも含まれる。ユースケースは機能要求仕様とも呼ばれる。ユースケース以外に非機能的要求仕様も含まれる。非機能的要求仕様は、設計や実装に対する何らかの制限（性能要求、品質要求、設計上の制約など）である。

ソフトウェア要求仕様の記述に関する推奨手法は IEEE 830-1998 で示されている。この標準はソフトウェア要求仕様の考えられる構造、望ましい目次、品質などについて記している。
関係者の特定

1990年代になって特に強調されるようになったのは、「関係者」の特定である。「関係者」とは単にそのシステムを発注した企業の社員だけに限られない点に注意されたい。他に考えられる「関係者」として次のような人々がいる:

その企業と対等な関係で密に連携している（あるいはこれから連携が予定されている）企業

何らかの事務処理部門

組織上上位にある者

問題点