1

2 人のアクター間の会話またはやり取りを含むプロセスをモデル化しているとしましょう。この例では、わかりやすいものを使用します:-

  1. サプライヤーが価格表を作成し、
  2. バイヤーは購入するアイテムをいくつか選択し、発注書を送信します。
  3. サプライヤーは発注書を受け取り、商品を発送します。
  4. サプライヤーが請求書を送付
  5. 買い手は請求書を受け取り、支払いを行います

もちろん、これらの各ステップ自体は、すぐに複雑になる可能性があります。要件ドキュメントでこれをユースケースにどのように分割しますか?

このプロセスを 1 つのユース ケースとして扱うとしたら、1 冊の本を埋めることができます。

あるいは、上記の各ステップからユース ケースを作成すると、キャプチャする必要のある重要なインタラクションとフローの一部が隠れてしまいます。「注文書の受け取り」で始まり「請求書の送信」で終わるユースケースと、「請求書の受け取り」で始まり「支払いの実行」で終わる別のユースケースを用意することは理にかなっていますか?

何かアドバイス？

4

2 に答える 2

1

私が通常このようなタスクにアプローチする方法は、プロセスの UML ユース ケースと高レベルのアクティビティ図の作成を開始することです。詳細については気にせず、最善を尽くしてください。

ドラフトを作成すると、それを改善する方法がすぐにわかります。その後、ユースケースを小さくしたり、大きなアクティビティを構造化したりするなど、リファクタリングを続けることができます。または、ユース ケースが小さすぎる場合は、いくつかのユース ケースをまとめることもできます。

あなたのプロジェクトの詳細を知らなくても、私は先に進み、各ステップを個別のユース ケースにします。それらはすべて自己完結型のようであり、相互参照なしで説明できます。そうしている間に依存関係が見つかった場合は、いつでもアプローチを再考できます。

また、ロギング、セキュリティなどの一般的な要素に「extend」および「include」ブロックを使用することを検討してください。

于 2008-10-02T06:34:25.550 に答える
1

はい、ここには多くの可能性があります。上記の例では、買い手が請求書を支払うために複数の部分的な支払いを行うことで、さらに複雑になる可能性があります。

おそらく、完全なワークフロー ユース ケースを作成する必要があります。上記の各ステップを独自のユースケースに分割しても、一部のステップには前後の条件があるため、役に立たない場合があります。

私は QuickBooks のソース コードに取り組んでいますが、トランザクションがシステムを通過する方法の数は気が遠くなるようなものです。QA担当者がすべての組み合わせをテストすることはほとんど不可能です.

于 2008-10-02T06:09:28.387 に答える