2

このユースケースに番号を付ける/書く方法を決定しようとしていますが、少し問題があります。

 

短い形式で：

 

主なシナリオ

1.アナリストが注文を選択します

2.システムは注文が手動でスケジュールされることを決定します

3.アナリストがラインアイテムを選択します

4.システムは要求された日付をチェックし、日付を満たすことができるかどうかを判断します

5.アナリストは出荷日を受け入れます

すべての広告申込情報がスケジュールされるまで、3〜5を繰り返します。

6.残りのユースケース。

 

代替シナリオ＃1-自動スケジュール注文

2.システムは、注文を自動的にスケジュールできることをユーザーに通知します。

2.1。アナリストは、注文を自動スケジュールするようにシステムに指示します

2.2。-2.4。アナリストがシステムに置き換えられることを除いて、メインシナリオのステップ3〜5と同じです。

2.2を繰り返します。2.4まで。すべての広告申込情報がスケジュールされるまで。

メインシナリオのステップ6に戻ります。

 

代替シナリオ＃2-要求された日付を満たすことができません

どちらのシナリオでも、要求された日付に間に合わない状況に遭遇する可能性があります。

X.システムは要求された日付を満たすことができないと判断します

X.1システムが最初の利用可能日を決定

X.2アナリストが出荷日を変更

X.3戻る...???

このシナリオでは、注文が手動でも自動スケジュールでも、手順は同じです。ただし、シナリオは2つの異なるノード（メインで4つ、代替で2.3）から分岐できます。これをどのように処理しますか？2番目の代替シナリオのステップにどのように番号を付ける必要がありますか？

4

1 に答える 1

0

これは、シナリオの形で散文で書くか (おそらく、プロセスを通じてペルソナに従う)、またはアクティビティ/シーケンス図に入れるもののように思えます。ユースケースは、「繰り返す」、「戻る」などを表すものではありません。個人的には、このケースを説明するためにシーケンス図を使用します。

与えられた説明からできることは、このワークフローが何であるかを実際に指摘するユース ケースを定式化することです。現在、約 15 行を読む必要があります。アナリストは何を達成したいですか？

主な使用例は「製品の<<extend>>発送」であり、「発送のスケジュール」と「発送日の変更」という 2 つの使用例が含まれる場合があります。

ちなみに、「アナリストはシステムに注文を自動スケジュールするように指示します」は不必要に思えます。システムがそれを自動的に実行できる場合は、そうすべきです。そのように伝える必要がある場合は、なぜそれが必要なのかを明確にする必要があります。

于 2013-02-07T13:55:32.760 に答える