Business-analysis-requirement-gathering-techniques

提供:Dev Guides
移動先:案内検索

要件収集テクニック

テクニックは、特定の状況でタスクが実行される方法を説明します。 タスクには、関連する手法がない場合もあれば、1つ以上ある場合もあります。 テクニックは、少なくとも1つのタスクに関連している必要があります。

以下は、よく知られている要件収集手法の一部です-

ブレーンストーミング

ブレインストーミングは、要件の収集に使用され、人々のグループからできるだけ多くのアイデアを取得します。 通常、問題の可能な解決策を特定し、機会の詳細を明確にするために使用されます。

文書分析

既存のシステムのドキュメントを確認することは、AS–ISプロセスドキュメントを作成するときに役立ち、移行プロジェクトの範囲を特定するためのギャップ分析を促進するのに役立ちます。 理想的な世界では、現在の要件を文書化するための出発点である、既存のシステムの作成を推進した要件を検討することさえあります。 情報のナゲットは、要件の完全性を検証する一環として質問をするのに役立つ既存のドキュメントに埋もれていることがよくあります。

フォーカスグループ

フォーカスグループは、フィードバックを得るために製品のユーザーまたは顧客を代表する人々の集まりです。 ニーズ/機会/問題についてのフィードバックを収集して要件を特定するか、既に導出された要件を検証および改善するために収集できます。 この形式の市場調査は、特定の参加者による管理されたプロセスであるという点で、ブレインストーミングとは異なります。

インターフェース解析

ソフトウェア製品のインターフェースは、人間でも機械でもかまいません。 外部システムおよび外部デバイスとの統合は、もう1つのインターフェイスです。 ユーザー中心の設計アプローチは、使用可能なソフトウェアを確実に作成するのに非常に効果的です。 インターフェース分析-他の外部システムとの接点を確認することは、ユーザーにすぐに見えない要件を見逃さないために重要です。

インタビュー

すばらしいソフトウェアを作成するには、利害関係者とユーザーのインタビューが不可欠です。 ユーザーと利害関係者の目標と期待を理解しなければ、それらを満足させることはほとんどありません。 また、各インタビュー対象者の視点を認識して、入力を適切に評価し、対処できるようにする必要があります。 リスニングは、優れたアナリストが一般的なアナリストよりもインタビューからより多くの価値を得るのに役立つスキルです。

観察

ユーザーを観察することで、アナリストはプロセスフロー、手順、問題点、改善の機会を特定できます。 観察は受動的でも能動的でもよい(観察中に質問をする)。 受動的観察は、(要件を改善するために)プロトタイプに関するフィードバックを得るのに適しています。ここで、能動的観察は既存のビジネスプロセスの理解を得るのにより効果的です。 どちらのアプローチも使用できます。

プロトタイピング

プロトタイピングは、要件を収集するための比較的現代的な手法です。 このアプローチでは、ソリューションの初期バージョン(プロトタイプ)を構築するために使用する予備要件を収集します。 これをクライアントに提示すると、クライアントは追加の要件を提示します。 アプリケーションを変更し、クライアントを再度使用します。 この反復プロセスは、製品がビジネスニーズのクリティカルマスを満たすか、合意された反復回数まで続きます。

要件ワークショップ

ワークショップは、要件の収集に非常に効果的です。 ブレインストーミングセッションよりも構造化された関係者が協力して要件を文書化します。 コラボレーションをキャプチャする1つの方法は、ドメインモデルアーティファクト(静的ダイアグラム、アクティビティダイアグラムなど)の作成です。 ワークショップは、1人よりも2人のアナリストの方が効果的です。

リバースエンジニアリング

移行プロジェクトが既存のシステムの十分なドキュメントにアクセスできない場合、リバースエンジニアリングはシステムの動作を識別します。 システムが何をすべきかを特定できず、システムがいつ間違ったことをするかを特定しません。

調査/アンケート

多くの人から情報を収集する場合(多すぎて予算や時間の制約についてインタビューできない場合)、調査またはアンケートを使用できます。 調査では、ユーザーに選択肢からの選択、何かの評価(「強く同意する、同意する…​」)、または自由形式の回答を可能にする自由回答形式の質問を強制することができます。 調査の設計は困難です。質問は回答者を偏らせる可能性があります。