Business-analysis-requirements-management
ビジネス分析-要件管理
ソフトウェア要件の収集は、ソフトウェア開発プロジェクト全体の基盤です。 ビジネス要件の要請と収集は、すべてのプロジェクトにとって重要な最初のステップです。 ビジネス要件と技術要件のギャップを埋めるために、ビジネスアナリストは、特定のコンテキスト内のビジネスニーズを完全に理解し、これらのニーズをビジネス目標に合わせて、利害関係者と開発チームの両方に適切に伝える必要があります。
主要な利害関係者は、誰かが顧客/クライアントの要件をわかりやすい英語で説明できることを望んでいます。 これは、高レベルで価値を理解することで彼らに利益をもたらすでしょうか？ これは、ドキュメントを要件とBAが最善の方法で通信する方法をマッピングしようとするため、主な焦点領域になります。
プロジェクトが失敗する理由
プロジェクトが失敗する多くの理由がありますが、いくつかの共通領域には以下が含まれます-
- 市場と戦略の失敗
- 組織および計画の失敗
- 品質不良
- リーダーシップとガバナンスの失敗
- スキル、知識、能力の失敗
- エンゲージメント、チームワーク、コミュニケーションの失敗
問題の核心は、プロジェクトがますます複雑になり、変化が起こり、コミュニケーションが困難になることです。
成功するチームが要件管理を行う理由
要件管理とは、チームを*同期*状態に保ち、プロジェクト内で行われていることを*可視化*することです。
プロジェクト全体を成功させるには、チーム全体が何を構築しているのか、そしてなぜそれを理解するのが重要です。それが要件管理の定義方法です。 「なぜ」が重要なのは、要件についての目標、フィードバック、および決定のコンテキストを提供するためです。
これにより、将来の成功と潜在的な問題の予測可能性が高まり、チームは問題を迅速に修正し、プロジェクトを予定通りに予算内で正常に完了することができます。 開始点として、関係者全員が、要件とは何か、それらを管理する方法について基本的な理解を持っていることが重要です。
基本から始めましょう
要件とは、利害関係者が問題を解決したり目的を達成するために必要な条件または能力です。 システムまたはシステムが満たす必要がある条件または機能。 契約、標準、仕様、またはその他の正式に課された文書を満たすコンポーネント。
要件は、テキスト、スケッチ、詳細なモックアップまたはモデル、エンジニアが構築するもの、QAマネージャーがテストするものに最もよく伝達される情報で表現できます。 開発プロセスに応じて、要件を把握するために異なる用語を使用する場合があります。
高レベルの要件は、単に「必要」または「目標」と呼ばれることもあります。 ソフトウェア開発プラクティスでは、要件は「ユースケース」、「機能」、または「機能要件」と呼ばれる場合があります。 さらに具体的には、アジャイル開発方法論の範囲内で、要件は多くの場合 epics および stories としてキャプチャされます。
チームが何と呼んでいるか、どのプロセスを使用しているかに関係なく;要件は、すべての製品の開発に不可欠です。 要件を明確に定義しないと、不完全な製品または欠陥のある製品を生産する可能性があります。 プロセス全体を通して、要件の定義に関与する多くの人々が存在する可能性があります。
利害関係者は、問題を解決する上で製品がどのように価値を提供するかを説明する機能を要求する場合があります。 設計者は、ユーザビリティまたはユーザーインターフェイスの観点から、最終製品の外観または性能に基づいて要件を定義する場合があります。
ビジネスアナリストは、特定の技術的または組織的な制約を順守するシステム要件を作成する場合があります。 今日の洗練された製品とソフトウェアアプリケーションの構築では、プロジェクトまたはリリースの範囲を十分に定義するのに数百または数千の要件が必要になることがよくあります。 したがって、開発プロセス中に要件が自然に変化し、時間とともに進化するため、チームが各要件にアクセスし、共同作業し、更新し、テストを完了できることが不可欠です。
要件管理の価値を高レベルで定義したので、すべてのチームメンバーと利害関係者が理解から利益を得ることができる4つの基本事項をさらに詳しく見てみましょう。
- 適切な要件を計画する：「一体何を構築していますか？」
- コラボレーションと賛同：「仕様を承認するだけです！」
- トレーサビリティと変更管理：「待って、開発者はそれが変わったことを知っていますか？」
- 品質保証：「こんにちは、誰かがこのことをテストしましたか？」
誰もが私たちが構築しているものとその理由を知っていますか？ それが要件管理の価値です。
利害関係者からのコラボレーションとバイイン
みんなループですか？ 前進するための要件について承認はありますか？ これらの質問は、開発サイクル中に発生します。 全員が要件に同意できれば素晴らしいのですが、多くの利害関係者がいる大規模なプロジェクトでは、通常これは起こりません。 全員の同意を得ようとすると、決定が遅れたり、さらに悪いことに、まったく決定されなかったりする可能性があります。 すべての決定についてコンセンサスを得ることは必ずしも容易ではありません。
実際には、必ずしも「コンセンサス」が必要というわけではありません。プロジェクトを前進させるために、グループからの「バイイン」と管理者からの承認が必要です。 コンセンサスを使用して、すべての人が妥協して決定に同意するようにします。 バイインでは、人々に最良のソリューションを支持させ、賢明な決定を下し、前進するために必要なことを実行させようとしています。
誰もが決定が最良であることに同意する必要はありません。 誰もが決定をサポートする必要があります。 チームのコラボレーションは、意思決定に関するサポートを受け、適切な要件を計画するのに役立ちます。
コラボレーションチームは、全員がプロジェクトに関与し、フィードバックを提供できるように努力します。 共同チームはアイデアを継続的に共有し、通常はコミュニケーションが改善され、プロジェクトの目標に対するコミットメントと理解が共有されているため、意思決定をサポートする傾向があります。
開発者、テスター、または他の利害関係者がコミュニケーションの問題が発生し、人々がイライラし、プロジェクトが遅れるのは、「ループの外」を感じるときです。 全員が仕事の範囲に賛同したら、要件を明確にし、十分に文書化することが不可欠です。 すべての要件を追跡することは、物事がトリッキーになる場所です。
完了するために複数の人と協力することを含む1マイルのTo Doリストがあることを想像してください。 これらすべてのアイテムをどのようにまっすぐに保ちますか？ アイテムの1つの変更がプロジェクトの残りの部分にどのように影響するかをどのように追跡しますか？ ここで、トレーサビリティと変更管理が価値を高めます。
