要件の改善
すべての要件は完璧で実装可能であることが理想的ですが、現実には、一部の要件を調整、連結、または削除して、堅実な要件のセットを確保する必要があります。 各要件を評価することで、改善できる領域を探すことができます。
評価の際には、以下のような質問を自問してください。
要件は明確で完全であるか。
対処する必要があることを認識しているが、要件に含まれていないといったギャップが存在するか。
規制およびコンプライアンス関連のニーズはすべて含まれているか。
この要件は他の要件と重複しているため、連結する必要があるか。
要件にはスコープ外のコンポーネントが含まれているか。
要件には具体的な設計や実装が含まれているか。
要件は、実際の業務上の問題ではなく、レガシ システムによる問題の処理方法を指定しているか。
要件は、解決が必要な問題の解決方法ではなく、その問題自体を記述することを目的としています。 問題は、すべての要件を確認し、それらを設計プロセスの一環としてソリューションにマッピングすることで解決されます。 要件を提供するユーザーが、要件に関する入力を提供する際、問題がどのように解決されるのかを知る必要はありません。
例 - 設計の詳細の含有
この例では、設計の詳細を含む要件について説明します。
顧客アカウント マネージャーは、Microsoft Dataverse の取引先企業行の所有者である場合に、新しいサポート案件が Dynamics 365 で作成されたときにトリガーされる Microsoft Power Automate フローからメールで通知を受信します。
この要件は、顧客アカウント マネージャーとして、顧客が新しいサポート案件をオープンしたときに通知を受け取りたい というようにさらに単純に記述できます。
可能であれば、要件の何、誰、なぜを明確にして、それが新しいソリューションでどのように処理されるかは含めないようにします。 ディスカッションを業務上のニーズに関連付けることで、解決する必要がある問題に関する理解を明確にすることができます。 多くの場合、要求の実装に関して、レガシ システムで行われていた方法よりも優れた方法が存在することがあります。
例 - 詳細の欠如
この例では、欠如している要求の詳細について説明します。
取引先企業には、顧客となった最初の 1 年間は高い与信限度額が付与されません。
この要件の記述では、限度額がいくらであり、どのような金額が高いと見なされるのかがわからないため、実装不可能です。 また、要求のテストも不可能になります。 限度額に対する真の要件は、2 百万ドルといった単純な値であったり、リージョンごとに限度額が異なるような、複雑なケースになる場合があります。 後者の場合、要求の全体的な複雑度は高くなります。 この例は単純ですが、要件がさらに複雑である場合、要件が明確でないと、プロジェクトのスコープとリソースに影響を与える可能性があることを想像してみてください。