Loading article…
システムエンジニアリングとソフトウェアエンジニアリングでは、要求分析は、さまざまな利害関係者の相反する可能性のある要求を考慮に入れ、ソフトウェアまたはシステムの要求を分析、文書化、検証、管理して、新しいまたは変更された製品またはプロジェクトを満たすためのニーズまたは条件を決定するタスクに焦点を当てています。[ 2 ]
要件分析は、システムやソフトウェアプロジェクトの成否に大きく影響します。[ 3 ]要件は文書化され、実行可能で、測定可能で、テスト可能で、[ 4 ]追跡可能で、[ 4 ]特定されたビジネスニーズや機会に関連しており、システム設計に十分な詳細レベルで定義されている必要があります。
概念的に、要求分析には3種類の活動が含まれます。
要件分析は、多くの繊細な心理的スキルが関わる、長くて骨の折れるプロセスになる可能性があります。新しいシステムは環境と人々の間の関係を変えるため、すべての利害関係者を特定し、彼らのすべてのニーズを考慮に入れ、新しいシステムの影響を理解してもらうことが重要です。アナリストは、顧客から要件を引き出すためにいくつかの手法を用いることができます。これには、シナリオの開発（アジャイル手法ではユーザーストーリーとして表現される）、ユースケースの特定、職場観察またはエスノグラフィーの使用、インタビューの実施、フォーカスグループ（この文脈では要件ワークショップまたは要件レビューセッションと呼ばれる方が適切）の実施、要件リストの作成などが含まれます。プロトタイピングを使用して、利害関係者にデモンストレーションできるサンプルシステムを開発することができます。必要に応じて、アナリストはこれらの方法を組み合わせて利害関係者の正確な要件を確立し、ビジネスニーズを満たすシステムを作成します。[ 5 ] [ 6 ]要件の品質は、これらの方法やその他の方法によって向上させることができます。
利害関係者分析の項では、システムに正当な利害関係を持つ個人または組織（企業などの法人、標準化団体など）について説明しています。これらの個人または組織は、システムによって直接的または間接的に影響を受ける可能性があります。
1990年代における新たな重要な重点事項の一つは、ステークホルダーの特定に焦点を当てることであった。ステークホルダーはアナリストを雇用する組織に限らないことがますます認識されるようになってきている。その他のステークホルダーには以下が含まれる。
要件には、個々のステークホルダーには認識されていない、部門横断的な影響が伴うことが多く、ステークホルダーへのインタビューでも見落とされたり、不完全にしか定義されなかったりすることがよくあります。こうした部門横断的な影響は、訓練を受けたファシリテーター（ビジネスアナリスト）が進行役を務める管理された環境でJRDセッションを実施することで明らかにすることができます。このセッションでは、ステークホルダーが議論に参加し、要件を引き出し、その詳細を分析し、部門横断的な影響を明らかにします。議論の内容を記録する専任の記録係を配置することで、ビジネスアナリストはセッションの目的に合致する適切な要件を生み出す方向に議論を導くことができます。
JRDセッションは、共同アプリケーション設計セッションに類似しています。前者は設計の指針となる要件を引き出すセッションであり、後者は引き出された要件を満たすために実装すべき具体的な設計機能を引き出すセッションです。
要件を文書化する従来の方法の一つに、契約書形式の要件リストがあります。複雑なシステムの場合、このような要件リストは数百ページにも及ぶことがあります。
適切な比喩としては、非常に長い買い物リストが挙げられるだろう。こうしたリストは、その目的を達成する上で著しく失敗してきたため、現代の分析においてはほとんど好まれていないが、今日でもなお見られることがある。
要件リストの代替手段として、アジャイルソフトウェア開発では、日常的な言葉で要件を提示するためにユーザーストーリーを使用します。
ベストプラクティスでは、要件リストはあくまで手がかりとして捉え、「なぜ？」と繰り返し問いかけ、真のビジネス目的を突き止めます。その後、関係者と開発者は、各目標がどの程度達成されたかを測定するためのテストを考案できます。こうした目標は、具体的ではあるものの測定不可能な要件の長いリストよりも変化が緩やかです。重要かつ測定可能な目標が少数確立されれば、迅速なプロトタイピングと短い反復開発フェーズを経て、プロジェクトが半分も終わらないうちに、関係者にとって真の価値を提供できるようになります。
プロトタイプとは、別のコンピュータプログラムの特性の一部を示すコンピュータプログラムであり、ユーザーがまだ構築されていないアプリケーションを視覚的に確認できるようにするものです。プロトタイプの代表的な形式はモックアップで、将来のユーザーやその他の関係者がシステムの外観を把握するのに役立ちます。プロトタイプを使用することで、アプリケーションの構築前にアプリケーションの様々な側面を確認・共有できるため、設計上の意思決定が容易になります。プロトタイプの導入により、ユーザーと開発者間のコミュニケーションが大幅に改善されることがよくありました。アプリケーションを早期に確認することで、後々の変更が少なくなり、結果として全体的なコストを大幅に削減することができました。
プロトタイプは、平面図（ワイヤーフレームと呼ばれることが多い）または合成機能を使用した動作可能なアプリケーションのいずれかです。ワイヤーフレームはさまざまなグラフィックデザイン文書で作成され、最終的なソフトウェアにグラフィックデザインが適用されることが想定されている場合は、デザインからすべての色を削除する（つまり、グレースケールのカラーパレットを使用する）ことがよくあります。これは、プロトタイプがアプリケーションの最終的な視覚的な外観と操作感を表しているかどうかについての混乱を防ぐのに役立ちます。
ユースケースとは、システム（通常はソフトウェア）の機能要件を文書化するための構造であり、新規開発か既存システムの変更かを問わず適用されます。各ユースケースは、特定のビジネス目標を達成するために、システムが人間ユーザーまたは他のシステムとどのように連携すべきかを示す一連のシナリオを提供します。ユースケースでは、通常、専門用語を避け、エンドユーザーやドメインエキスパートが理解できる言葉遣いが用いられます。ユースケースは、要件エンジニアとステークホルダーが共同で作成することがよくあります。
ユースケースは、ソフトウェアやシステムの動作を記述するための、一見シンプルなツールです。ユースケースには、ユーザーがソフトウェアやシステムをどのように操作することを想定しているかをテキストで記述します。ユースケースは、システムの内部動作を記述したり、システムの実装方法を説明したりするものではありません。むしろ、順序に関する前提条件なしに、タスクを実行するために必要な手順を示すものです。
要件仕様とは、現状のビジネスニーズに関する発見事項を統合し、これらのニーズを評価して、対象となるソリューションの範囲内でニーズを満たすために必要なものを決定し、具体的に示すことです。発見、分析、仕様策定によって、現状の状態から将来のあるべき状態へと理解が進みます。要件仕様は、実現すべき将来の状態の全範囲を網羅することも、優先的に修正すべきソフトウェアシステムのバグや改善点など、埋めるべき特定のギャップに焦点を当てることもできます。大規模なビジネスプロセスではほぼ必ずソフトウェアやデータシステム、テクノロジーが利用されるため、要件仕様はソフトウェアシステムの構築、購入、クラウドコンピューティング戦略、製品やデバイスに組み込まれたソフトウェア、その他のテクノロジーと関連付けられることがよくあります。要件仕様のより広い定義では、トレーニング、ドキュメントガイド、人員、マーケティング戦略、機器、消耗品など、あらゆるソリューション戦略やコンポーネントが含まれるか、それらに焦点を当てます。
要件はいくつかの方法で分類されます。以下は、技術管理に関連する要件の一般的な分類です。[ 1 ]
詳細な機能には言及せず、ビジネスレベルの目標を記述したもの。これらは通常、ビジネス成果を達成するために必要な高レベルの（ソフトウェアおよび／またはハードウェア）機能である。
ミッション目標、環境、制約、有効性および適合性の尺度 (MOE/MOS) の観点からシステムの期待を定義する事実および仮定の記述。顧客は、システムエンジニアリングの 8 つの主要機能を実行する者であり、特にオペレーターが主要顧客として重視されます。運用要件は基本的なニーズを定義し、少なくとも次のリストで提示された質問に答えます。[ 1 ]
アーキテクチャ要件とは、システムの必要なシステムアーキテクチャを特定することによって、何を行う必要があるかを説明するものです。
動作要件とは、システムの必要な動作を特定することによって、何を行う必要があるかを説明するものです。
機能要件は、達成しなければならない必要なタスク、アクション、またはアクティビティを特定することによって、何を行う必要があるかを説明します。機能要件分析は、機能分析の最上位機能として使用されます。[ 1 ]
非機能要件とは、具体的な動作ではなく、システムの動作を評価するために使用できる基準を規定する要件のことです。
任務や機能がどの程度実行される必要があるかは、一般的に量、質、網羅性、適時性、または準備状況の観点から測定されます。要件分析では、システムライフサイクル要因に基づいて、特定されたすべての機能にわたってパフォーマンス（どの程度うまく実行する必要があるか）要件がインタラクティブに開発され、その見積もりの確実性の度合い、システムの成功に対する重要度の度合い、および他の要件との関係によって特徴付けられます。[ 1 ]
製品の「製造要件」、「コード要件」、「購入要件」、およびプロセスの「実行方法要件」は、技術データパッケージおよび技術マニュアルに表現されます。[ 1 ]
上位レベルの要求から暗黙的に導き出されたり、変換されたりした要求。例えば、長距離飛行や高速飛行の要求は、軽量化の設計要求につながる可能性がある。[ 1 ]
要件は、上位レベルの要件を複数の下位レベルの要件に分割または割り当てることによって確立されます。例：2つのサブシステムで構成される100ポンドのアイテムの場合、2つの下位レベルのアイテムの重量要件は70ポンドと30ポンドになる可能性があります。[ 1 ]
よく知られている要件分類モデルには、ヒューレット・パッカード社で開発されたFURPSおよびFURPS+がある。
スティーブ・マコーネルは著書『ラピッド・デベロップメント』の中で、ユーザーが要件収集を阻害するいくつかの方法を詳しく述べている。
これは、システムや製品の開発が開始された後でも、ユーザーの要求が絶えず変化する状況につながる可能性がある。
要件分析中にエンジニアや開発者が引き起こす可能性のある問題点は以下のとおりです。
コミュニケーション上の問題に対する解決策の一つとして、ビジネス分析やシステム分析の専門家を雇用するという試みがなされてきた。
1990年代に導入されたプロトタイピング、統一モデリング言語（UML）、ユースケース、アジャイルソフトウェア開発といった手法も、従来の手法で発生した問題に対する解決策として意図されたものである。
また、アプリケーションシミュレーションツールやアプリケーション定義ツールといった新しいタイプのツールが市場に登場しました。これらのツールは、ビジネスユーザーとIT部門間のコミュニケーションギャップを埋め、コードを作成する前にアプリケーションを「テストマーケティング」できるように設計されています。これらのツールの中でも特に優れたものは、以下の機能を提供します。
ソフトウェア業界では、これらの活動が適切に行われない場合、ソフトウェアエンジニアリングプロジェクトが極めて脆弱になることが広く認識されています。