ビジネス要件

ビジネス要件は、ステークホルダー要件仕様 (StRS) とも呼ばれ、CONOPSのようなシステムのエンドユーザーの観点から、提案されたシステムの特性を記述します。製品、システム、ソフトウェア、およびプロセスは、ビジネス要件を実現、満足、または満たす方法です。したがって、ビジネス要件は、ソフトウェアやその他のシステムの開発または調達のコンテキストで議論されることがよくあります。

このような議論を行う主な理由は 3 つあります。

1. 一般的な慣習では、目標または期待される利益を「ビジネス要件」と呼びます。^[1]
2. 一般的に、「要件」という用語は、作成が期待される製品、システム、ソフトウェアの機能を説明するために使用されます。
3. 広く信じられているモデルでは、これら 2 種類の要件は詳細度または抽象度のみが異なるとされています。つまり、「ビジネス要件」は高レベルで、多くの場合曖昧であり、詳細な製品、システム、またはソフトウェア要件に分解されます。

ロビン・F・ゴールドスミス氏にとって、このような混乱は、ビジネス要件は目的ではなく、満たされたときに目的を満たす（つまり、価値を提供する）ものであることを認識することで回避できます。ビジネス要件の「何」は、製品/システム/ソフトウェア要件の「どのように」に分解されません。むしろ、製品とその要件は、ビジネス要件への応答、つまり「何」をどのように満たすかを表しています。ビジネス要件はビジネス環境内に存在し、発見されなければなりませんが、製品要件は人間が定義（指定）します。ビジネス要件は高レベルの存在に限定されず、詳細にまで突き詰める必要があります。ただし、詳細レベルに関係なく、ビジネス要件は常に、満たされたときに価値を提供するビジネス成果物です。詳細に突き詰めても、ビジネス要件が製品要件になることはありません。^[2]

システムまたはソフトウェア開発プロジェクトでは、ビジネス要件には通常、関係者からの承認が必要です。これは通常、製品、システム、またはソフトウェアの作成または更新につながります。製品/システム/ソフトウェア要件は通常、機能要件と非機能要件の両方で構成されます。通常は製品/システム/ソフトウェアの機能 (機能と使用法) と組み合わせて定義されますが、非機能要件は実際にはビジネス要件の形式を反映していることが多く、制約と見なされることもあります。これには、ビジネス レベルで適用される必要なパフォーマンス、セキュリティ、または安全性の側面が含まれる場合があります。

ビジネス要件は、多くの場合、ビジネス要件ドキュメント (BRD) に記載されています。BRD では、要件の達成方法ではなく、要件の計画と開発に正確にアクセスするプロセスまたはアクティビティに重点が置かれています。これは通常、システム要件仕様またはドキュメント (SRS または SRD)、または機能仕様ドキュメントなどの他のバリエーションに委任されます。ビジネス要件とシステム要件の違いが無視されると、BRD と SRD の間で混乱が生じる可能性があります。その結果、多くの BRD は実際には製品、システム、またはソフトウェアの要件を記述しています。

ソフトウェア エンジニアリングまたはソフトウェア開発ライフサイクルのコンテキストにおけるビジネス要件とは、システムの開発サイクルの早い段階で、顧客、従業員、ベンダーなどのビジネス ユーザーのビジネス要件を引き出し、文書化して、将来のシステムの設計を導くという概念です。ビジネス要件は、多くの場合、ビジネス アナリストによって取り込まれます。ビジネス アナリストは、ビジネス活動とプロセスを分析し、「現状の」プロセスを調査して、目標の「将来の」プロセスを定義します。

ビジネス要件には次のようなものが含まれることが多い

• ビジネスの背景、範囲、変更の理由^[3]を含む
• 要件を持つ主要なビジネス関係者
• 将来/目標状態に向けた成功要因
• ビジネスや他のシステムによって課せられる制約
• ビジネスプロセスモデルと分析。多くの場合、フローチャート表記を使用して「現状」と「将来の」ビジネスプロセスを表します。
• 概念データモデルとデータ辞書の参照
• ビジネス用語と地域用語の用語集
• 情報システムを通じてデータがどのように流れるかを示すデータフロー図（ビジネス活動のアルゴリズムの流れを示すフローチャートとは異なります）

ビジネス要件は通常、ビジネスアナリストが他のプロジェクト関係者と協力して定義します。

両者は、ビジネス要件の決定と技術的ソリューションの開発を担当する場合があります。ビジネスアナリストは、実装アプローチの開発、および利害関係者の関与やリスク管理を含むすべてのビジネス領域への影響の管理に関与する傾向があります。

ビジネス要件を記録する最も一般的な形式は、ビジネス要件ドキュメント(BRD) です。BRD の目的は、最終的にどのような設計になるかにかかわらず、システムからどのような結果が求められるかを定義することです。したがって、BRD ドキュメントは、システム リファレンス ドキュメント (SRD) または技術設計ドキュメント (TDD) で補完されます。このドキュメントには、パフォーマンス、保守性、適応性、信頼性、可用性、セキュリティ、スケーラビリティなど、サービス品質に関連する技術要件 (非機能的) を含む、設計、技術パフォーマンス、インフラストラクチャの期待が詳細に記載されています。

初期段階のテストによるプロトタイピングにより、取り込まれたビジネス要件の完全性と正確性を評価できます。利害関係者は早い段階で要件の定義に協力し、その結果はビジネス システムを構築するプロジェクト開発チームに送られます。他の利害関係者は、最終的に展開されたシステムをテストして評価します。明確さを保つには、適切なテンプレートの使用を決定するための正式なプロセスを使用して、要件とそのソリューションを追跡する必要があります。ビジネス要件の範囲は、必ずしもビジネス システムとして構築する必要があるものを定義する段階に限定されるわけではありません。実行中のビジネス システムがどのように管理および保守されるかを構想し、ビジネス目標または戦略との整合性が維持されるようにする段階にまで及びます。ビジネス要件ドキュメントは、管理された方法で継続的に改訂する必要があります。標準化された形式、または特定のビジネス機能およびドメイン用に設計されたテンプレートを使用すると、範囲に焦点を合わせたままにできるだけでなく、ビジネス要件の完全性を確保できます。

一般的には要件を評価する手段と考えられていますが、プロトタイピングは実際にはビジネス要件から構築中の製品、システム、またはソフトウェアに関心を移すことが多いです。プロトタイプは動作するソフトウェアです。つまり、ビジネス要件から 3 つのステップ (製品/システム/ソフトウェア要件、その製品/システム/ソフトウェアのエンジニアリング/技術設計、プログラム コードでの設計の実装) が取り除かれたものです。プロトタイプは、開発者が実装しようとしているソフトウェアの予備バージョンです。プロトタイプはかなり具体的なので、プロトタイプを試す関係者は、開発者が作成しているものの一部について、より有意義なフィードバックを提供できます。これは、ビジネス要件を満たす方法に関する開発者の解釈であって、ビジネス要件そのものではありません。さらに、プロトタイプを早期かつ迅速に作成するために、グラフィカル ユーザー インターフェイス(GUI) が強調され、「中身」は省略されます。中身はプログラム ロジックの大部分であり、ほとんどのビジネス要件が対処される場所です。言い換えると、プロトタイプで明らかになる問題がビジネス要件に関係する可能性はほとんどありません。

要件の変更を認識し、それを文書化し、要件の定義を最新の状態に維持することが重要です。ただし、ビジネス要件は、その認識ほど変化しません。ビジネス要件は存在するかもしれませんが、利害関係者、アナリスト、およびプロジェクト チームによって認識または理解されていない可能性があります。変更は、通常「要件の変更」と呼ばれるもの、つまり製品/システム/ソフトウェア要件に関してより顕著です。これらは、適切に特定されていないビジネス要件を満たすための想定された方法を反映する傾向があります。ビジネス要件の達成に起因する困難の多くは、実際には、製品、システム、またはソフトウェアの高レベルの設計にほぼすべての「要件」の労力を費やすという一般的な慣行を反映しています。これは、価値を提供するために製品/システム/ソフトウェアが満たす必要があるビジネス要件を最初に適切に定義していないことに起因します。開発プラクティスでは、通常、製品/システム/ソフトウェアを継続的に改訂し、最終的に、必要なことを行う、つまり明らかにビジネス要件に対応しているように見えるソリューションに「戻る」まで続けます。ビジネス要件を特定するためのこのようなコストのかかる試行錯誤の間接的な方法は、「ベスト プラクティス」として宣伝されている人気のアジャイル開発手法を含む「反復開発」の多くを基礎としています。

テンプレートは、ビジネス要件に関連することが多い特定のトピックに関する問い合わせを促すのに役立ちます。テンプレートは、ビジネス要件に関する標準化されたドキュメントを促進し、理解を促進します。テンプレートは、ビジネス要件の正確性や完全性を保証するものではありません。実際、テンプレートはよく誤用され、表面的で、意味のある分析のない機械的な定義を促進する傾向があるため、要件の調査に悪影響を与えることがよくあります。

ビジネス要件は、要件の定義に関係する利害関係者の基盤が大きいために時期尚早に固められてしまうことが多く、利害の対立が生じる可能性があります。合意の管理と構築のプロセスは、本質的に繊細で、政治的な問題になることもあります。それほど難しくはないもののよくある課題は、利害関係者が複数の地理的な場所にいる分散型チームの問題です。営業スタッフが顧客の近くにいるのに対し、製造スタッフが製造ユニットの近くにいるのは当然です。上級管理職を含む財務および人事部門は登録本社の近くにいます。たとえば、営業ユーザーと製造ユーザーが関与するシステムでは、目的の対立が見られる場合があります。一方が最大限の機能を提供することに関心がある一方で、もう一方が最低の製造コストに重点を置く場合があります。このような状況では、多くの場合、最大限の機能を合理的かつ収益性の高い製造および流通コストで提供するという合意に至ります。

これらの課題に対処するには、プロトタイプのデモンストレーションと共同作業を通じて、初期段階の利害関係者の同意を得ます。利害関係者ワークショップは、ファシリテートされたセッションまたは単純なハドルディスカッションのいずれかとして一般的に行われ、特に機密性の高いビジネス要件や潜在的な利益相反がある場合に合意形成に役立ちます。ビジネスプロセスの複雑さは要因の 1 つです。これには、法的または規制上の要件、ブランディングなどの社内全体のガイドライン、または社会的責任に対する企業のコミットメントを理解するために必要な専門知識が必要になる場合があります。ビジネス要件分析は、ビジネスプロセスの「内容」とそのコンテキストを提供する「方法」を把握するだけではありません。機能するシステムの設計と構築への変換に対処する必要がある場合があります。この段階では、ビジネス要件は技術的な詳細と実現可能性を認識する必要があります。

新しいビジネス要件のセットごとに、カスタム構築されたソリューションが常に必要というわけではありません。標準化されたプロセスや製品が数多く存在し、それらを微調整したりカスタマイズしたりすることで、ビジネス要件に対応できます。対象となるビジネス システムは、特定のテクノロジの選択、予算、またはすでに導入されている利用可能な製品によって制約されることがよくあります。

最後に、フォーマットの標準化は困難を引き起こす可能性があります。複数のプロジェクトに複数のフォーマットがあると、要件ドキュメントの構造と内容にばらつきが生じ、追跡可能性と管理性の観点からは非効率的になります。実際、部門横断的な要件収集演習で使用するテンプレートを作成する場合、補完的な知識を持つさまざまな役割が共通のフォーマット内で作業することが難しい場合があります。したがって、専門家ではない関係者が、仕様の領域をカバーするために付録や追加の添付ファイルによって追加の要件を提供できるようにすることが重要です。さまざまなニュアンスに対処し、最適なものを見つけることは、効果的な要件に対する最大の課題です。

次の手順が含まれます。

1. ビジネスの定義
2. ビジネスドメインを理解する
3. 組織の目標
4. コアコンピタンス

• システム開発ライフサイクル
• システムエンジニアリング
• ソフトウェア開発プロセス
• ビジネスアナリスト
• ソフトウェア要件仕様
• 要件分析
• 要件
• ソフトウェアのプロトタイピング
• ビジネス分析

• ビール、アドリアナ。要件とは、目標を達成するために私たちがしなければならないことである。www.bealprojects.com、2012
• ゴールドスミス、ロビン F.ソフトウェア プロジェクトを成功させるための実際のビジネス要件の発見。Artech House、2004 年。
• プロジェクトマネジメント協会 (2021)。プロジェクトマネジメント知識体系ガイド (PMBOK ガイド)。プロジェクトマネジメント協会 (第 7 版)。ニュータウンスクエア、ペンシルバニア州。ISBN 978-1-62825-664-2。{{cite book}}: CS1 メンテナンス: 場所が見つかりません 発行者 (リンク)
• ロバートソン、スザンヌ、ジェームズ C. ロバートソン。要件定義プロセスの習得。第 2 版、Addison-Wesley、2006 年。