回答

ビジネスアナリストは、すべてのプロジェクト参加者（クライアント、開発者、テスター）に対して明確で一義的に理解できるように、各要件の受け入れ基準（acceptance criteria）を形式化する必要があります。そのために、Gherkin（Given-When-Then）記法、チェックリスト、ユースケースなどの仕様技術を活用します。アナリストは、要件文書に基準を文書化し、各要件には作業が適切に実行されたことを確認するための客観的条件のセットがあることを確保します。

主な特徴:

• ビジネスおよび技術用語を用いた明確で測定可能な基準の定義。
• 開発開始前にクライアントが基準の確認に参加する。
• ユーザーストーリー、仕様書、テストケースに基準を組み込む。

騙しの質問。

追加の受け入れ基準なしで、要件を説明するためにユーザーストーリーのみを使用してもいいですか？

いいえ、明示的な受け入れ基準がないユーザーストーリーはあまりにも抽象的で、異なる解釈をされる可能性があります。基準が必要な理由は、要件が正しく実装されたかどうかを理解するためです。

受け入れ基準に非機能要件（例えば、パフォーマンス）を含める必要がありますか？

はい、非機能要件も基準に形式化する必要があり、そうしないと、見逃したり、完全に実装されなかったりするリスクがあります。

受け入れ基準を承認すべきは、ビジネスアナリストだけですか？

いいえ、基準の合意は必ずクライアントと、可能であれば開発チームと行う必要があり、誤解を最小限に抑えるためです。

よくある間違いとアンチパターン

• クライアントとの基準の合意を無視する。
• 基準を開発チームの裁量に任せる。
• 作業開始後に基準を遅れて追加する。

実際の例

ネガティブケース: ビジネスアナリストがクライアントと受け入れ基準を合意せず、開発者が要件を独自に解釈しました。 利点: 迅速な開発で、会議がプロセスを遅らせることはありませんでした。 欠点: リリース後、機能の70%が実際の期待と一致せず、対立が発生しました。

ポジティブケース: アナリストが受け入れ基準を形式化し、両方の当事者と合意し、ユーザーストーリーに添付しました。 利点: クライアントとチームとの間に理解が生まれ、リリース後のバグが最小限に。 欠点: 始めに合意に少し多くの時間がかかりました。