要件分析

システム工学とソフトウェア工学において、要件分析は、さまざまな利害関係者の矛盾する可能性のある要件を考慮し、ソフトウェアまたはシステムの要件を分析、文書化、検証、管理しながら、新しい製品や変更された製品やプロジェクトを満たすニーズや条件を決定するタスクに焦点を当てています。^[2]

要件分析は、システムやソフトウェアプロジェクトの成功または失敗に極めて重要です。^[3]要件は文書化され、実行可能で、測定可能で、テスト可能で、^[4]追跡可能で、^{[4]特定されたビジネスニーズまたは機会に関連し、}システム設計に十分な詳細レベルで定義されている必要があります。

概念的には、要件分析には3種類のアクティビティが含まれます。^{[引用が必要]}

• 要件の抽出: (例: プロジェクト憲章または定義)、ビジネス プロセスのドキュメント化、および関係者へのインタビュー。これは、要件収集または要件検出と呼ばれることもあります。
• 要件の記録: 要件はさまざまな形式で文書化されることがあります。通常は概要リストが含まれ、自然言語ドキュメント、ユースケース、ユーザーストーリー、プロセス仕様、データモデルなどのさまざまなモデルが含まれる場合があります。
• 要件の分析: 記載された要件が明確、完全、重複なし、簡潔、有効、一貫性があり、曖昧でないかどうかを判断し、明らかな矛盾を解決します。分析には、要件のサイズ設定も含まれる場合があります。

要件分析は、多くの繊細な心理的スキルが関わる、長くて疲れるプロセスになることがあります。新しいシステムは環境と人々の関係を変えるので、すべての利害関係者を特定し、彼らのすべてのニーズを考慮し、新しいシステムの影響を彼らが理解していることを確認することが重要です。アナリストは、顧客から要件を引き出すためにいくつかの手法を使用できます。これらには、シナリオの開発（アジャイル手法ではユーザーストーリーとして表される）、ユースケースの特定、職場観察または民族誌の使用、インタビューまたはフォーカスグループの開催（この文脈では、要件ワークショップまたは要件レビューセッションと呼ぶ方が適切です）、要件リストの作成が含まれます。プロトタイプ作成は、利害関係者にデモンストレーションできるサンプルシステムを開発するために使用できます。必要に応じて、アナリストはこれらの方法を組み合わせて利害関係者の正確な要件を確立し、ビジネスニーズを満たすシステムを作成します。^{[5] [6]}要件の品質は、これらの方法やその他の方法によって向上できます。

• 視覚化。視覚化やシミュレーションなど、目的の最終製品に対する理解を深めるツールを使用します。
• テンプレートの一貫した使用。要件を文書化するために一貫したモデルとテンプレートのセットを作成します。
• 依存関係の文書化。要件間の依存関係と相互関係、および仮定と集合を文書化します。

システムに正当な関心を持つ個人または組織 (企業などの法人や標準化団体) については、 「利害関係者の分析」を参照してください。これらの個人または組織は、システムによって直接的または間接的に影響を受ける可能性があります。

1990 年代に新たに重視されたのは、利害関係者の特定です。利害関係者はアナリストを雇用している組織に限定されないことが、ますます認識されるようになっています。その他の利害関係者には、次のような人々が含まれます。

• システムを操作する人（通常オペレーターと保守オペレーター）
• システムから利益を得る人（機能的、政治的、経済的、社会的受益者）
• システムの購入または調達に関わるすべての人。大量市場向け製品を扱う組織では、製品管理、マーケティング、場合によっては営業が代理消費者（大量市場顧客）として機能し、製品の開発を指導します。
• システムの側面を規制する組織（金融、安全、その他の規制機関）
• システムに反対する人々または組織（否定的な利害関係者。誤用事例も参照）
• 設計中のシステムとインターフェースするシステムを担当する組織。
• アナリストがシステムを設計している組織と水平に統合される組織。

要件には、個々の利害関係者にはわからない部門横断的な影響が伴うことが多く、利害関係者へのインタビュー中に見落とされたり、不完全に定義されたりすることがよくあります。これらの部門横断的な影響は、訓練を受けたファシリテーター(ビジネス アナリスト) が進行役を務める制御された環境で JRD セッションを実施することで引き出すことができます。このセッションでは、利害関係者が議論に参加して要件を引き出し、その詳細を分析し、部門横断的な影響を明らかにします。議論を文書化するために専任の記録係が同席し、ビジネス アナリストがセッションの目的を満たす適切な要件を生成する方向に議論を導くことができるようにする必要があります。

JRD セッションは、共同アプリケーション設計セッションに似ています。前者では、セッションで設計を導く要件を引き出し、後者では、引き出した要件を満たすために実装する特定の設計機能を引き出します。

要件を文書化する従来の方法の 1 つは、契約形式の要件リストです。複雑なシステムでは、このような要件リストは数百ページに及ぶことがあります。

適切な比喩としては、非常に長い買い物リストが挙げられます。このようなリストは、目的を達成するのに見事に失敗することが証明されているため、現代の分析では非常に好まれません^[要出典]が、今日でもまだ見られます。

• 要件のチェックリストを提供します。
• プロジェクトスポンサーと開発者間の契約書を提供します。
• 大規模システムの場合、高レベルの説明を提供して、そこから低レベルの要件を導き出すことができます。

• このようなリストは数百ページに及ぶことがあります。これらは、目的のアプリケーションについて読みやすい説明を提供することを目的としたものではありません。
• このような要件リストはすべての要件を抽象化するため、コンテキストはほとんどありません。ビジネス アナリストは、付随する設計ドキュメントに要件のコンテキストを含めることがあります。
  • この抽象化は、要件がどのように適合するか、または連携して動作するかを説明することを目的としたものではありません。
  • リストには、要件間の関係や依存関係が反映されない場合があります。リストを使用すると、各項目の優先順位付けが容易になりますが、コンテキストから外れた項目を 1 つ削除すると、ユース ケース全体またはビジネス要件が役に立たなくなる可能性があります。
  • このリストは、望ましいシステム/アプリケーションの設計への影響についてよりよく理解を共有するために、利害関係者と要件を慎重に検討する必要性を置き換えるものではありません。
• リストを作成しただけでは、その完全性が保証されるわけではありません。ビジネス アナリストは、実質的に包括的なリストを発見して収集するために誠意を持って努力し、不足している要件を関係者に指摘してもらう必要があります。
• これらのリストは、利害関係者と開発者の間で誤った相互理解を生み出す可能性があります。ビジネスアナリストは、翻訳プロセスに不可欠です。
• 開発とテストのプロセスが始まる前に、すべての機能要件を明らかにすることはほぼ不可能です。これらのリストが不変の契約として扱われると、開発プロセスで発生する要件によって、議論の余地のある変更要求が発生する可能性があります。

アジャイル ソフトウェア開発では、要件リストの代わりに、ユーザー ストーリーを使用して日常的な言語で要件を提案します。

ベスト プラクティスでは、要件の構成されたリストを単なる手がかりとして捉え、実際のビジネス目的が明らかになるまで「なぜ?」と繰り返し問いかけます。その後、関係者と開発者は、各目標がこれまでにどの程度達成されたかを測定するテストを考案できます。このような目標は、具体的だが測定されていない要件の長いリストよりもゆっくりと変化します。重要な測定済み目標の小セットが確立されると、迅速なプロトタイピングと短い反復開発フェーズが進行し、プロジェクトの半分が終わるずっと前に、関係者に実際の価値を提供できるようになります。

プロトタイプは、別のコンピュータ プログラムの特性の一部を示すコンピュータ プログラムであり、ユーザーがまだ構築されていないアプリケーションを視覚化できるようにします。プロトタイプの一般的な形式はモックアップで、将来のユーザーやその他の関係者がシステムがどのように見えるかを把握するのに役立ちます。プロトタイプを使用すると、アプリケーションを構築する前にアプリケーションの側面を確認して共有できるため、設計上の決定が容易になります。プロトタイプの導入により、ユーザーと開発者間のコミュニケーションが大幅に改善されることがよくありました。アプリケーションの早期のビューにより、後で変更する必要が少なくなり、全体的なコストが大幅に削減されました。^{[引用が必要]}

プロトタイプは、平面図 (ワイヤーフレームと呼ばれることが多い) や、合成された機能を使用した実用的なアプリケーションです。ワイヤーフレームはさまざまなグラフィック デザイン ドキュメントで作成され、最終的なソフトウェアにグラフィック デザインを適用することが予想される場合は、デザインからすべての色を削除することがよくあります (つまり、グレースケール カラー パレットを使用します)。これにより、プロトタイプがアプリケーションの最終的な外観と操作感を表しているかどうかの混乱を防ぐことができます。^{[引用が必要]}

ユースケースとは、通常はソフトウェアを含むシステムの機能要件を文書化するための構造であり、新規または変更されるソフトウェアを含みます。各ユースケースは、特定のビジネス目標を達成するために、システムが人間のユーザーまたは別のシステムとどのように対話すべきかを伝える一連のシナリオを提供します。ユースケースでは通常、専門用語を避け、代わりにエンドユーザーまたはドメインの専門家の言語を好みます。ユースケースは、多くの場合、要件エンジニアと利害関係者が共同で作成します。

ユースケースは、ソフトウェアやシステムの動作を説明する、一見単純なツールです。ユースケースには、ユーザーがソフトウェアやシステムをどのように操作するかをテキストで説明します。ユースケースでは、システムの内部動作を説明したり、そのシステムの実装方法を説明してはいけません。代わりに、連続した仮定なしにタスクを実行するために必要な手順を示します。

要件仕様は、現在のビジネス ニーズに関する発見事項と、これらのニーズの評価を統合して、焦点を当てているソリューション スコープ内でニーズを満たすために何が必要かを決定し、指定することです。発見、分析、および仕様により、理解は現在の現状から将来のあるべき状態に移行します。要件仕様は、実現される将来の状態の全範囲と深さをカバーすることも、優先的に修正するソフトウェア システムのバグや行うべき機能強化など、埋めるべき特定のギャップを対象にすることもできます。大規模なビジネス プロセスでは、ほとんどの場合、ソフトウェアおよびデータ システムとテクノロジが採用されているため、要件仕様は、ソフトウェア システムの構築、購入、クラウド コンピューティング戦略、製品またはデバイスに組み込まれたソフトウェア、またはその他のテクノロジに関連付けられることがよくあります。要件仕様のより広い定義には、トレーニング、ドキュメント ガイド、人員、マーケティング戦略、機器、サプライなど、あらゆるソリューション戦略またはコンポーネントが含まれるか、それらに焦点を当てています。

要件はいくつかの方法で分類されます。以下は技術管理に関連する要件の一般的な分類です。^[1]

詳細な機能には言及しない、ビジネス レベルの目標の記述。これらは通常、ビジネス成果を達成するために必要な高レベル (ソフトウェアおよび/またはハードウェア) の機能です。

システムの期待をミッション目標、環境、制約、有効性と適合性の尺度 (MOE/MOS) の観点から定義する事実と仮定の記述。顧客とは、システム エンジニアリングの 8 つの主要機能を実行する人々であり、特に主要顧客であるオペレータに重点​​が置かれます。運用要件は基本的なニーズを定義し、少なくとも次のリストに提示された質問に答えます。^[1]

• 運用の配布または展開: システムはどこで使用されますか?
• ミッション プロファイルまたはシナリオ: システムはどのようにしてミッションの目的を達成するのでしょうか?
• パフォーマンスと関連パラメータ: ミッションを達成するために重要なシステムパラメータは何ですか?
• 利用環境：各システムコンポーネントはどのように使用されるのか？
• 有効性要件: システムはそのミッションを遂行する上でどの程度効果的または効率的である必要がありますか?
• 運用ライフサイクル: ユーザーはどのくらいの期間システムを使用するのでしょうか?
• 環境: システムが効果的に動作することが期待される環境は何ですか?

アーキテクチャ要件は、システムの必要なシステム アーキテクチャを特定することによって、何を実行する必要があるかを説明します。

動作要件は、システムの 必要な動作を特定することによって、何を実行する必要があるかを説明します。

機能要件は、達成しなければならない必要なタスク、アクション、またはアクティビティを特定することによって、何を行う必要があるかを説明します。機能要件分析は、機能分析のトップレベル機能として使用されます。^[1]

非機能要件は、特定の動作ではなく、システムの動作を判断するために使用できる基準を指定する要件です。

ミッションまたは機能を実行する必要がある範囲。通常は、量、品質、範囲、適時性、または準備状況の観点から測定されます。要件分析では、システムライフサイクル要因に基づいて、特定されたすべての機能にわたってパフォーマンス要件（どの程度うまく実行する必要があるか）が対話的に開発され、見積もりの​​確実性、システムの成功に対する重要度、および他の要件との関係の観点から特徴付けられます。^[1]

製品の「構築」、「コーディング」、「購入」要件とプロセスの「実行方法」要件は、技術データパッケージと技術マニュアルで表現されます。^[1]

上位レベルの要件から暗示される、または変換される要件。たとえば、長距離または高速の要件は、軽量の設計要件につながる可能性があります。^[1]

要件は、高レベルの要件を複数の低レベルの要件に分割または割り当てることによって確立されます。例: 2 つのサブシステムで構成される 100 ポンドのアイテムの場合、2 つの低レベルのアイテムの重量要件は 70 ポンドと 30 ポンドになる可能性があります。^[1]

よく知られている要件分類モデルには、Hewlett-Packardで開発されたFURPSと FURPS+があります。

Steve McConnell は、著書「Rapid Development」の中で、ユーザーが要件収集を阻害するさまざまな方法について詳しく説明しています。

• ユーザーが何を望んでいるのか理解していない、またはユーザーが自分の要件を明確に把握していない
• ユーザーは書面による要件セットにコミットしない
• コストとスケジュールが決まった後も、ユーザーは新たな要件を要求する
• ユーザーとのコミュニケーションが遅い
• ユーザーはレビューに参加しない、または参加することができないことが多い
• ユーザーは技術的に未熟である
• ユーザーは開発プロセスを理解していない
• ユーザーは現在の技術を知らない

これにより、システムや製品の開発が開始された後でも、ユーザーの要件が変化し続けるという状況が発生する可能性があります。

要件分析中にエンジニアや開発者が引き起こす可能性のある問題は次のとおりです。

• コードを書くことへの自然な傾向により、要件分析が完了する前に実装が開始され、実際の要件が判明した時点でそれを満たすためにコードが変更される可能性があります。
• 技術者とエンドユーザーの語彙が異なる場合があり、その結果、完成品が提供されるまでは両者が完全に一致していると誤って信じてしまう可能性があります。
• エンジニアや開発者は、クライアントのニーズに特化したシステムを開発するのではなく、既存のシステムやモデルに要件を適合させようとする場合があります。

コミュニケーションの問題に対する解決策の 1 つは、ビジネス分析またはシステム分析の専門家を雇うことです。

1990 年代に導入されたプロトタイピング、統一モデリング言語(UML)、ユースケース、アジャイル ソフトウェア開発などの手法も、以前の方法で発生した問題の解決策として意図されています。

また、新しいクラスのアプリケーション シミュレーションツールやアプリケーション定義ツールも市場に登場しています。これらのツールは、ビジネス ユーザーと IT 組織間のコミュニケーション ギャップを埋めるように設計されています。また、コードを作成する前にアプリケーションを「テスト マーケティング」できるようにもなっています。これらのツールの最も優れた機能は次のとおりです。

• アプリケーションフローをスケッチし、代替案をテストするための電子ホワイトボード
• ビジネスロジックとデータニーズを把握する能力
• 最終的なアプリケーションを忠実に模倣した高忠実度のプロトタイプを生成する能力
• インタラクティブ性
• コンテキスト要件やその他のコメントを追加する機能
• リモートおよび分散ユーザーがシミュレーションを実行し、対話する機能

^[1]

ウィキメディア・コモンズには、要件分析に関連するメディアがあります。

• 要件エンジニアリングと分析に関する査読済み百科事典のエントリ
• 国防調達大学のステークホルダー要件定義プロセス^{[リンク切れ‍ ]} --- Wayback Machineのステークホルダー要件定義プロセス(2015 年 12 月 23 日アーカイブ)
• MIL-HDBK 520 システム要件ドキュメントガイダンス