こんにちは！
これは、記事「 BAタイムズのノーマン・ザスワルドナー 」の翻訳です。 2014年の記事ですが、2018年には非常に関連性があるように思えました。
さあ始めましょう！
データ要件-ビジネスアナリストは注意が必要ですか？
ある日、ITディレクターから、データ要件については考えず、ビジネス要件のみに焦点を当てるように言われました。 このシステムは6〜8か月で開発される予定でしたが、2年以上かかり、最終結果に満足した人はほとんどいませんでした。 [このテキストを読んで、よく組織化されたプロジェクトがあることを喜ぶことができません。私はIT製品の作成に取り組んでいます。ほとんどすべてのプロジェクトで、データだけを気にする人がいます]
ビジネスアナリストはデータ要件を気にする必要がありますか？ どう思いますか？
残念ながら、ビジネスアナリストは、ビジネス情報の分析よりもビジネスプロセスの分析に多くの時間を費やしています。 これは、多くの場合、ストーリーの半分のみを伝える要求につながります。 ITシステムの構築に関しては、データを理解することはプロセスを理解することと同じくらい重要です。 今日の世界では、構築されたシステムのみを再構築する余裕のある組織はほとんどありません。
要件を収集し、最初にプロジェクトを最大限に活用するために、必要なもの（および必要なもののみ）の全体像を作成できるようにする方法があります。 [興味をそそられる]
では、データについてはどうでしょうか？
ビジネスアナリストとして、私たちは問題や機会の根本を見つける専門家であり、これを行うための多くの方法があります。 使用する方法の選択は、ビジネス環境、利害関係者の好み（利害関係者）、主題専門家（SME）の利用可能性、システムの利用可能性、関連文書などを含む多くの要因に依存します。現在の現状のビジネスプロセス。 ユースケース、データフロー図、機能分解、シーケンス図、および状態図は、使用可能なメソッドのほんの一部です。 ビジネスプロセスのモデリングに関しては、ツールボックスに完全な方法がありますが、情報を文書化するという概念が欠けていることがよくあります。
ビジネスアナリストは、データ要件を忘れたり、無視したりすることがあります。 これは、彼らがこれが彼らの仕事ではない、または他の誰かがそれを世話するだろうと思うからかもしれません。 おそらく、これらのすべての長方形と線を含む図の外観に脅かされています。 理由に関係なく、ITシステムを構築するチームの一員であり、データをまったく理解せずにビジネスプロセスを文書化する場合、作業の半分しか行いません。
なぜ気にする必要があるのですか？
データ要件を理解すると、多くの利点があります。 ビジネスアナリストがビジネスプロセスとデータを理解している場合、両方の領域をクロスチェックする絶好の機会があります。 たとえば、データを使用しない（または生成しない）ビジネスプロセスがある場合、ビジネスプロセスではない可能性があります。 同様に、ビジネスプロセスで使用されていないデータモデルにデータ要素がある場合、ビジネスプロセスを見逃したか、データ要素がシステムの一部ではない可能性があります。 いずれの場合でも、この知識を使用してビジネスプロセスの分析を完了し、すべてのデータ要件を考慮することができます。
データ要件を文書化するために使用する4つの重要な方法があります。 選択する方法は、ビジネス環境、時間とお金の量、および利害関係者と中小企業の好みによって異なります。
データ要件
1.データモデリング
データモデルは、情報要件を収集するために使用される最も強力なツールの1つです。 データ型、フィールド長、他のデータ項目との関係など、各データ項目を慎重に文書化できるため、これは優れたアプローチです。 前述したように、データモデルはビジネスプロセスモデルの完全性をチェックするための優れたツールです。
それを強力にするデータモデリングのもう1つの側面は、特にツールを使用してモデルを開発した場合、ビジネスアナリストがSMEによってインストールおよび検証されると、データベース管理者と協力してモデルを物理データベースに再設計できることです。データモデリング。
データモデリングには練習が必要です。この方法の経験がない場合は、トレーニングコースを受講し、学習を支援できる経験豊富な同僚またはメンターと協力する必要があります。
2.データ辞書
データディクショナリはデータモデルの必須部分ですが、個別に開発することもできます。 データディクショナリは、エンティティ、各オブジェクトの属性、およびそれらの間の関係を記述するシステムデータ要素の記述です。 データディクショナリを開発するために大きな準備は必要ありませんが、これは簡単な練習ではなく、忍耐が必要です。
データディクショナリの検証は、ビジネスアナリストが定義に関する利害関係者の間で意見の相違に遭遇することが多いため、困難な場合があります。 これらの違いをプロジェクトのライフサイクルの早い段階で調整することは必須であり、それらを無視することは後の段階で悲惨なものになる可能性があります。
3.レポートとプロトタイプの分析
ビジネスアナリストがデータ要件を説明できるもう1つの方法は、一連のレポートレイアウトを開発することです。 システムに入力されるすべてのデータは、レポートに何らかの形式で表示されると想定されています。 結局のところ、データがレポートに表示されない場合、なぜデータベースにそれを配置するのでしょうか？ 理論的には、ビジネスアナリストが中小企業によって検証された一連のレポートレイアウトを手に入れるとすぐに、見逃せないすべてのデータ要素を手にします。
通常、ビジネスアナリストは、組織が使用するレポートが既に存在するため、最初からレポートレイアウトを作成する必要はありません。 追加のデータ要件につながる新しいレポートまたは異なるレポートが存在する場合があり、一部の既存のレポートが変更される場合があります。 これは、データ要件を開発するための最も簡単な方法の1つであり、重要なトレーニングを必要としない方法です。
4.リバースエンジニアリング
ほとんどの組織はカスタマイズされたソリューションの開発のリスクとコストを認識しているため、多くのITシステム開発プロジェクトは市販の市販ソリューション（COTS）に焦点を当てています。 COTSの実装により、ビジネスプロセスとデータ要件の定義の観点から宿題を行わない組織は、非常に簡単に障害のリスクにさらされます。 サプライヤーにすべてを委ねるだけでは十分ではなく、あなた自身が出力を受け取ることを完全に確信する必要があります。
リバースエンジニアリングテクノロジーでは、検討中のCOTSの試用版を取得し、データベースソフトウェアをデータモデリングツールにコピーして物理データベーススキーマを作成します。 次に、スキーマを組織のデータ要件を表すデータモデルと比較します。 それらの違いの分析により、決定を下すべき領域が決定されます。 たとえば、ソリューションが特定のデータ要件をサポートしていない場合、組織はそれがなくても存続できるかどうかを決定するか、手作業を追加するか、製品をカスタマイズできるかどうかを判断する必要があります。 サプライヤデータベースのリバースエンジニアリングが常に可能であるとは限らない多くの理由があり、可能であっても、いくつかの技術的ノウハウが必要です。
はい、できます！
データ要件を収集するために、データモデリングの専門家である必要はありません。 興味があるだけで、何か新しいことに挑戦したいという気持ちがあり、知らないことを知っているかもしれない他のITプロフェッショナルと協力する準備ができている必要があります。 快適ゾーンから抜け出し、ビジネス分析であるゾーンに入るのは簡単です
次の記事では、説明したツールのいくつかを使用してデータ要件を収集する方法について説明します。
乾杯！