project-management - ユースケースで例外を定義する必要がありますか？

Question

「会議のスケジュール」というユースケースがあるとします。仕様で定義されているように、会議は現在または将来にのみスケジュールできます。ユースケースでは、「指定された日時が過去の場合、メッセージボックスに「会議の時間は過去にはできません」と表示される」というフローを含める必要がありますか？

私が言ったように、それは日付/時刻が過去になることはできないという仕様で定義されていますが、ユースケースの定義では、そこでも定義する必要がありますか？

Answer 1

ビジネスのワークフローは、回避できるのであれば技術的なものであってはなりません。

「ユーザーにはこれらの条件下でエラーが表示されます...」のように言うのは問題ありませんが、それを実装する方法を定義するのは開発者の責任です。例外は良い方法かもしれませんが、ビジネスの利害関係者は無関心である必要があります。実装の詳細。

Answer 2

この古いスレッドを見つけてよかったです！ユースケースの例外についてwikiエントリを読んだところ、いくつかの問題が発生しました。

ユースケースが適切に使用されることを理解しているので、過去の会議を例外にするべきではありません。

ユースケースは、この場合、会議をスケジュールするための要件を表します。無効な会議出席依頼の処理は、実際にはスケジューリングプロセスの一部であり、例外ではありません。

ユースケースと同様に、この要件は例外なく存在します。無効な日付は詳細項目です。ユースケースをより一般的な目次と考えてください。

繰り返しモデリングしている場合は、モデル/ドキュメントを作成するときに、無効な会議出席依頼を拒否する要件を「発見」して管理します。

、

Answer 3

この古いスレッドを見つけてよかったです！ユースケースの例外についてwikiエントリを読んだところ、いくつかの問題が発生しました。

ユースケースが適切に使用されることを理解しているので、過去の会議を例外にするべきではありません。

ユースケースは、この場合、会議をスケジュールするための要件を表します。無効な会議出席依頼の処理は、実際にはスケジューリングプロセスの一部であり、例外ではありません。

ユースケースと同様に、この要件は例外なく存在します。無効な日付は詳細項目です。ユースケースをより一般的な目次と考えてください。

繰り返しモデリングしている場合は、モデル/ドキュメントを作成するときに、無効な会議出席依頼を拒否する要件を「発見」して管理します。

さらに簡潔に言えば、スケジュール会議機能について説明しました。UMLユースケースは、機能主導型の開発には使用しないでください。