手法
プロジェクト チームは、さまざまな手法で要求のキャプチャや管理ができます。 Microsoft Azure DevOps 作業項目と GitHub の問題は、プロジェクト チームの要件に対する共同作業を容易にするものとして、通常は使用されます。 また、チームで使用できるバックログおよびロードマップ管理に特化したツールを利用できます。 要件は、このようなツールの他に、要件ドキュメント、または、物語やユーザー ストーリー形式で、キャプチャされます。
ユーザー ストーリーは、ユーザーが誰か、システムに何が必要なのか、なぜシステムが必要なのかに焦点を合わせています。
例えば、「販売ユーザーとして、割引を顧客にメールで送信したい」と表されます。
実装予定のアクティブなプロジェクトのスプリント/反復に優先付けされるのを待つ間、要件はバックログに分類されます。 バックログは、実装待ちのアイデアの一覧だと考えてください。 スプリントや反復は、プロジェクト チームがソリューションへと実装するためにグループ化された、定義した期間や作業だと考えられます。
スプリントや反復を計画しているときに、バックログ内にある作業アイテム/問題の作業量の見積もりや、優先付けを求められる場合があります。 チームによって、作業レベルの見積もりには、様々なアプローチがあります。 あるチームでは何時間かかるかを見積もり、あるチームでは T シャツのサイズを参考に使います。 基本的に、アイテムの見積もりを行う場合、小、中、大で分類できます。 その後、チームはこのサイズを利用して、スプリントや反復で実装するアイテムをグループ化します。
要件は、実装が可能であることと、1 つのスプリントや反復で完成できる大きさである必要があります。 大規模な要件は、容易に実現できる小さな要件に分割できます。 一部の手法では、大きな要件をエピックと呼びます。エピックは、より細かい部品に分解される前の高レベルな要件を指します。
要件は、機能要件と非機能要件のどちらかにみなされます。 機能要件は、ソリューションの目的や行動について説明します。 非機能要件は、パフォーマンス要件などの、ソリューションの非動作の側面を説明します。 新たなソリューションの機能についてすべてを説明するには、機能要件と非機能要件の両方が必要です。
機能要件
機能要件は、要件の担当者、内容、および理由に重点を置く必要があります。 例えば、「顧客サービス担当者として、解決済みの類似の顧客の問題を検索して、現在の顧客の問題に対する解決策を見つける必要がある」という要件の場合、Microsoft Dynamics 365 Customer Service の機能要件を表しています。
機能要件の大部分は、ユーザーの最終的なソリューションから発生します。
非機能要件を利用することで、ソリューションの成功に重要で、ユーザーが一般的に気にするトピックをキャプチャできます。 この種類の要件では、一般的にソリューションのパフォーマンス、能力、プライバシー、セキュリティ、コンプライアンスなどのトピックが取り上げられます。
例えば、「システムは、停止中に 2,500 件の同時受信問題レポートを処理する必要がある」という要件の場合、Dynamics 365 Customer Service の非機能要件を表しています。
非機能要件
非機能要件の大部分は、IT もしくは企業のコンプライアンス担当者から発生するもので、エンド ユーザーからは発生しません。
非機能要件は、どのように成功を評価し、決定するかを明確に設定する必要があります。 多くの場合、非機能要件には正確に成功を評価する明確な開始地点と終了地点が含まれていません。 非機能要件に制御できない範囲が含まれることも一般的です。そのため、これらの要件を認識し、顧客とのリスク軽減をすることが重要です。 このシナリオの例として、現地のモバイル デバイスで 1 秒未満のパフォーマンス要件を求められたとします。
非機能要件は、一般的にソリューション アーキテクトがその要件をどのように満たすかを決める責任を負います。 ただし、コンサルタントは、このソリューションの非機能要件を認識している必要があります。 多くの場合、非機能要件の目的を支えている部分の変更を求められることがあります。
重要なのは、要件の品質を確実に高いものにすることと、何を実施することに同意したのかを表現することです。 多くの場合、この確認をすることで、要件を実装した後で Dynamics 365 の展開がどの程度成功するかに違いが出ます。