要件の収集 – 適切なツールの選択

このセクションの目的は、利用可能なさまざまな要件収集ツールと、プロジェクトに使用するツールを選択する際に考慮する必要がある要因についての洞察を提供することです。 これらのツールを使いこなせるようになる前に、これらのツールの使用に関するトレーニングを受ける必要があります。

プロジェクトが提供するソフトウェア アプリケーションまたは Web サイトの性質は、どの要件収集ツールを使用するかの決定に影響します。 決定に影響を与えるその他の要因は、ビジネス ユーザーの数と種類、顧客サービス担当者、および保守担当者とその場所です。 このセクションでは、利用可能なツールのいくつかについて説明し、それらを使用するのに適した状況について説明します。

契約書または作業明細書

組織がアプリケーションの開発を外部のベンダーと契約している場合は、アプリケーションまたは Web サイトが持つ特徴と機能を大まかに規定した契約を結ぶことになります。 契約書に作業明細書 (SOW) が添付されている場合は、特徴と機能がより詳細に説明されている場合があります。 契約書または SOW のステートメントを要件に絞り込むためにやるべき作業はまだありますが、それらを使用して、要件定義が維持されなければならない境界を定義する必要があります。

ブレーンストーミング

ブレインストーミングは、考えやアイデアを募るためにおそらく最も一般的に使用されるツールです。 これは、参加者が 1 つの部屋に集まってうまく機能する必要がある手法です (少なくとも、音声またはビデオ会議によるブレインストーミングで成功した人は聞いたことがありません)。 また、参加者が議論されている問題または解決策について共通の理解を持っていることにも依存しています。

ブレーンストーミング セッションでは、アイデアの量に焦点を当てる必要があるため、セッションの全員が発言しやすい雰囲気を醸成する必要があります。 セッションで提起されたアイデアの一部が実現不可能である場合、または契約または SOW でカバーされていない場合、今はそれらを軽視する時ではありません。 創造性を発揮しましょう。 セッションを設定するには、人々がセッションに到着する前に、創造的な思考を引き起こす問題を説明する必要があります。 ブレーンストーミングを行うグループごとに問題ステートメントが必要です。プロジェクトに契約または SOW がある場合は、これらに基づいて問題ステートメントを作成する必要があります。

互いに親和性のあるアイデアや要件を組み合わせるようにチームを奨励する必要があります。10 の異なる要件で同じ機能や機能を捉えても意味がありません。 演習の最後のステップは、目的にカーディナル スコアまたは序数スコアを使用して、機能に優先順位を付けることです。 これは、開発を利用可能な予算に合わせるときに、どの要件を最初に放り出す必要があるかがわかるようにするためです。 これを達成するために、ノミナル グループ テクニックと呼ばれるブレインストーミングのバリエーションを試すことができます。

ブレーンストーミングとノミナル グループ テクニックは、新しいアプリケーション/Web サイトに対して同じニーズを持つ複数の人々を部屋に集めて、彼らの創造性が互いに刺激し合うことができる場合に適しています。 チーム全員がアプリケーションで同じ作業を実行する場合、または少なくとも互いのアプリケーションの使用法に精通している場合に使用できます。 また、複数の異なる機能グループ (販売、顧客サービス、サポートなど) がある場合にも使用できるため、機能グループごとに 1 つのブレインストーミング セッションを実施できます。 ブレーンストーミングは、ニーズが異なる利害関係者の小さなグループがある場合、または利害関係者が地理的に分散している場合には適切ではありません。

面接

インタビューでは、利害関係者と 1 対 1 で面会し、焦点を絞った質問をすることができます。これにより、インタビュー中に引き出された要件が明確になり、利害関係者のニーズに適切に対応できるようになります。 利害関係者のニーズの性質と、要件を満たすための機能を開発するコストを熟知している場合、インタビュー手法を使用すると、壮大な要件の範囲を広げることもできます。 開発に必要な時間と労力のために、規定された要件が実現不可能であると判断した場合は、利害関係者に「….それを行うためのより簡単な方法はありますか?」または「…. x、y、z はその必要性を満たしましたか?」

分析、同様の要件の組み合わせ、要件の契約または SOW への調整はお客様が行い、その結果を面接対象者にフィードバックする必要があります。

この方法は、要件を求める対象となる異種の利害関係者のグループが比較的小さい場合に使用できます。 この方法の利点は、与えられた要件を制御できること、期待に影響を与えることができること、および要件を正確に把握できることです。 多数の利害関係者に依頼するプロジェクトには適していません。

共同アプリケーション開発 (JAD)

JAD はワークショップを使用して、ブレインストーミングのように利害関係者から要件を求めます。 ただし、重要な違いがいくつかあります。主な違いは、要件収集プロセスにシステム アナリストが関与することです。 ワークショップでは、ファシリテーターが議論を軌道に乗せ、要件を収集するタスクにチームの努力を集中させる必要があり、要件を記録するレコーダーが必要です (これはブレインストーミングに似ています)。 ワークショップにアナリストが関与することで、収集された要件が実行可能になり、開発時間や労力の点で不当なコストがかからないことが保証されます。 ワークショップにアナリストがいることのもう 1 つの利点は、より少ないコストで同じニーズに対応できる代替案を提供できることです。

JAD は、ブレインストーミングが適切であり、ブレインストーミングと同様に、チームを同じ場所に配置する必要があるのと同じ状況で機能します。

調査 調査は、調査がリモートで実行できることを除いて、インタビューと同じアプローチです。 要請された利害関係者がプロジェクトのニーズを表明できるようにするために必要な情報は、彼らが知的に対応できるように、十分なリード タイムで伝達する必要があります。 予定された終了日までに回答を確実に受け取るには、回答期限を指定する必要があります。また、回答の分析、照合、調整を自分で行う必要があります。 調査では、調査の結果を利害関係者に伝える必要もあります (インタビュー手法と同様)。

この手法は、要請された利害関係者グループが地理的に分散している場合、または要請された利害関係者の数が多すぎてインタビュー手法を使用できない場合に適しています。 調査手法を使用すると、インタビューに伴うオーバーヘッドなしで、多数の利害関係者から要件を収集できます。 注意: この方法である程度の成功を収めるには、利害関係者に彼らの反応の重要性を印象付ける必要があります。

絵コンテ

ストーリーボードは、要件をテキストではなくグラフィカルに表示する手段です。 この技術は、漫画制作で最初に使用されたエンターテイメント業界から借りています。

ストーリーボードを使用して要件をキャプチャするには、レコーダがイーゼルまたはホワイト ボードに画面を描画する必要があります。 画面には、画面に表示されるすべての情報と、情報を収集するために必要な入力フィールドが含まれます。 ストーリーボードは、ファシリテーターとレコーダーがいるワークショップの設定で使用されます。 ファシリテーターとレコーダーは、最初の主要なニーズを表現するための画面を作成して、セッションを開始します。 これは、ログイン画面、または基本的な機能をキャプチャするその他の画面である可能性があります。 元の画面は、機能を完了するために後続の画面をトリガーする場合があります。 たとえば、最初の注文入力画面は、すべての注文に共通の情報をキャプチャし、後続の画面では、さまざまなタイプの注文に固有の情報をキャプチャする必要があります。たとえば、ソフトウェアの注文、コンピュータの注文、および操作マニュアルの注文ごとに 1 つの画面です。 . ストーリーボードは、グループが各機能または要件をナビゲートするときに画面を作成します。

ストーリーボードは各画面のいくつかの状態しかキャプチャできないため、レコーダが各画面のさまざまな状態と、さまざまな入力時の画面の動作 (エラーの処理方法、入力情報の検証方法など) をキャプチャすることが重要です。 .)。

ストーリーボードの利点の 1 つは、アプリケーションの重要な機能となる画面を定義し、各画面のルック アンド フィールのグループ設定で合意を得られることです。 この方法は、開発中のアプリケーションが GUI ベースの場合、または Web サイトに適しています。 ワークショップに参加できるように、勧誘されている利害関係者が同じ場所にいることも適切です。 利害関係者が地理的に分散している場合や、開発中のアプリケーションが GUI ベースでない場合は適切ではありません。

Leave a Comment

Your email address will not be published. Required fields are marked *