プラットフォームの概要ユースケースのライフサイクル機能要件の精査

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

機能要件の精査

Foundryで新しい開発作業を始める前に、ユースケースの簡単な説明を書いてください。

多くの場合、組織にはこのタイプの文書化に対する既定のアプローチがあります。既存のフォーマットがない場合は、これらのプロンプトを方向性のあるガイダンスとして検討してください。

ユースケース概要テンプレート

概要

ユースケースと努力の動機は何ですか?組織に詳しい一般の人に、この特定のプロセスやチームについて説明する価値は何ですか?

決定

最終的にどのような決定が行われますか?中間的な決定は何ですか?どのユーザーがどの決定に関連しますか?

関係者

ユースケースの関係者は誰で、彼らの視点から何を気にしていますか?

機能要件

ユースケースソリューションで提供される必要のある機能は何ですか?以下のフォーマットで構成することを検討してください。

[ユーザー タイプ] [インターフェース] [決定] [決定の入力] [アクション]

例えば、ルート運用アナリスト(ユーザータイプ)が、担当ルートのフライトアラート受信トレイ(インターフェース)を確認し、優先度、フライト詳細、組織への影響(決定の入力)に基づいてアラートをトリアージ(決定)し、各アラートを再割り当て、解決、またはエスカレーション(アクション)します。

成果とKPI

定量的および定性的な成果は何ですか?成果はどのように測定されますか?

背景とコンテキスト

現在、この作業はどのように行われていますか?制限や課題は何ですか?

技術文書の作成

共同で技術文書の作成やプロジェクト計画を行う場合は、Notepad を使用して、文書化ページを作成し、プロジェクト内の Documentation フォルダに保存することを検討してください。

機能要件

機能要件は、ユースケースが提供する機能に関して、最も詳細な説明です。ビジネス要件、ユーザーストーリー、低忠実度モック、決定ポイント分析などの成果物をまとめたものです。

これらの要件を捉えるための唯一の「正しい」方法はありませんが、以下のフォーマットでは、重要な詳細を簡潔に強調するのに役立ちます。

[ユーザータイプ] [インターフェース] [決定] [決定の入力] [アクション]

フライトルートの監視やアラートに基づくパフォーマンス改善に関するユースケースを考慮してください。

ルート運用アナリスト(ユーザータイプ)が、担当ルートのアラート受信トレイ(インターフェース)を確認し、優先度、フライトとルートの詳細、組織への影響(決定の入力)に基づいてアラートをトリアージ(決定)し、各アラートを再割り当て、解決、またはエスカレーション(アクション)します。

ルートアナリスト(ユーザータイプ)が、アドホックでポイントアンドクリック(インターフェース)ツールを使用して、歴史的なフライトパターン(決定の入力)に基づいてエスカレートされたアラートのルート原因分析(決定)を実行し、解決策を提案(アクション)します。

データサイエンティスト(ユーザータイプ)が、アドホックでポイントアンドクリック(インターフェース)ツールを使用して、歴史的なフライトパターン(決定の入力)に基づいてルールを提案(決定)し、ルートアラートを生成(アクション)します。

地域マネージャー(ユーザー)が、フライトデータと第三者情報源および推奨事項(決定の入力)をまとめた概要ダッシュボード(インターフェース)を使用してトレンドを特定(決定)し、戦略的投資を行う(アクション)。

この形式で機能要件を収集することで、ユーザーの意図を理解し、利用可能なプラットフォーム機能に適合した実装パターンを選択する柔軟性を残すことができます。また、視覚化、指標、推奨事項などの決定の入力を生成するために必要なデータの濃縮、およびデータのモデリングと決定の出力のキャプチャに必要なオントロジー構造を理解するための重要な情報をキャプチャします。

フラグ

これらのフラグは、要件フェーズでの一般的なアンチパターンを示しています。ユースケースのスコープがこれらのいずれかに当てはまるかどうかを検討してください。

  • 現在の課題への調査が不十分
  • 特定のUI要素にアンカーを置いた要件
  • ユーザーの範囲が狭すぎる
  • スコープがユーザーの決定にまで及んでいない