回答。

問題の歴史:

ユースケースを用いたシステム記述の方法論の出現と発展は、複雑なソリューションのビジネスロジックとユーザーシナリオを記録するための統一された理解しやすい方法の必要性と関連しています。UML言語は、ユースケース図を標準として普及させ、開発者、ビジネス、アナリスト間のコミュニケーションの透明性を向上させました。

問題:

実際のプロジェクトでは、単に図を描くだけでは不十分で、要件の完全なカバレッジ、一貫性のあるシナリオ、俳優とシステムの動作の詳細を確保する必要があります。大規模なシステムは数百のバリエーション、代替案、およびエラーを持ち、ホワイトスペースや衝突が発生することを引き起こします。

解決策:

システムアナリストは、ユーザーおよび役割のリストを作成し、それらの目標を完全に記述し、主要および代替のイベントの流れを特定し、前提条件を明確に記録し、エラー処理のオプションを考慮する必要があります。そのためには、シナリオテーブル、ダイアグラム、優先度属性、およびステークホルダー間のレビューのためのツールを使用します。

主な特徴:

• シナリオの形式化とその順序。
• シナリオの完全性と交差を手動および自動で再確認。
• 最低1つの「俳優 - システム」インタラクションレベルでの詳細化。

トリッキーな質問。

基本シナリオのみで、代替流れを記録しないことはできますか？

いいえ、代替および例外の流れを無視すると、シナリオが不完全になり、実装時のエラーリスクが高まります。

インターフェースの相互作用のみを処理し、システムの内部動作は省略しても良いですか？

いいえ、システムの動作（例えば、「データが検証される」などの条件を説明しない）を詳細化しないと、実装時に誤解やあいまいさが生じる可能性があります。

すべてのシナリオを1つのユースケース文書に記述するのが良いとされていますか？

いいえ、シナリオの過度の集約は可読性を低下させ、テストや要件のサポートを困難にします。

一般的なエラーとアンチパターン

• エラーを考慮せずに理想的なパス（ハッピーパス）のみを説明する。
• ビジネスロジックではなくUIに焦点を当てる。
• 複雑なシナリオを無条件に1つのエンティティにまとめる。

生活の例

ネガティブケース：主要な流れ（ハッピーパス）だけが記述され、e-commerceシステムでの支払いエラーが考慮されていない。

利点:

• 迅速な合意

欠点:

• エラーのある支払いが発生した場合、プロダクションでの大規模なエラー
• 高額な修正

ポジティブケース：ユースケースが分岐を含む詳細で記述されている — 代替、エラー、中止、境界状態。

利点:

• 明確な要件
• 導入段階でのバグが減少

欠点:

• 分析段階が長くなる。