適切な要件の計画

では、何が良い要件なのでしょうか？適切な要件は価値があり、実行可能である必要があります。ニーズを定義し、ソリューションへの道筋を提供する必要があります。チームの全員がその意味を理解する必要があります。要件の複雑さはさまざまです。

優れた要件ドキュメントは、下位要件に分類された高レベルの要件を持つグループの一部になることができます。
また、最終製品の動作またはコンポーネントを説明する一連の機能要件を含む非常に詳細な仕様が含まれている場合があります。
適切な要件は簡潔かつ具体的である必要があり、「どのようにニーズを満たすのか」という質問ではなく、「何が必要なのか」という質問に答える必要があります。
適切な要件により、すべての利害関係者が計画のそれぞれの部分を理解することが保証されます。部品が不明瞭または誤って解釈された場合、最終製品に欠陥があるか、故障する可能性があります。

要件の進展に応じてプロセス全体でチームから継続的にフィードバックを受け取ることにより、要件の失敗や誤解を防ぐことができます。全員との継続的なコラボレーションと賛同が成功の鍵です。

要件の収集と分析

要件とは、利害関係者が問題を解決したり組織目標を達成するために必要な条件または能力です。システムが満たす必要がある条件または機能。

ソフトウェアエンジニアリングの_要件分析_は、さまざまな利害関係者の対立する可能性のある要件を考慮して、ソフトウェアまたはシステム要件を分析、文書化、検証、管理する、新しい製品または変更された製品のニーズまたは条件を決定するタスクに対応します。

要件があります-

文書化
実用的
測定可能
テスト可能
追跡可能

要件は、特定されたビジネスニーズまたは機会に関連し、システム設計に十分な詳細レベルに定義される必要があります。

ビジネスアナリストは、既存のシステムを観察し、既存の手順を調査し、顧客やエンドユーザーと議論することで情報を収集します。アナリストは、稼働中のシステムがない場合、想像力と創造力も必要です。収集した要件を分析して欠落しているリンクを見つけることは、要件分析です。

エリシティングアプローチ

目的を引き出すには、ビジネスの専門家、開発マネージャー、およびプロジェクトスポンサーに以下の質問をします-

このプロジェクトは、会社のどのビジネス目標を達成するのに役立ちますか？
なぜ今このプロジェクトをやっているのですか？
後で行うとどうなりますか？
まったく実行しないとどうなりますか？
このプロジェクトの恩恵を受けるのは誰ですか？
それから利益を得る人々は、それを現時点でおそらく可能な最も重要な改善と考えていますか？
代わりに別のプロジェクトを行う必要がありますか？

考えられる目標は、コストの削減、顧客サービスの改善、ワークフローの簡素化、古い技術の置き換え、新しい技術の試験運用などです。また、提案されたプロジェクトが記載された目的の達成にどのように役立つかを正確に理解してください。

さまざまなタイプの要件

ビジネスアナリストが興味を持っている要件の最も一般的なタイプは次のようになります-

ビジネス要件

ビジネス要件は、ソリューションに依存せずに組織の目標を達成するために実行する必要がある企業の重要な活動です。ビジネス要件文書（BRD）は、顧客のニーズと期待の文書を含むプロジェクトのビジネスソリューションの詳細を示します。

ユーザー要件

ユーザー要件は、ユーザーがソフトウェアプロジェクトから構築されるソフトウェアに期待/希望する特定の要件を指定する必要があります。ユーザー要件は、検証可能、明確かつ簡潔、完全、一貫性、追跡可能、実行可能である必要があります。

ユーザー要件ドキュメント（URD）またはユーザー要件仕様は、ソフトウェアエンジニアリングで通常使用されるドキュメントであり、ユーザーがソフトウェアに何ができると期待するかを指定します。

システム要求

システム要件は、アプリケーションの最適な機能を提供するためにコンピューターにインストールする必要があるソフトウェアリソース要件と前提条件の定義を扱います。

機能要件

機能要件は、開発中のシステムの特定の意図された動作をキャプチャして指定します。システムの計算、データの操作と処理、ユーザーインターフェイスとアプリケーションとの対話、およびユーザーの要件がどのように満たされるかを示す他の特定の機能などを定義します。各要件に一意のID番号を割り当てます。

非機能要件

非機能要件は、特定の動作ではなくシステムの動作を判断するために使用できる基準を指定する要件です。システムアーキテクチャは、非機能要件を実装する計画について語っています。

非機能要件は、システムがどのように見えるべきか、または「システムがそうでなければならない」のように言及することができるかについて話します。非機能要件は、システムの品質と呼ばれます。

移行要件

移行要件は、企業の現在の状態から望ましい将来の状態への移行を容易にするためにソリューションが満たさなければならない機能を記述しますが、移行が完了すると不要になります。

それらは本質的に常に一時的なものであり、既存のソリューションと新しいソリューションの両方が定義されるまで開発できないため、他の要件タイプとは区別されます。通常、既存のシステムからのデータ変換、対処する必要があるスキルギャップ、および目的の将来の状態に到達するためのその他の関連する変更をカバーします。これらは、ソリューションの評価と検証を通じて開発および定義されます。

トレーサビリティと変更管理

要件のトレーサビリティは、最初のアイデアの生成からテスト段階まで、すべての要件を整理、文書化、追跡する方法です。

要件トレース機能マトリックス（RTM）は、開発プロセスを通じて機能要件とその実装を追跡する方法を提供します。各要件は、関連するセクション番号とともにマトリックスに含まれています。

プロジェクトが進行すると、RIMが更新され、各要件のステータスが反映されます。製品のシステムテストの準備が整うと、マトリックスには各要件、どの製品コンポーネントが対応しているか、どのテストが正しく実装されていることを検証するかがリストされます。

トレーサビリティ

RTMに次のそれぞれの列を含める-

要件の説明
FRDの要件リファレンス
検証方法
テスト計画の要件リファレンス

例-プロジェクト内のアイテム間の関係を識別するためにドットを接続します。一般的なダウンストリームフローのコネクタです。

アイデア要件デザインテストビジネス目標

各要件を元のビジネス目標にまでさかのぼることができるはずです。

要件をトレースすることにより、変更による波及効果を特定し、要件が完了しているかどうか、および適切にテストされているかどうかを確認できます。トレーサビリティと変更管理により、管理者は問題を予測し、継続的な品質を確保するために必要な安心感と可視性を得ることができます。

品質保証

要件を最初に正しく実現することは、品質の向上、開発サイクルの短縮、製品に対する顧客満足度の向上を意味します。要件管理は、あなたがそれを正しくするのを助けるだけでなく、あなたのチームが開発プロセスを通してお金と多くの頭痛を節約するのを助けます。

簡潔で具体的な要件は、修正するのに費用がかかる場合よりも、問題を早期に検出して修正するのに役立ちます。さらに、欠陥を早期に修正するよりも、開発プロセスの後半で開発プロセスの後で修正する場合、要件を修正するよりも最大で* 100倍*高くなる可能性があります。

要件管理を品質保証プロセスに統合することで、チームの効率を高め、手戻りをなくすことができます。さらに、コストの問題のほとんどが発生するのは手直しです。

言い換えれば、開発チームは、最初は正しく実行されなかった努力のために予算の大半を無駄にしています。たとえば、開発者は古い仕様ドキュメントに基づいて機能をコーディングしますが、後でその機能の要件が変更されたことを学習します。これらのタイプの問題は、効果的な要件管理のベストプラクティスによって回避できます。

要約すると、要件管理は複雑な規律のように聞こえますが、それを単純な概念に要約すると、チームが「私たちが構築しているものとその理由を理解していますか？」開発者、QAマネージャー、およびテスターに対するマネージャー、プロジェクトリーダー、関係する利害関係者および顧客-プロジェクトの失敗の根本的な原因は、プロジェクトの範囲の誤解であることがよくあります。

全員が共同作業を行い、プロジェクトのライフサイクル全体の要件に関連する議論、決定、変更に対する完全なコンテキストと可視性を備えている場合、つまり成功が一貫して発生し、継続的な品質を維持している場合。さらに、プロセスはスムーズであり、関係するすべての人にとって、摩擦とフラストレーションが少なくなります。

注-プロジェクトチームは、要件を効果的に管理することにより、プロジェクトの欠陥の50〜80％を排除できることが調査により示されています。カーネギーメロンソフトウェアエンジニアリング研究所によると、「ソフトウェア開発のコストの60〜80％が手直しされています。」

要件サインオフの取得

要件サインオフは、文書化されているように、要件の内容と提示が正確で完全であるというプロジェクトの利害関係者による合意を正式にします。正式な合意により、実装中または実装後に、利害関係者が新しい（以前は遭遇しなかった）要件を導入するリスクが軽減されます。

要件サインオフを取得するには、通常、各プロジェクト関係者と文書化された要件の対面の最終レビューが必要です。各レビューの終わりに、利害関係者はレビューされた要件文書を正式に承認するよう求められます。この承認は、物理的または電子的に記録できます。

通常、要件サインオフの取得は、要件通信内の最終タスクです。ビジネスアナリストは、レビュープロセス中に提起されたコメントや異議への対応など、正式な要件レビューからの出力を必要とします。

Business-analysis-planning-good-requirements

目次