要求分析

この記事には参考文献や外部リンクの一覧が含まれていますが、脚注によって参照されておらず、情報源が不明瞭です。 脚注を導入して、記事の信頼性向上にご協力ください。（2023年9月）

要求分析（ようきゅうぶんせき、英: requirements analysis）とは、システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す。要求分析はシステム設計工程でも重要な部分であり、アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である。顧客の要求が特定されたら、システム設計者がその解決策を設計することになる。

概念上、要求分析には以下の3つの活動が含まれる:

• 要求を聞きだす: 顧客やユーザーとの対話によってその要求を聞きだす。
• 要求を分析する: 要求を必要に応じて明確化し、補い、矛盾点や問題点を明らかにする。
• 要求を記録する: 要求を文書化する。文書形式には通常の自然言語の文書以外にユースケース、ユーザーストーリーなどがある。

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

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

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

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

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

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

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

• マネージャから見れば、プロトタイプが即座に出来てきたのに、実際の開発に時間がかかる理由が理解できない。
• 設計者は実際の開発にあたって一からやり直すことになるのを恐れて、プロトタイプのコードをつぎはぎして実システムを作ることを強制されているように感じる。
• プロトタイプはユーザーインターフェイスの設計などには有効である。しかし、本来の要求が何だったのかということとは無関係である。
• 設計者とユーザーがユーザーインターフェイスの設計に重点を置きすぎて、実際にビジネスを行うシステムがおろそかになる。

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

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

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

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

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

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

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

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

• ビジネスの目標を達成するためのビジネスタスクを記述する。
• 適切な詳細さで記述される。
• ソフトウェア開発者が一回のリリースで実装出来る程度の量である。

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

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

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

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

• その企業と対等な関係で密に連携している（あるいはこれから連携が予定されている）企業
• 何らかの事務処理部門
• 組織上上位にある者

Steve McConnell はその著書 Rapid Development の中で、要求を集める作業をユーザーが妨げる可能性を以下のように示した:

• ユーザーは自らが何を欲しているか理解していないことがある。
• ユーザーは要求仕様書に関わりたがらないことがある。
• ユーザーは既にスケジュールと費用が確定した状態で新たな要求を出してくる。
• ユーザーとの対話には時間がかかる。
• ユーザーはレビューに参加したがらないか、参加できないことがある。
• ユーザーは技術に疎い。
• ユーザーは開発工程を理解しない。

このような要因によって要求仕様は開発が開始されてからも変更され続けることになる。

要求分析において技術者や開発者が次のような問題を引き起こすこともある:

• 技術者とエンドユーザーは語彙の違いによって話が通じないことがある。結果として意思疎通できていないにもかかわらず、完全な合意に達したと勘違いしたまま開発を行うことがある。
• 技術者や開発者は要求を既存のシステムやモデルに当てはまるようにしようとする傾向があり、その顧客専用のシステムを開発するのを避けようとする。
• 分析を技術者やプログラマが行ってしまい、対象分野の専門家が参加しないためにユーザーのニーズが正しく反映されないことがある。

このような意思疎通問題の解決策としてそのビジネスの専門家やシステム分析の専門家が雇われることもある。

1990年代に登場したプロトタイピング、統一モデリング言語(UML)、ユースケース、アジャイルソフトウェア開発などの技法も従来の手法の問題点を解決するべく導入されてきた。

アプリケーションのシミュレーションツールや定義ツールも市場に出回るようになってきた。このようなツールはユーザーとIT組織の意思疎通問題を解決するよう設計されており、実際にコードを開発する前にアプリケーションを試してみることを可能にしている。これらツールの特徴は以下の通り:

• 電子ホワイトボードでアプリケーションの流れを図示したり代替案を検証する。
• ビジネスロジックやデータの必要性を捉える能力
• 最終的なアプリケーションをかなりの精度で実現する高機能プロトタイプを生成する能力
• 対話性
• 文脈的な要求やコメントを追記できる機能
• 遠隔ユーザーや分散ユーザーがシミュレーションとやりとりする機能

• McConnell, Steve (1996年). Rapid Development: Taming Wild Software Schedules (1st ed. ed.). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5. http://www.stevemcconnell.com/ 
• Wiegers, Karl E. (2003年). Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle (2nd ed. ed.). Redmond: Microsoft Press. ISBN 0-7356-1879-8. http://www.processimpact.com 
• Andrew Stellman and Jennifer Greene (2005年). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8. http://www.stellman-greene.com 

• ソフトウェア開発工程
• 要件
• ソフトウェア要求仕様
• 要求管理
• ビジネスプロセス・リエンジニアリング
• システム分析
• BABOK
• 情報技術
• ユースケース
• プロセスモデリング
• データモデリング
• モデル駆動工学
• モデル変換言語

• 要求分析 山本修一郎（NTTデータ）、月刊ビジネスコミュニケーション