この記事は、の一部として公開されました データサイエンスブログソン

ドキュメントの準備は、すべての責任アナリストが行う最も重要なタスクのXNUMXつです。 ビジネスアナリストは、クライアントの要件を文書化するだけでなく、プロジェクトのライフサイクル中に発生した進捗状況とすべての変更を文書化します。 プロセスフローを書き留めて、メンテナンスと将来の参照のためにこれらのことを書き留めておくことが重要です。

この分野に不慣れな場合、またはビジネスアナリストとして成功することを目指している場合は、ビジネスアナリストが作成した重要で詳細なドキュメントに関するガイドが役立つでしょう。

余計な手間をかけずに、ビジネスアナリストが作成したすべてのドキュメントが、BAを成功させるために不可欠なものを確認してみましょう。

ビジネスアナリストが作成する必要のある主要なドキュメント：

このリストでは、クライアントにとって最適なビジネスソリューションを実現するために、プロジェクトの開始からプロジェクトの実施まで、BAが作成した重要なドキュメントについて説明します。

• 事業分析計画

• ビジネス要件ドキュメント

• 機能要件仕様（FRS）/機能仕様文書（FSD）

• システム要件仕様（SRS）/システム要件ドキュメント（SRD）

• 要件トレーサビリティマトリックス（RTM）

• ユースケース図

• ワイヤーフレーム、モックアップ

• 変更要求文書

これらの重要なドキュメントのそれぞれについて詳しく説明しましょう。

プロジェクトビジョンドキュメント

クライアントまたはプロジェクトマネージャーが主にプロジェクトビジョンドキュメントを作成しますが、このドキュメントの作成におけるビジネスアナリストの役割も同様に重要です。 プロジェクトビジョンドキュメントには、開発する製品の目標とビジョンが含まれ、その特定の製品を通じてどのような目的が達成されるかについて説明します。 また、次の要素で構成されています。メリット、関連するリスク、およびプロジェクトが開始される前に利用可能なオプション。 これらの文書は、会社とビジネスの利害関係者の間の正式な合意として機能します。

プロジェクトビジョンドキュメントには次のものが含まれます。

–ビジョンと目標

–その特定のプロジェクトに含まれるユーザーの説明

–プロジェクトの利害関係者

–開発する製品の概要

–開発中に含まれる製品の機能

–製品要件

–関連する制約またはリスク

–品質/文書化の要件

事業分析計画

ビジネス分析計画は、主に、プロジェクトのライフサイクル中にビジネスアナリストが実行する必要のある主要なアクティビティを説明する正式なドキュメントです。 ビジネスアナリストは、プロジェクトスコープの計画段階でこのドキュメントを作成します。 このフェーズに関与するのは、この計画を実行するためにサポートが必要なプロジェクトマネージャー、製品所有者、およびビジネスマネージャーです。

ビジネス分析計画には、次の手順が含まれます。

1. 計画の目的

2. 役割と責任の分配

3. プロジェクト計画の実行に必要なツール

4. プロジェクトを定義するために実装されたプロセスとテクニック

5. ワークフローとプロセスマッピング

6. 必要に応じて変更を実装するための適応性と対策

ビジネス要件計画

画像1

ビジネス要件ドキュメントまたはBRDは、クライアントが会社に取り組む必要のある特定の製品またはソフトウェアの要件を定義し、クライアントとの会議で話し合った結果を最終的に達成するために作成されます。 BRDは、プロジェクトのライフサイクル全体を通じて誰もが参照するそのようなドキュメントのXNUMXつです。 このドキュメントは、プロセス中に新人のミスを犯すことなく、すべてのフェーズで正しい選択を行うのに役立ちます。

BRDは、クライアントによって提示された問題ステートメントに基づいて、意図されたビジネスソリューションが何であるかに焦点を合わせます。 したがって、BRDは、ビジネスの利害関係者によって説明されているように、すべての重要な要件に言及し、収集していると言っても過言ではありません。

ビジネスアナリスト、プロジェクトマネージャー、スクラムマスター、クライアント、ドメインエキスパートとともに、上級管理者はBRDを作成して、ビジネス要件が正しく理解され、参照用に書き留められるようにします。

通常、ビジネス要件ドキュメントには次のものが含まれます。

–プロジェクトの背景

–ビジネスの目標と目的

–プロジェクトに関与する利害関係者

–要件の範囲

–プロジェクトに関連するデータの収集

–プロジェクトが適切に機能するためのインターフェース要件

–ビジネス用語集/専門用語（必要な場合）

機能要件仕様（FRS）

画像2

そのため、BRDは、誰でも簡単に参照できるようにドキュメントを参照できるように準備されています。 専門用語は使用されておらず、混乱を避けるためにビジネス要件は素人の言葉で表現されています。 ただし、BRDは、技術開発チームがシステムを完全に理解するための理想的なドキュメントではありません。 したがって、機能仕様書は開発チームの要件を満たすためにあります。

BRDが特定のプロジェクトで何を実行または達成する必要があるかについて話し合う一方で、FRSは、チームがプロジェクトを完了する方法と、規定された時間内にプロジェクトを完了するための最適なパスを見つけるためにシステムがどのように動作するかを重視します。 機能仕様書は、データ、操作、入力、出力、システムのプロパティなど、システムの意図された動作も定義します。 FRDはより洞察に満ちており、開発およびテストチームが特定のプロジェクトで仕事を遂行することを目的としています。

システム要件文書（SRD）/ SRS

画像3

SRSまたはSRDは、システムの完全な動作と、開発後にシステム全体がどのように機能する必要があるかを記述します。 このドキュメントには、すべての機能と非機能要件が含まれています。 システム要件仕様（SRS）/システム要件ドキュメント（SRD）には、次のものが含まれています。

–ユースケース

–プロジェクトを構築するためのソフトウェア要件のタイプ

–製品がシームレスに機能するためのデータベースとストレージの要件

– UI / UXを理解するための製品機能

–目的のソフトウェアのターゲットユーザーを理解するためのユーザー特性

WireFrame、プロトタイプ、およびモックアップ

画像4

開発されようとしている会社の製品を視覚的に表現することが不可欠です。 このモックアップ、別名ワイヤーフレームは、最終的にクライアントが将来のシステムを理解するのに役立ち、BAとして、クライアントが自分のアイデアに同意するかどうかを知るのに役立ちます。

この青写真を視覚的に提示するために、ビジネスアナリストは、JIRAなどのワイヤーフレームツールを使用してワイヤーフレームデザインを準備します。 これらの図は、クライアントの要件に合わせているため、分析フェーズで多くの時間を節約できます。 開発チームはまた、ワイヤーフレーム設計から参照を取得して、実用的な設計を構築します。

ユースケース図

ビジネスアナリストは、チームがシステム要件を特定、整理、定義するのに役立つユースケース図も作成する必要があります。 ユースケースは、チームによって開発されたシステムとの典型的なユーザーの相互作用を示しています。 さらに、ユーザーがシステムと対話するシナリオを記録するのにも役立ちます。 ユーザーストーリーと、インタラクションがどのように行われるべきかについての多くの可能性を扱います。

開発チームは、プロジェクトのライフサイクル全体でユースケース図を参照します。 BAは、チームまたは主要な利害関係者が変更を要求すると、ユースケース図を更新します。

通常のユースケース図と説明的な要件ドキュメントには、次のものが含まれます。

–俳優

–説明

- 引き金

–前提条件

–メモと問題

これらは、ユースケース図にある詳細の一部です。

要件トレーサビリティマトリックス-RTM

RTM、別名要件トレーサビリティマトリックスは、ビジネスアナリストによって作成および管理される重要なドキュメントです。 ビジネスアナリストは、RTMを使用して、プロジェクト要件を特定のテストケースおよび考えられる欠陥にマッピングおよび追跡します。 RTMは、開発されたアプリケーションのすべての機能がカバーされ、テストされていることを保証します。

RTMは、Excelなどのツールで表形式で作成され、テストシナリオと要件の関係が確立されます。 RTMは、プロジェクトに実装されている場合、変更を追跡するためにも使用されます。

ビジネス要件文書には次のものが含まれます。

–要件の説明

–機能要件

- 技術仕様

–ソフトウェアモジュール

–テスト済み

変更要求管理

ビジネスアナリストとして、プロジェクトの実行中にクライアントまたは開発チームから要求された多くの変更に遭遇する可能性があります。 事業主は、市場の憶測に従って特定の憶測の後で適切であると判断した場合、いくつかの機能を後で追加または削除するように要求する場合があります。 プロジェクトのコースプランを遅らせたり変更したりする可能性のある追加のリクエストは、変更リクエストと見なされます。 変更を実装する前に、ビジネスアナリストはタイムラインと影響を分析し、プロジェクトに追加する前に必要な承認を行います。

変更要求ドキュメントは、スコープクリープに対処するための優れた方法です。スコープクリープは、機能の追加または削除により、新しく提案されたアクションプランが当初の目的と異なる場合に発生します。 次に、技術チームとクライアントとの定期的な会議で、変更要求をどのように実装し、プロジェクト計画全体にどのように影響するかを決定します。

まとめ

ビジネスアナリストとして、すべての重要な情報を文書化し、関連するチームと共有して、決定された時間枠でプロジェクトを完了することが不可欠です。 さらに、ビジネスアナリストは、開発チームおよびビジネスの利害関係者と定期的に会議を行い、プロジェクトの進捗状況を追跡し、変更要求を受け入れ、技術チームと調整して次のことを行います。

画像ソース-

1. 画像1：example.com
2. 画像2：
3. 画像3：フレッシュコード
4. 画像4：ピントレスト