• 説明：開発者として、本番システムにアプリケーションを展開するために、アプリケーションの現在のステータスを更新セットに公開したいと考えています。
• 説明：顧客として、最新のステータスを得るために、インシデントにコメントが入力されたときに通知を受け取るようにしたいと考えています。
• 説明：変更マネージャーとして、複数の選択肢からなる質問のリストを作成して、特定の変更に対するリスクのアセスメントを可能にしたいと考えています。

説明：インシデントが作成されると、通知が送信されます。

次のように記述してください。

説明：インシデント作成者として、関係者に影響を与えるインシデントが作成されたときに関係者に通知できるように、インシデントを作成するときに、事前定義された一連の関係者にメール通知を送信したいと考えています。

適切な受け入れ条件には、必要に応じて以下のことを含める必要があります。

• 使いやすさ：受け入れ条件には、使いやすさの測定値を必ず含めてください。この質問に対する回答方法を示してください：使いやすいですか？重要なのは、適切な測定値を特定し、それぞれが定量化可能であることを確認することです。
• 機能：プロジェクトの最後に実施する必要がある特定のユーザータスク、ビジネスプロセス、または機能を特定します。機能の要件は次のとおりです：ユーザーは複数のサイズから選択できます。
• エラー処理：エラーケースとそれぞれの処理方法を列挙します。たとえば、ユーザーが間違った順序でステップを実行した場合に、ソフトウェアはそれをどのように処理するのでしょうか？
• パフォーマンス：個々のユーザーの観点からシステムパフォーマンスをテストします。例：UI はレスポンシブですか？
• ストレステスト：多数のユーザー、トランザクション、またはクエリによりシステムがストレスを受けたときにシステムがどのように対応するかを説明します。受け入れ条件では、ストレステストの許容可能なしきい値を定義する必要があります。例：100 人のユーザーが同時にクエリを送信した場合、システムは 250 ミリ秒のしきい値以内に応答しますか？

説明：顧客として、クレジットカード情報の安全性を確保するために、安全な Web ベースのフォームを使用して書籍の注文と支払いを行いたいと考えています。

説明：顧客として、最新のステータスを得るために、インシデントにコメントが入力されたときに通知を受け取るようにしたいと考えています。

受け入れ条件：インシデントにコメントが入力されたときに、適切な担当者に通知されます。

適切な担当者が明確でないなど、テストに十分な詳細が提供されていないため、受け入れ条件は不十分です。