ビジネスアナリストとして要件を整理する方法

ビジネス要件とは、プロジェクトや製品に関するステークホルダーのニーズをまとめた正式な文書です。ビジネス要件の提示方法に決まった標準フォーマットはありませんが、どのバージョンも、製品やプロジェクトについて議論、分析、文書化、検証を行うのに十分な詳細さで記述されている必要があります。

ビジネス要件は、次のいずれかの方法で提示できます。

• テーブルまたはスプレッドシート
• 図（ワークフロー）
• グラフ
• モデル (実体関係図)
• プロトタイプまたはシミュレーション
• 構造化された文章またはテキストのテンプレート

ビジネス要件を整理して提示する方法

以下は、要件を記述および整理する手順です。 ビジネスアナリスト.

ステップ1） 要件を分類する。

• 各要件を、該当するカテゴリーに分類してください。
• 技術系の関係者は技術要件のカテゴリを参照し、非技術系の関係者はビジネス要件または一般的な要件のカテゴリを参照するべきである。
• 各組織は、どのカテゴリーが自らの基準に合致するかを決定すべきである。
• 分類は、要件の種類（機能要件かビジネス要件か）に基づいて行うこともできますが、この区分はすべてのプロジェクトに当てはまるわけではありません。

ステップ2） 要件を整理します。
関係者が文書を容易に閲覧し、不足している項目を見つけられるように、要件を論理的な順序で収集・整理する。

ステップ3） リストを準備します。
承認が必要な関係者ごとにグループ分けした要件レビューリストを作成してください。

例えば、技術的なバックグラウンドを持つ利害関係者は、製品の技術的な側面のみに関心を持つだろう。

ステップ4） 一意の識別子を使用します。
If trac要件を相互に関連付けるのは難しいので、一意の識別子を使用して tracより簡単に利用できる。

ステップ5） 利害関係者が希望する方法で要件を提示する。
関係者によって、同じ要件でも異なる形式で提示する必要があるかもしれません。例えば、ある関係者は図解を好む一方、別の関係者は構造化された文章を好むといった具合です。

ステップ6） 目次を準備します。
すべての要件の目次を作成してください。これは関係者にとって役立ちます。 track を使ってそれらを素早く見つける。

ステップ7） ビジネス分析ツールを使用します。
　 ビジネス分析ツール リリース全体を通して、要件を一貫して提示および分類するのに役立ちます。

ステップ8） 要件ドキュメントをプロセス フローごとに整理します。
文書から不要な要件を削除し、残った要件を、それらがサポートするプロセスフローごとに整理する。

ステップ9） 要件をマッピングします。
収集した各要件をプロセスフローの特定の手順にマッピングすることで、レビュー担当者が要件とそれがサポートするワークフローを関連付けることができるようになります。

ステップ10） 表と箇条書きを使用します。
複雑な要件は表を用いて提示し、それぞれの要件の重要な点を強調するために箇条書きを用いる。

ビジネス要件定義書の作成とプレゼンテーションに役立つヒント

より良いプレゼンテーションと tracビジネス要件の王様である以下のヒントは、すべてのビジネスアナリスト（BA）にとって役立ちます。

• 要件の分類は時間がかかるため、毎回新しいカテゴリを作成するのではなく、ビジネスアナリスト、ステークホルダー、専門家、技術チームがプロジェクト間で再利用できる標準的なカテゴリセットを定義しましょう。
• 各要件は、対象となるユーザーを考慮して作成してください。主要な関係者、影響力のある人物、意思決定者（利害関係者、技術スタッフ、開発者など）を理解しましょう。
• 一度に 1 つの要件を定義します。各要件はアトミックである必要があります。
• 曖昧さを避けるため、要件記述では「など」や「約」といった曖昧な修飾語を使用しないでください。
• まだ定義されていない要件を参照しないでください。
• 文書から重複した記述や矛盾する記述を削除してください。
• 複雑な要件を、より小さく、管理しやすく、レビューしやすい項目に分割する。
• 説明する 何 システムは、 の それは実現するだろう――実装は設計段階で行うべきだ。

ビジネス要件を視覚化するための一般的な手法

長々と文章を並べ立てることは、ステークホルダーを失う最も手っ取り早い方法です。ビジネスアナリストは、テキストベースの要件すべてに視覚的な要素を添えることで、意図が一目でわかるようにします。以下の手法は、BABOKガイドやほとんどの企業におけるビジネスアナリストの実践例で用いられています。

• ビジネスプロセスモデリング表記法（BPMN）： BPMNは、プール、レーン、ゲートウェイ、イベントを用いて、エンドツーエンドのビジネスプロセスを図示します。誰が何をいつ行うかを示すのに最適です。
• ユースケース図と Descriptイオン： アクターとシステム間の相互作用、および各アクターが期待する結果を把握します。機能主導型のバックログに適しています。
• 受け入れ基準を含むユーザーストーリー： 「…として、私は…したい。そうすれば…」という簡潔な文と、Given-When-Then条件を組み合わせた形式。アジャイルチームにおける標準的なフォーマットです。
• ワイヤーフレームとモックアップ： 低忠実度または中忠実度のスクリーンは Figmaバルサミク、または Axure 非技術系の関係者にとってUI要件を具体的に理解できるようにする。
• エンティティ関係図（ERD）： ソリューションが保存する必要のあるデータエンティティと、それらの間の関係を示します。これは、レポート作成と統合の要件にとって非常に重要です。
• データフロー図（DFD）： Tracデータがプロセス、ストレージ、外部アクターを介してどのように移動するか、特に分析や統合プロジェクトにおいて。

対象となるユーザーに合わせて手法を選びましょう。経営幹部はプロセス図やカスタマージャーニー図に反応しやすく、開発者はER図やユーザーストーリーに反応しやすく、エンドユーザーはワイヤーフレームやプロトタイプに反応しやすいからです。

ビジネス要件文書を整理するための一般的なツール

要件の数が数十を超えると、Word 文書では対応できなくなります。ビジネス アナリストは、ベースライン設定、レビュー、 trac脆弱性、および変更管理。以下は、業界全体で最も広く使用されているものです。

• JiraとConfluenceの連携： アジャイルチームにおける標準的な組み合わせ。要件はJiraのエピックとストーリーとして管理され、ConfluenceページにはBRD（ビジネス要件定義書）の記述と図が掲載されます。
• ジャマ・コネクト： 要件管理、ベースライン設定、ライブ配信に重点を置いたエンタープライズプラットフォーム trac医療機器や航空宇宙などの規制産業における利用可能性。
• IBM Engineering Requirements 管理ドア： 防衛、自動車、安全性が極めて重要なシステムで長年使用されてきたツールで、あらゆる要件を満たす必要があります。 trac食べられる。
• Modern Requirements の Azure DevOps: 拡張する Azure DevOpsにおいて、作業項目から直接、レビュー、承認、ベースライン設定、およびWord形式のBRDエクスポートが可能です。
• Miro or Lucidchart: ホワイトボードや図解ツールは、BPMN、ER図、ユーザージャーニー、ワークショップのメモを作成するために使用され、これらは後に正式なBRDの作成に役立てられます。
• バルサミクと Figma: UI要件をテキストではなく視覚的に表現できるワイヤーフレームおよびプロトタイプ作成ツール。

プロジェクトの規模と監査ニーズに合わせてツールセットを選択してください。小規模プロジェクトはConfluenceとJiraから始めることができますが、規制対象プログラムでは通常、JamaまたはDOORSが必要になります。 tracアクセシビリティ監査。

ビジネス要件を提示する際によくある間違い

綿密に調査された要件であっても、提示方法が悪ければ却下される可能性があります。以下のミスは、ほとんどのビジネスアナリストの事後分析で見られるものであり、レビューの際に注意すべき点です。

• 何をどのように組み合わせるか： スリップping 要件定義書に実装の詳細を盛り込むと、分析が完了する前に設計チームが解決策に縛られてしまう。
• 曖昧な表現： 「速い」「ユーザーフレンドリー」「柔軟性がある」といった言葉はテストできません。測定可能な受け入れ基準に置き換えてください。
• すべての関係者にとって共通のフォーマット： 経営陣、開発者、エンドユーザーに同じ見解を提示しても、通常は誰一人として満足しない。対象者に合わせてフォーマットを調整する必要がある。
• 見つけて下さい trac可能性: ビジネス目標、設計要素、テストケースと関連付けられていない要件は、変更要求が届いた際に正当化することはできない。
• 優先順位なし： MoSCoW、加重スコアリング、または同様の枠組みを用いずに数百もの要件を提示すると、関係者は価値ではなく範囲について議論せざるを得なくなる。
• ドキュメントの負荷が高すぎる場合： すべての図、ログ、および根拠を200ページにも及ぶ1つのPDFに詰め込むと、重要な要件が見落とされてしまいます。BRD（ビジネス要件定義書）を論理的なセクションに分割し、明確な目次を作成してください。
• スキップping サインオフ： 正式な承認プロセスを経ずにBRD（ビジネス要件定義書）を提示すると、後々の納品段階でスコープの拡大や責任のなすりつけ合いが生じる可能性が残る。

Rev各ステークホルダーセッションの前に、このリストと照らし合わせてBRD（ビジネス要件定義書）を確認することで、後の段階で手戻りが発生する問題のほとんどを事前に把握できます。

よくあるご質問