要求分析（ようきゅうぶんせき、Requirements Analysis）とは、システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す。要求分析はシステム設計工程でも重要な部分であり、アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である。顧客の要求が特定されたら、システム設計者がその解決策を設計することになる。概念上、要求分析には以下の3つの活動が含まれる:要求分析は時間のかかる忍耐を要するものとなる場合もあり、微妙な心理学的スキルを要することもある。新たなシステムは人間関係や環境を変えることもあるので、関係者全てを特定しておくことも重要であり、関係者全員のニーズを聞き出すと共に、彼らがシステムとどう関わるかを理解していることを確認する必要がある。アナリストは顧客から要求を聞きだすためにいくつかの技法を活用する。インタビューやフォーカスグループ（要求ワークショップ）から要求リストを作成するのは古くからある技法である。やや新しい技法としてプロトタイピングとユースケースがある。必要に応じてアナリストはこれらの手法を駆使し、関係者の要求を正確に把握する。それによってビジネスの必要性に合ったシステムが開発される。関係者インタビューは要求分析の典型的な手法である。工数との兼ね合いで関係者の選択が一般に必要とされる。インタビューによってプロジェクトの開始時点で想定していなかった要求が明らかとなり、個々の要求の間で矛盾が生じることがある。場合によっては関係者を集めた「要求ワークショップ」を開くのが有効である。ワークショップは関係者が集中できる環境で行うのが望ましい。司会役は議論が逸れないよう注意する。また、書記役が議論を記録しておくのがよい。司会役はプロジェクターと図作成ソフトウェアを使ったり、紙とマーカーによる資料を使ったりする。司会役の重要な仕事として、個々の要求の優先順位付けが参加者の個性にあまり依存しすぎないように注意しなければならない。要求を文書化する方法として契約型要求リストがある。複雑なシステムでは、この要求リストが数百ページにもなることがある。最善のプロジェクトでは、要求リストを単なる手掛かりとして扱い、繰り返し「何故このような要求が出てきたか」を問いかけて真のビジネスの目的を明らかにする。そして関係者と開発者で各目標の達成状況を測るための基準を設ける。これら目標は個別の（基準のない）要求リストよりも変化しない。重要な目標が達成されたとき、手早いプロトタイピングと開発によってプロジェクトの途中であっても関係者に成果として提供することがある。1980年代中ごろ、要求分析問題の解決策として「プロトタイピング」が注目された。プロトタイプとは、開発前にユーザーに対してアプリケーションを視覚化してみせるための画面表示などである。プロトタイプによってユーザーはシステムがどのようなものかを具体的に描くことができるようになり、開発前に設計上の決定を行うことが容易になる。プロトタイプの導入によってユーザーと開発者の対話が大いに改善された。最初に画面の見え方を示しておけば後工程での変更が少なくなり、全体としてコスト削減につながる。しかしその後、次のような問題は解決できないことがわかってきた:プロトタイプは、実際に動作する簡単なアプリケーションの場合もあるが、線画（ワイヤフレーム）の場合もある。線画では色をつけないようにして、最終的なシステムの見た目と混同させないようにするのがよいとされる。ユースケースは、新システムやシステムの改善にあたっての要求を文書化する技法である。各ユースケースは1つ以上の「シナリオ」を提供し、その中でシステムやエンドユーザーや他のシステムがどのように相互作用を行ってビジネスの目標を達成するかを描く。ユースケースでは技術的な専門用語を排し、エンドユーザーやその分野の専門家にわかる用語を使うのが望ましい。ユースケースはソフトウェア開発者とエンドユーザーが共同で執筆することも多い。ユースケースはソフトウェアの挙動を説明する単純なツールである。ユースケースにはユーザーがインターフェイスを通してソフトウェアを動作させる全ての方法に関する文章による記述が含まれる。ユースケースはソフトウェア内部の動きは記述されないし、どう実装されるかも説明されない。単にユーザーが何かをソフトウェアにさせる際の手順を示すだけである。このような形で全てのユーザーとシステムのやり取りが記述されている。1990年代、ユースケースは機能的要求仕様を捉える手法として急速に広まった。特にその起源となったオブジェクト指向の世界で顕著であるが、その利用はオブジェクト指向システムに限られたものではなく、ユースケース自体はオブジェクト指向に縛られた手法ではない。各ユースケースは1つのビジネス目標/タスクを達成する方法を描いている。従来からのソフトウェア工学の観点からすれば、1つのユースケースはシステムの1つの機能を描いていると言える。多くのソフトウェアプロジェクトでは、システム全体を記述するのに数十から数百のユースケースが必要であることを意味する。特定のソフトウェアプロジェクトの形式化の度合いやそのプロジェクトの工程によってユースケースをどこまで詳細に記述すべきかが決まる。ユースケースは、あるビジネス目標を達成する際の外部のアクターと対象システムの相互作用を定義する。アクターとはシステムの外にあってシステムとやり取りをするものであり、ユーザーだったり、別のシステムだったりする。ユースケースではシステムを「ブラックボックス」として扱い、システム外から観測できるやり取りを扱う。これは意図的な方針であり、この方針によって要求仕様の記述が簡略化され、その機能がどのように実装されるかという前提（先入観）を排除することができる。ユースケースは以下のように記述されるべきである。ユースケースは機能的要求仕様にとってはよい手法だが、非機能的要求仕様には適さない。ただし、パフォーマンス・エンジニアリングでは、重要なユースケースにはそれに対応した非機能的要求が存在するとされる。ソフトウェア要求仕様は、開発対象システムの振る舞いを完全に記述したものである。これには、そのソフトウェアとユーザーとのやり取りを全て記述したユースケースも含まれる。ユースケースは機能要求仕様とも呼ばれる。ユースケース以外に非機能的要求仕様も含まれる。非機能的要求仕様は、設計や実装に対する何らかの制限（性能要求、品質要求、設計上の制約など）である。ソフトウェア要求仕様の記述に関する推奨手法は IEEE 830-1998 で示されている。この標準はソフトウェア要求仕様の考えられる構造、望ましい目次、品質などについて記している。1990年代になって特に強調されるようになったのは、「関係者」の特定である。「関係者」とは単にそのシステムを発注した企業の社員だけに限られない点に注意されたい。他に考えられる「関係者」として次のような人々がいる:Steve McConnell はその著書 "Rapid Development" の中で、ユーザーが要求を集める作業を妨げる可能性を以下のように示した:このような要因によって要求仕様は開発が開始されてからも変更され続けることになる。要求分析において技術者や開発者が次のような問題を引き起こすこともある:このような意思疎通問題の解決策としてそのビジネスの専門家やシステム分析の専門家が雇われることもある。1990年代に登場したプロトタイピング、統一モデリング言語(UML)、ユースケース、アジャイルソフトウェア開発などの技法も従来の手法の問題点を解決するべく導入されてきた。アプリケーションのシミュレーションツールや定義ツールも市場に出回るようになってきた。このようなツールはユーザーとIT組織の意思疎通問題を解決するよう設計されており、実際にコードを開発する前にアプリケーションを試してみることを可能にしている。これらツールの特徴は以下の通り:

出典:wikipedia