Acceptance Criteria dengan EARS Pattern: Cara Menulis Requirement yang Jelas, Testable, dan Minim Salah Paham

Acceptance criteria adalah batas jelas yang menjawab apakah sebuah fitur sudah selesai atau belum. Masalahnya, banyak acceptance criteria ditulis seperti harapan umum, bukan perilaku sistem yang bisa diverifikasi.

• EARS adalah singkatan dari Easy Approach to Requirements Syntax.
• Tujuan EARS adalah membuat requirement lebih konsisten, lebih spesifik, dan lebih mudah diuji.
• Format ini cocok untuk product manager, business analyst, designer, developer, QA, sampai owner bisnis.
• EARS membantu memisahkan kondisi normal, kondisi error, status sistem, dan fitur opsional sejak awal.

Banyak masalah delivery bukan lahir dari kemampuan teknis yang kurang, tetapi dari kalimat requirement yang terlalu longgar. Di awal terlihat sepele, tetapi begitu masuk desain, development, QA, dan revisi, celah tafsir mulai muncul.

Kalimat seperti "checkout harus lancar", "login harus aman", atau "dashboard harus mudah dipakai" terdengar benar, tetapi belum memberi pegangan kerja. Lancar itu diukur dari apa? Aman berarti mekanisme apa? Mudah dipakai untuk role mana dan skenario apa?

Acceptance criteria yang baik bukan sekadar menjelaskan niat fitur, tetapi menjelaskan perilaku yang bisa dibuktikan.

EARS Pattern adalah pola penulisan requirement dengan struktur kalimat yang sederhana. Ia membantu tim menulis apa yang harus dilakukan sistem, kapan perilaku itu terjadi, dan dalam kondisi apa perilaku tersebut berlaku.

Nilai utamanya bukan membuat dokumen terlihat formal. Nilainya ada pada konsistensi. Ketika semua orang memakai pola yang sama, requirement lebih mudah dibaca, lebih mudah ditanya ulang, dan lebih mudah diubah menjadi test case.

• Tulis aktor atau pemicu dengan jelas.
• Tulis kondisi yang harus terpenuhi.
• Tulis respons sistem yang bisa diamati.
• Hindari kata sifat yang tidak punya ukuran, seperti bagus, cepat, aman, mudah, atau rapi.

Dalam praktik sehari-hari, ada lima pola EARS yang paling sering dipakai. Anda tidak harus menghafalnya seperti rumus kaku, tetapi memahami fungsi masing-masing pola akan membuat ticket kerja jauh lebih jelas.

• Ubiquitous: aturan yang selalu berlaku. Contoh: The system shall store all transaction timestamps in WIB.
• Event-driven: perilaku yang terjadi setelah event tertentu. Contoh: When the user clicks Pay, the system shall create a payment session.
• State-driven: perilaku saat sistem berada dalam status tertentu. Contoh: While the order is awaiting payment, the system shall show the payment deadline.
• Optional feature: perilaku ketika fitur tertentu aktif. Contoh: Where two-factor authentication is enabled, the system shall request a verification code after password validation.
• Unwanted behavior: respons saat kondisi gagal atau tidak diinginkan. Contoh: If payment authorization fails, then the system shall keep the cart active and show the failure reason.

Cara paling cepat memahami EARS adalah membandingkan requirement kabur dengan versi yang sudah diberi kondisi, pemicu, dan respons sistem.

• Sebelum: User harus bisa login dengan aman.
• Sesudah: When the user enters valid credentials, the system shall authenticate the user and redirect them to the dashboard.
• Sesudah: If the user enters an invalid password five times within ten minutes, then the system shall lock login attempts for 15 minutes and show the unlock time.
• Sebelum: Admin harus mendapat notifikasi kalau ada pesanan baru.
• Sesudah: When a paid order is created, the system shall send a notification to the admin dashboard and include order ID, customer name, total amount, and payment status.

Perbedaannya terasa jelas. Versi pertama masih mengandalkan asumsi, sedangkan versi EARS memberi bahan untuk desain UI, implementasi backend, validasi QA, dan diskusi scope.

Kalau requirement awal masih mentah, jangan langsung dipaksa masuk ke template. Pecah dulu maksud bisnisnya menjadi skenario kecil yang bisa diamati.

1. 1Tentukan hasil bisnis atau user outcome yang ingin dicapai.
2. 2Tulis skenario normal: apa yang terjadi ketika semuanya berjalan benar.
3. 3Tulis skenario gagal: input salah, pembayaran gagal, koneksi putus, data tidak ditemukan, atau permission tidak cukup.
4. 4Tentukan status yang memengaruhi perilaku sistem, misalnya logged in, unpaid, archived, suspended, atau maintenance.
5. 5Tulis setiap skenario dalam satu kalimat EARS yang hanya memuat satu perilaku utama.
6. 6Uji kalimatnya dengan pertanyaan: apakah QA bisa membuktikan ini pass atau fail tanpa bertanya lagi?

Sebelum ticket masuk sprint atau diberikan ke developer, cek apakah acceptance criteria sudah cukup operasional. Checklist sederhana ini biasanya langsung menurunkan revisi yang tidak perlu.

• Ada kondisi atau event yang jelas.
• Ada respons sistem yang bisa dilihat, disimpan, dikirim, dihitung, atau diverifikasi.
• Tidak memakai kata sifat tanpa ukuran.
• Tidak menggabungkan terlalu banyak perilaku dalam satu requirement.
• Jalur sukses dan jalur error dipisahkan.
• Data penting disebut eksplisit, misalnya field yang wajib tampil, status yang berubah, atau pesan error yang perlu diberikan.
• Requirement tidak bertentangan dengan policy, security, analytics, atau flow lain yang sudah ada.

EARS bukan jaminan requirement otomatis bagus. Format yang benar masih bisa menghasilkan kalimat buruk kalau isinya tetap kabur.

• Memakai EARS tetapi respons sistemnya masih abstrak, misalnya "the system shall be user friendly".
• Menulis satu kalimat yang memuat banyak aksi sekaligus sehingga sulit dites.
• Tidak menyebut kondisi batas, seperti limit ukuran file, jumlah percobaan login, atau waktu kedaluwarsa.
• Mencampur requirement bisnis dengan detail solusi yang belum disepakati.
• Melupakan negative path, padahal bug paling sering muncul saat input atau state tidak ideal.

EARS paling terasa manfaatnya saat sebuah tim sering bergerak cepat, banyak handoff, atau sering mengalami revisi karena makna requirement berbeda antara product, design, dev, QA, dan stakeholder bisnis.

• Backlog terasa penuh tetapi banyak ticket belum siap dikerjakan.
• QA sering bertanya ulang karena acceptance criteria tidak punya ukuran pass atau fail.
• Developer sering mengambil keputusan sendiri karena requirement tidak menyebut kondisi edge case.
• Stakeholder merasa fitur sudah benar secara teknis, tetapi belum sesuai ekspektasi bisnis.
• Tim ingin membuat brief kerja yang rapi tanpa membuat dokumen requirement terlalu berat.

Untuk mulai memakai EARS, gunakan template kecil di setiap ticket. Tidak perlu membuat dokumentasi panjang; cukup pastikan skenario utama dan skenario gagal tertulis dengan jelas.

1. 1Context: jelaskan masalah user atau bisnis dalam satu paragraf pendek.
2. 2Happy path: tulis 2-4 acceptance criteria dengan pola When atau While.
3. 3Error path: tulis kondisi gagal dengan pola If, then.
4. 4Optional behavior: tulis pola Where hanya jika fitur bergantung pada konfigurasi atau paket tertentu.
5. 5QA note: sebutkan data uji, role user, atau batasan teknis yang wajib diperiksa.

EARS Pattern membantu tim mengganti requirement yang penuh asumsi menjadi instruksi kerja yang bisa dibaca bersama. Dampaknya sederhana tetapi besar: diskusi lebih fokus, scope lebih jelas, QA lebih mudah membuat test case, dan developer tidak terlalu sering menebak maksud ticket.

Mulailah dari satu kebiasaan kecil: setiap acceptance criteria harus punya kondisi, perilaku sistem, dan bukti yang bisa diverifikasi. Dari sana, kualitas requirement biasanya naik tanpa perlu proses yang rumit.