スポンサーやエンドユーザーからプロジェクト要件を収集せずに新しいプロジェクトを開始する場合は、失敗に備えて自分自身を設定しています。 プロジェクトは肯定的な結果を提供し、係争物受寄者の予想を満たすとき巧妙である。 あなたのプロジェクトがプロジェクトとユーザーの期待を満たしていない場合、それはあなたが完了したか、予算内でそれを維持したどのくらいの速さに関係なく、失敗していません。

たとえば、新しいモバイルアプリを作成するためにプロジェクトをリードしているとします。 プロジェクトの要件を収集し、開発者、プロダクトマネージャー、クリエイティブのチームをまとめます。 しかし、起動後、ユーザーはアプリのインターフェイスについて不平を言う。 彼らは何かを成し遂げるためにアプリをナビゲートすることができません。

あなたのチームは、プロジェクトスポンサーから集められたすべてのプロジェクト要件を満たすことに集中していたことが判明しました。

あなたのチームは機能するアプリを提供しましたが、ユーザーの期待に応えられませんでした。 幸いなことに、新しいプロジェクトを開始する前に、利害関係者の要件を特定、分析、検証することで、このような結果を回避できます。 これが要件分析の出番です。

要件分析とは何ですか？

要件分析には、すべての可能性のある競合を考慮しながら、新しいプロジェクトに対する利害関係者の期待を定義、分析、検証、調整することが含まれ

プロジェクト要件を特定、分析、管理して、プロジェクトが何を達成すべきかを決定し、プロジェクト計画のあいまいさや矛盾する要件を排除するプ

要件分析プロセスを実行するとき、受け入れられた要件は次のとおりでなければならないことに注意してくださ:

• 文書化された
• 実用的な
• 測定可能な
• テスト可能な
• トレーサブルな
• 十分な詳細で定義された
• 全体的なビジネスニーズに関連する

要件分析はいつ

通常、プロジェクト計画を開始する前に、要件分析プロセスを実行します。 さらに、プロジェクト管理では、次の場合に要件分析を実行します:

• 開発コストの計算
• プロジェクトの優先順位の設定
• 作業内訳構造の作成
• 進行中のプロジェクトのプロジェクトスペシャリストを含む

プロジェクトマネージャーは、新規プロジェクトを開始する前にプロジェクト要件分析を実行します。 要件分析文書は、主要な利害関係者からのプロジェクト要件を収集、整理、および追跡します。 それはプロジェクト計画を導き、stakeholderおよび経営目標と一直線に並ぶあなたのプロジェクトを完了することを保障する。

ソフトウェア工学における要件分析

要件分析はどのプロジェクトにとっても有益ですが、ソフトウェア工学では最も一般的です。 ソフトウェア工学では、要件分析は要件工学と呼ばれ、新しいソフトウェアの構築または変更に対する期待を定義します。

ソフトウェアエンジニアリングにおける要件分析により、プロジェクトマネージャーとリーダーは、明確な方向性を維持し、ユーザーのニーズを前面と中央に保 ソフトウェア工学における要件分析は、通常、プロジェクトの期間を通じて反復的で連続的なプロセスであり、一度だけ行われるタスクではありません。

どのようにプロジェクトの要件を見つけるのですか？

プロジェクトの要件を発掘することは、要件分析の核心です。 それは最も重要な係争物受寄者からの入力を識別し、得ることから始まる。 これらの利害関係者を特定した後、作業を開始する前に、研究と検証のためのプロジェクト要件を記録します。

徹底した要件分析を行うには、主に三つの段階があります:

1. 最初のステップは、ビジネスプロセスの文書を収集し、利害関係者とのインタビューを行うことによって、要件を収集することです。
2. 次に、要件を分析して検証し、要件が明確で、完全で、一貫性があり、明確であるかどうかを評価します。
3. 最後に、要件を記録し、プロジェクト全体でその実装を監視します。

要件分析プロセスで相談すべき重要な利害関係者には、クライアント、エンドユーザー、チームメンバー、プロジェクトスポンサーが含まれます。 これらは通常プロジェクトによって最も影響を与えられる係争物受寄者であり理想的なプロジェクトの結果を定義するために必要性は組み合

要件分析技術を知る必要がある

要件分析技術は、要件分析を通じてそれを行う利害関係者の期待を決定するのに役立ちます。 彼らはまた、あなたが同じページにいることを確認するために、単純な、視覚的な言語で利害関係者の期待を明確にすることができます。 要件を収集したら、要件分析文書にそれらを書き留め、承認のために利害関係者と共有します。

プロジェクト中にこの要件分析文書を変更した場合は、変更管理手順を使用して記録し、関連する利害関係者の承認のために再度提出してくださ

ビジネスニーズを発見するための要件分析技術

次の要件分析技術は、ビジネスニーズを発見するのに役立ちます:

• ギャップ分析：ギャップ分析は、ビジネスとその目標を研究し、このギャップをどのように閉じることができるかについての洞察を提供するプロセ
• Business motivation model(BMM):この分析手法は、グローバルな変化に対応するビジネス上の意思決定をサポートするOMGモデリングシステム上に構造化されています。
• カスタマージャーニーのマッピング: ストーリーテリングとビジュアルの注入により、カスタマージャーニーマップは、顧客の動機、恐怖、異議を理解するのに役立ちます。

ソフトウェア要件を特定するための要件分析技術

以下の要件分析技術は、ソフトウェア要件のニーズを特定するのに役立ちます:

• データフロープログラム:データフロープログラム(DFP)は、詳細な詳細を掘り下げずにプロジェクトスコープを定義します。
• ユースケース:ユースケースは、システムの動作を定義し、エンドユーザーの観点から通信するのに役立ちます。
• ユーザーストーリー:ユーザーストーリーは、システムが提供すべき機能ではなく、ユーザーのニーズに焦点を当てています。

プロジェクト要件を特定する際の課題は何ですか？

プロジェクトの要件を特定する際には、いくつかの共通の課題が予想されます。

利害関係者は、彼らが望むものを知らない

要件分析の最大の課題は、顧客がしばしば彼らが望むものの漠然とした考えを持っていることです。 何人かの顧客はそれを伝えることと知っているが戦うかもしれない従って彼らの必要性を捕獲するために右の質問をするあなたまである。

要件は動的であることが多い

要件分析のもう一つの課題は、要件の進化する性質です。 プロジェクトの開始時に定義された期待は、プロジェクトの進行に伴って変更される可能性があります。 ビジネスの動向は、全く新しいソリューションを必要とする、初期条件に影響を与える可能性があります。 予期しない変更に対処するためのバックアップ計画と変更管理プロセスを準備します。

チーム間のコミュニケーションが悪い

プロジェクトマネージャー、エンジニア、ユーザー間の技術的な専門知識の違いにより、これらの利害関係者は常に目に それはすべての複雑な側面間の仲介者そして伝達者であるプロジェクトマネージャーとしてあなたの仕事である。

開発チームは組織の政治を忘れている

開発チームは組織の政治を忘れていることが多く、特に機能横断的なチームを持つ大企業では。 オフにすると、誤解、目標のずれ、プロジェクトの失敗の原因となる可能性があります。

要件分析プロセスとは何ですか？

プロジェクトの要件を発見するには、以下の五つのステップのプロセスが不可欠です。

ステークホルダー分析を実行

プロジェクト要件を発見するには、プロジェクトスポンサーからエンドユーザー、プロジェクトチームまで、関係する主要なステークホルダーを一覧表示します。

プロジェクトで誰が発言権を持っているかを明確に把握することは、実際の要件分析の前に彼らの期待を集めて整理する正しい道にあなたを 主要な利害関係者を特定したら、プロジェクトの成功または失敗に対する影響力と関心のレベルによってグループ化できます。

• ハイパワー、非常に興味：密接にこのランクの利害関係者の期待を管理します。 彼らの要件はあなたの最優先事項でなければなりません。 顧客、プロジェクトスポンサー、およびエンドユーザーは、このカテゴリに分類されます。 同様に彼らの最も近い影響力を見てください。
• 高出力、あまり興味：これらの利害関係者は、あなたのプロジェクトに大きな利害関係を持っていますが、それについて熱心ではありません。 それらを満足させ、興味を支えるために懸命に働きなさい。
• 低電力、非常に興味：これらの利害関係者はあなたのプロジェクトに大きな利害関係を持っていませんが、問題が発生しないように定期的に情報を通
• 低消費電力、関心が低い：これらの利害関係者は、あなたのプロジェクトにほとんど関心と利害関係を持っていません。 ループでそれらを保ち、それらとのあなたの関係を維持しなさい、しかし余分なコミュニケーションとのそれらを気にしてはいけない。

各利害関係者の要件に注意してください

プロジェクトの利害関係者を特定して分類した後、それぞれに期待を尋ねてください。 彼らはこの製品から何を望んでいますか？ 彼らの期待される結果は何ですか？

ステークホルダーと話すときは、透明性を維持し、プロジェクトの範囲と潜在的な範囲のギャップを明確にし、議論を文脈化します。 そうしないと、利害関係者は非現実的なプロジェクト要件を設定する可能性があり、プロジェクト成果物に目的の機能を実装できないと失望につ

プロジェクトの目標をより明確に把握し、伝えるためには、各利害関係者の明確な視点を理解することが不可欠です。 利害関係者の要件に注意するのに役立ついくつかの要件分析手法を次に示します:

• ホストの個々のインタビュー:各係争物受寄者に彼らの特定の必要性および意見を理解するためにそれぞれ話して下さい。
• グループ面接の実施：特定のステークホルダーグループを含む面接会を開催する。 これらのセッションでは、異なるグループの期待を結ぶ情報の重複を形成することができます。
• ユースケースの活用:ユースケースは、システム、ソフトウェア、またはサービスの機能を説明するシナリオベースのテクニックです。
• モックアップの構築：プロトタイプは、ユーザーが完成した製品のアイデアを提供し、発売前に製品のギャップやユーザーの不満を見つけやすくします。

グループ要件

要件を特定した後、これらの4つのカテゴリのいずれかにグループ化します:

• 技術的要件:プロジェクトを正常に完了するために解決する必要がある技術的な問題
• 運用要件:指定された期間にわたってプロジェクトを実行し続ける: プロジェクトが完了または成功したと見なされるために必要な機能要件

要件を明確にして記録する

さて、各要件の実現可能性と、プロジェクトがどのようにそれらを提供できるかを決定する時です。 そのために必要:

• 要件定義を明確かつ十分詳細は、関連する。
• その重要性に応じてランク要件。 予算が限られていることが多いため、要件に優先順位を付ける必要があります。 “Nice-to-haves”の上に最も重要なニーズを一覧表示します。”
• 主要な利害関係者と議論することにより、相反する要件の問題を解決します。 これは、要件分析を実施する上で最も価値のあるステップです。 これにより、関係者はプロジェクトの結果のいくつかの可能性を探求し、追求するための最良のものに同意することができます。
• 新製品またはシステムの潜在的な信頼性と使いやすさについて詳細な分析を実行します。 この分析では、灰色の領域と考えられる問題を特定します。 重要な調査結果を書面で記録し、以前に特定された利害関係者と共有します。

署名された契約を得る

口頭で要件に同意するだけでは不十分です。 書面でそれらを取得し、提示された要件が正確に彼らのニーズを反映していることを確認する主要な利害関係者グループによって署名された文書 この要件分析文書は、ソフトウェア工学ではソフトウェア要件仕様（SRS）として知られており、スコープクリープの問題の可能性を防ぎます。

要件分析ドキュメントの例

要件分析ドキュメント(RAD)には、テキストとビジュアルダイアグラムを含めることができます。 それはあなたとあなたの顧客間の契約上の一致として役立つことができ、stakeholdersが理解できる言語で書かれているべきである。 要件分析文書の重要なセクションには、次のものがあります:

• 目的
• 聴衆
• 機能要件
• 技術要件

フロリダ州立大学からの要件分析ドキュメントの例を以下に示します。

なぜWrikeを要件分析ツールとして使用するのですか？

成功したプロジェクトは、すべての利害関係者の期待を満たしています。 Wrikeのような強力なプロジェクト管理ツールを使用すると、主要な利害関係者から要件を簡単に収集し、要件分析とプロジェクト計画プロセスを可視化し、一元化された場所とワークスペースでプロジェクト要件を分析できます。

ステークホルダーの期待を満たしながら、時間と予算でプロジェクトの目標を達成する準備ができていますか？ Wrikeのプロジェクト管理ソフトウェアの2週間の無料トライアルから始めましょう。