注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundry で新しい開発に着手する前に、ユースケースの簡単な説明を記述します。
多くの場合、組織にはこの種のドキュメントを作成するための推奨方法がすでにあります。決まった形式がない場合は、以下の問いを方向性を定めるための指針として検討してください。
概要
ユースケースと、取り組みの動機は何ですか？組織には詳しくても、この特定のプロセスやチームについては知らない人に、その価値をどのように説明しますか？
意思決定
最終的に下す意思決定は何ですか？中間段階で下す意思決定は何ですか？どのユーザーがどの意思決定を担いますか？
関係者
ユースケースの関係者は誰ですか？それぞれの立場から何を重視していますか？
機能要件
ユースケースのソリューションはどのような機能を提供する必要がありますか？次の形式で整理することを検討してください。
[User Type] [Interface] [Decision] [Decision Inputs] [Action]
例：路線運航アナリスト（ユーザーの種類）が、担当路線のフライトアラート受信トレイ（インターフェース）を確認し、優先度、フライトの詳細、組織への影響（意思決定の入力）に基づいてアラートのトリアージを行い（意思決定）、各アラートを再割り当て、解決、またはエスカレーションします（アクション）。
成果と KPI
定量的および定性的な成果は何ですか？成果をどのように測定しますか？
背景とコンテキスト
現在、この業務はどのように行われていますか？制約や課題は何ですか？
共同での技術文書の作成やプロジェクト計画には、Notepad を使ってドキュメントページを作成し、プロジェクト内のドキュメントフォルダーに保存することを検討してください。
機能要件は、ユースケースが提供しなければならない機能を最も詳細に記述したものです。ビジネス要件、ユーザーストーリー、低忠実度のモック、意思決定ポイントの分析などを整理し、具体化したものです。
これらの要件を記録する唯一の「正しい」方法はありませんが、次の形式を使うと、重要な詳細を簡潔に強調できます。
[ユーザーの種類] [インターフェース] [意思決定] [意思決定の入力] [アクション]
飛行路線を監視し、アラートに基づいてパフォーマンスを改善するユースケースを考えてみます。
路線運航アナリスト（ユーザーの種類）が、担当路線のアラート受信トレイ（インターフェース）を確認し、優先度、フライトと路線の詳細、組織への影響（意思決定の入力）に基づいてアラートのトリアージを行い（意思決定）、各アラートを再割り当て、解決、またはエスカレーションします（アクション）。
路線アナリスト（ユーザーの種類）が、アドホックなポイントアンドクリック操作（インターフェース）のツールで、過去のフライトパターン（意思決定の入力）に基づいて、エスカレーションされたアラートの根本原因分析（意思決定）を行い、解決策を推奨します（アクション）。
データサイエンティスト（ユーザーの種類）が、アドホックなポイントアンドクリック操作（インターフェース）のツールで、過去のフライトパターン（意思決定の入力）に基づいてルールを提案し（意思決定）、路線アラートを生成します（アクション）。
地域マネージャー（ユーザー）が、集計されたフライトデータ、サードパーティーのソース、推奨事項（意思決定の入力）を含む概要ダッシュボード（インターフェース）を使って傾向を特定し（意思決定）、戦略的な投資を行います（アクション）。
この形式で機能要件を収集すると、ユーザーの意図を理解しやすくなり、特定の UI 要素にとらわれるのではなく、利用可能なプラットフォーム機能に適した実装パターンを柔軟に選択できます。また、可視化、メトリクス、推奨事項などの意思決定の入力を生成するために必要なデータエンリッチメントや、データをモデル化して意思決定の出力を記録するためのオントロジー構造を理解するうえで重要な情報も記録できます。
以下は、要件定義フェーズでよく見られるアンチパターンを示す注意点です。ユースケースのスコープ設定に、これらのいずれかが当てはまるかどうか検討してください。