私は要件分析を行っており、スパイクの良い例を見つけようとしていました。それが何であるかの説明しか見つけられないようです。
システムの使用例については、次の概要があります。
- 名前: 名前は、ユース ケースのユーザーの意図または機能上の目的を明示的に表す必要があります。
- 簡単な説明: 簡単な説明では、主要な通常および代替フロー アクティビティを数行で強く表現する必要があります (アクターが何を望んでいるかを説明してください!)。
- トリガー: トリガーは、ユース ケースを開始する原因となるイベントを表します。このイベントは、外部、一時的、または内部の場合があります。これは、バッチ ジョブにとって重要です。
- 主要なアクター: 各ユース ケースには、少なくとも 1 つの主要なアクターが含まれますが、より多くの主要なアクターが関与する可能性があります。
- 二次アクター: 該当する場合は、ここに記載してください。
- 前提条件: 前提条件は、ユース ケース シナリオを開始する前に常に真でなければならないものを示します。
- 通常フロー: これは、代替フローと共に、ユース ケースの主要部分です。
- 代替フロー: 代替とは、最終結果としてユース ケースの目標を達成する処理/続行の通常のケースの許容可能なバリエーションです。
- 例外: これらは望ましくないが必要なバリエーションですが、ユース ケースの目標の達成にはつながりません。
- 事後条件: 事後条件は、ユースケースが正常に完了したときに常に真でなければならないことを示します。これは、通常の流れまたは代替の流れの結果である可能性があります。
ユーザーストーリーについては、次のアウトラインがあります。
- タイトル: ユーザー ストーリーの目的を説明します。
- 合理的/目的: ユーザー ストーリーによってどのような価値が生み出されるかを説明します。
- 実装の詳細: ビジネスの日常的な言葉で書かれており、次のサブセクションが含まれています。
- コンテキスト: システムのどこからこのストーリーが始まるか、および開発を開始する前に考慮すべきその他の情報について説明します。
- 正常な流れ: 望ましい結果につながる幸せな道筋を説明します。
- 代替フロー: 可能な代替。代替フローは別の話であることが多いため、広く使用されていない
- 例外: 通常/代替フローの失敗の可能性につながる条件を記述します。
- 備考: 開発者がユーザー ストーリーを正しく理解するのに役立つ追加の非技術情報および技術情報。
- テスト: ストーリーが開発後に検証されるときに実行する必要があるテストのリスト。すべてのテストには、予想される答えが含まれている必要があります。
だから私はスパイクの同様のアウトラインを見つけようとしています. スパイクの説明から、少なくとも次の項目を含める必要があると思います。
スパイクのアウトラインには他に何が必要ですか?