機能要件の文書化とアーティファクト
収集する要件は、一般に機能的または非機能的と見なされます。 機能要件は、ソリューションが実行する必要がある内容またはその動作を説明し、非機能要件は、一般にパフォーマンス要件などのソリューションの非動作の側面を説明するために使用されます。 このレッスンでは、機能要件に関するいくつかの考慮事項について説明します。
各機能要件では、要件の担当者、内容、および理由を明確に把握する必要があります。 要件が大きすぎる場合は、より小さい要素に分割する必要があります。
機能要件
機能要件の簡単な例をいくつか次に示します。
- 販売ユーザーとして、営業案件を失注としてクローズし、今後の販売戦略を改善するために失注した理由を把握できる必要がある。
- 販売マネージャーとして、見積の割引を承認して合計価格を下げ、顧客に割引を提供できる必要がある。
- スタッフの経理担当として、後で再度開く必要がないように、保留中の品目があるバッチは閉じないようにする必要がある。
これらの例は、担当者、内容、および理由を示しています。
適切に表現されていない要件の例をいくつか次に示します。
- 営業案件を受注できるか失注する。
- 価格に割引を反映する必要がある。
- バッチ品目リストで、左から 3 番目のボタンであるバッチの終了をクリックすると、発生を妨げる品目がない場合にバッチが終了する。
さまざまな要件を収集する場合は、機能の単なる一覧にするのではなく、プロセスやユーザー体験にマップするとかなり役立ちます。 ユーザー向けのストーリーを作成し、設計中のシステムをそれらのユーザーがうまく使用するにはどうすればよいかを確立します。 ホワイトボードに走り書きしたり、ツールを使用してプロセスを図示したり、計画段階でチームに有効なものを何でも提示したりすることができます。 チームは、後で各部分をより小さいアクション可能な項目に分割します。
受け入れ基準
どうすれば要件が満たされたと見なされるかを明確に理解しておくことは重要です。 多くの場合、この要件の文書化は、要件が十分に詳細かつ適切な規模であるかどうかの判断に役立ちます。 この文書化は、要件の実装を評価するためにチームをテストするのにも役立ちます。 最後に、関係者と共にレビューして、正確であることを確認する必要があります。これはスコープが徐々に移動するのを防ぐために使用できます。 満たせないかもしれない受け入れ基準を探し、実現可能な妥協点に達するための交渉を行うことが重要です。
例外の把握
一般に、取引の成約のような単純な要件には、直線的なパスと少数の例外パスしかない可能性があります。 ハッピー パスを把握する際に、これらの例外を探して特定することが重要です。 設計に進むときに、例外を主として設計する必要がなくなります。 このように処理する必要がありますが、存在することがわかっていない場合は、後で修正する必要があります。 さらに、一部の例外は、ソフトウェアのカスタマイズではなくプロシージャやプロセスで処理するのが最適であるため、その例外がどの程度頻繁に発生するかを必ず把握しておくこともお勧めします。
スコープの移動の回避
オフのままにすると、すべてのプロジェクトで、想定して予算を割り当てたものからスコープが追加されます。 特定した後、プロジェクトのガバナンス プロセスを使用して、その処理方法を評価する必要があります。 多くの場合、それらを含めることが許容されていると、プロジェクトの契約構造によっては変更オーダーが発生することがあります。 スコープの増加をそのまま無視すると、プロジェクトが失敗する可能性が高くなります。
国際化
Microsoft Power Platform には、アプリを国際化するための多くのオプションが作成者用に用意されています。 モデル駆動型アプリとポータル アプリにはどちらも、言語パックや複数通貨などの国際化オプションが用意されています。 これらの要件を正確に文書化することは、ユーザー採用のために不可欠です。 国際化の文書化は要件から始め、品質保証テスト計画、ユーザー採用テスト、システムの文書化に含める必要があります。 国際化のニーズも満たす実践的でテスト可能な要件を文書化するため、ここで挙げているベスト プラクティスに従ってください。
ソリューション アーティファクト
ソリューション コンポーネントに論理名を付けることがベスト プラクティスと見なされるため、そのような論理名のドキュメントを準備すれば、確実に価値を実感できるようになります。 それらの項目の文書化は、プロジェクトごとに少し異なる場合があります。
この文書化の目的は、時間の経過と共にソリューションを確実に進化させ続けることに加えて、プロジェクト チームに常に最新の情報を伝えることです。 これは特に、作成者チームに参加している場合や、各チーム メンバーが異なる機能セットに取り組んでいる場合に役立ちます。 予測可能な名前が付けられており、名前と予想される動作が一貫性のある方法で文書化されていれば、重要な内容をかなり文書化しやすくなります。
ユーザー ストーリーやバックログ項目などのプロジェクト計画項目は、文書化をすぐに始めるためのリソースとして役立ちます。 プロジェクトが完了するまでこの文書化を行うのを待つのも魅力的ですが、少なくともプロジェクトのマイルストーンごとに完了させると、さらに役立つ進行中のリソースとなります。 大きな問題になる前に不整合やエラーに気付いて修正することができます。
(モデル駆動型アプリまたは Dataverse データ ソースで) テーブルを文書化するときは、使用目的などのテーブルの説明を含めることを検討してください。 各テーブルの列と、そのデータ型および説明を含めます。 テーブル間のリレーションシップと、定義された動作 (行の削除動作など) を文書化します。 セキュリティ ロールと列レベルのセキュリティに関する考慮事項も含めてください。 ドキュメント ビューとそのクエリ、フォームとその対象ユーザー/用途、レポートとダッシュボードなどです。
自動化には、ビジネス プロセス フロー、Power Automate フロー、ビジネス ルール、従来型のワークフローが含まれます。 個々の自動化をそれぞれ文書化する必要があるだけでなく、それらの自動化がどのように連携するかも文書化する必要があります。 使用されるコネクタとその要件もここで文書化できます。
ドキュメント化するキャンバス アプリ コンポーネントには、特定の画面とそのナビゲーション、使用されるデータ ソース、式、自動化のトリガーが含まれます。 Power Apps ポータルには、キャンバス アプリと同様の文書化ニーズがありますが、認証済みユーザーと匿名ユーザーの区別も含められます。
Power Virtual Agents を文書化するときは、トピック レベルの会話フロー、対象のデータ ソース、エスカレーション計画を含めます。
特定の技術的な詳細に加えて、ユーザー体験の説明を書くと役立つことがあります。 「ユーザーがここをクリックします」だけではありません。予想されるエクスペリエンスをすべて含める以上のことをします。 そのユーザーによる毎日のソリューションの操作体験と見なすことができます。 この文書化の対象ユーザーについて考慮し、文書化のアクセシビリティなどを考慮したり、言葉による説明とグラフィックによる説明の両方を提供したりすることに気を配ってください。 この文書化は、新しいチーム メンバーのオンボーディング、ユーザー承認基準の作成、完了時の顧客へのプロジェクト引き渡しに役立つ可能性があります。
移行および統合用のデータの文書化
以前からある考慮事項なしでプロジェクトを開始することはめったにありません。 ユーザーは、既に理解している多くのビジネス データを、非効率的なアプリで使用しています。 実際の状況に応じて、データに接続したり、データを移行したりできます。 どちらのパスにも計画と文書化が必要です。
移行か統合かに関係なく、データの品質は非常に重要です。 データは正確ですか。 関連性がなくなった古いデータはありますか。 軽減すべき重複はありますか。 移行前に重複を排除できますか。
チェックリストを作成してそれに従うと、古いデータを新しいソリューションに取り込む際の影響を最小限に抑えることができます。
データ ソースを文書化する: 使用されるデータ ソースと接続を特定します。 ソース データの品質を特定します。 すべてのソース データが新しいシステムに転送されるわけではない点を念頭に置きながら、移行する列を特定します。
データのタイプを文書化する: ソース データと移行後スキーマを比較します。 データの移動を開始する前に、変換時に発生する可能性のある問題を特定します。
データ マッピングを文書化する: システムに取り込まれるデータの列ごとのレビューを完了し、適切にマップされていることを確認します。 ソース データ列とターゲット データ列のメタデータの違いを調整します。
エラー処理を文書化する: インポートまたは統合時のエラーを修正するための計画を作成します。
外れ値に対応する: ソースから新しい環境に移行されるデータがすべて 1 対 1 で完全にマッピングされるわけではありません。 そのような外れ値を特定して計画を作成します。
データの品質の継続的な評価を文書化する: データの品質のレビュー、レポート、修復を行います。