要求分析
1980年代中ごろ、要求分析問題の解決策として「プロトタイピング」が注目された。プロトタイプとは、開発前にユーザーに対してアプリケーションを視覚化してみせるための画面表示などである。プロトタイプによってユーザーはシステムがどのようなものかを具体的に描くことができるようになり、開発前に設計上の決定を行うことが容易になる。プロトタイプの導入によってユーザーと開発者の対話が大いに改善された。最初に画面の見え方を示しておけば後工程での変更が少なくなり、全体としてコスト削減につながる。
しかしその後、次のような問題は解決できないことがわかってきた:
マネージャから見れば、プロトタイプが即座に出来てきたのに、実際の開発に時間がかかる理由が理解できない。
設計者は実際の開発にあたって一からやり直すことになるのを恐れて、プロトタイプのコードをつぎはぎして実システムを作ることを強制されているように感じる。
プロトタイプはユーザーインターフェイスの設計などには有効である。しかし、本来の要求が何だったのかということとは無関係である。
設計者とユーザーがユーザーインターフェイスの設計に重点を置きすぎて、実際にビジネスを行うシステムがおろそかになる。
プロトタイプは、実際に動作する簡単なアプリケーションの場合もあるが、線画(ワイヤフレーム)の場合もある。線画では色をつけないようにして、最終的なシステムの見た目と混同させないようにするのがよいとされる。
ソフトウェア要求仕様は、開発対象システムの振る舞いを完全に記述したものである。これには、そのソフトウェアとユーザーとのやり取りを全て記述したユースケースも含まれる。ユースケースは機能要求仕様とも呼ばれる。ユースケース以外に非機能的要求仕様も含まれる。非機能的要求仕様は、設計や実装に対する何らかの制限(性能要求、品質要求、設計上の制約など)である。
ソフトウェア要求仕様の記述に関する推奨手法は IEEE 830-1998 で示されている。この標準はソフトウェア要求仕様の考えられる構造、望ましい目次、品質などについて記している。
要求分析において技術者や開発者が次のような問題を引き起こすこともある:
技術者とエンドユーザーは語彙の違いによって話が通じないことがある。結果として意思疎通できていないにもかかわらず、完全な合意に達したと勘違いしたまま開発を行うことがある。
技術者や開発者は要求を既存のシステムやモデルに当てはまるようにしようとする傾向があり、その顧客専用のシステムを開発するのを避けようとする。
分析を技術者やプログラマが行ってしまい、対象分野の専門家が参加しないためにユーザーのニーズが正しく反映されないことがある。