Acceptance Criteria dengan EARS Pattern: Cara Bikin Requirement Lebih Jelas dan Tidak Bikin Salah Paham

Di banyak proyek digital, masalahnya sering bukan karena timnya tidak bisa ngerjain. Masalahnya justru karena requirement-nya abu-abu.

Di awal kelihatannya simpel. Tapi begitu masuk ke design, development, QA, sampai revisi, baru terasa kalau banyak kalimat requirement yang ternyata terlalu umum, terlalu longgar, atau bisa ditafsir beda-beda.

Contoh yang sering muncul misalnya:

• "Sistem harus mudah digunakan."
• "Checkout harus berjalan lancar."
• "User harus bisa login dengan aman."

Semua kalimat itu terdengar benar. Tapi belum cukup jelas untuk dijadikan acuan kerja yang rapi. Designer bisa punya tafsir sendiri. Developer bisa punya tafsir sendiri. QA juga bisa punya tafsir sendiri. Hasil akhirnya bukan efisiensi, tapi debat interpretasi.

Apa Itu EARS Pattern?

EARS adalah singkatan dari Easy Approach to Requirements Syntax. Bahasa sederhananya: ini adalah cara menulis requirement atau acceptance criteria dengan pola kalimat yang lebih rapi, lebih jelas, dan lebih mudah diuji.

Jadi bukan metode yang ribet atau terlalu akademis. Justru kekuatan EARS ada di kesederhanaannya. EARS membantu kita mengubah requirement yang tadinya terlalu umum menjadi kalimat yang jelas, spesifik, bisa dites, dan minim multitafsir.

Kalau dibaca sepintas, format ini memang terlihat sederhana. Tapi justru di situ nilainya. Karena saat pola kalimatnya konsisten, requirement jadi lebih gampang dibaca dan lebih gampang diverifikasi.

Kenapa Acceptance Criteria Sering Gagal?

Acceptance criteria seharusnya jadi titik temu antara bisnis, product, design, developer, dan QA. Tapi dalam praktiknya, acceptance criteria sering ditulis terlalu cepat. Akhirnya isinya cuma niat, bukan instruksi yang benar-benar bisa diverifikasi.

Misalnya:

• "Sistem harus cepat."
• "User harus mendapat notifikasi."
• "Jika gagal, tampilkan error."

Kalimat seperti ini masih terlalu longgar. Cepat itu seberapa cepat? Notifikasi dikirim kapan? Error seperti apa? Setelah error muncul, sistem harus ngapain? Kalau hal-hal itu tidak dijelaskan, celah tafsir akan selalu muncul.

5 Pola Utama EARS yang Perlu Dipahami

Secara umum, EARS punya lima pola utama yang paling sering dipakai. Ini yang perlu dipahami dulu kalau ingin mulai menerapkannya.

1. Ubiquitous

Dipakai untuk aturan yang selalu berlaku.

• The system shall display the company logo on the login page.
• The system shall store all invoice timestamps in WIB.

2. Event-Driven

Dipakai saat ada kejadian tertentu yang memicu aksi.

• When the user clicks “Submit”, the system shall save the form data.
• When payment is confirmed, the system shall send an invoice email.

3. State-Driven

Dipakai saat perilaku sistem bergantung pada status tertentu.

• While the user is logged in, the system shall display the account menu.
• While the system is in maintenance mode, the system shall block new transactions.

4. Optional Feature

Dipakai untuk fitur yang sifatnya opsional.

• Where two-factor authentication is enabled, the system shall request a verification code during login.
• Where dark mode is enabled, the system shall use the dark color theme.

5. Unwanted Behavior

Dipakai untuk kondisi error, gangguan, atau situasi yang tidak diinginkan.

• If the payment fails, then the system shall show an error message and keep the cart intact.
• If the uploaded image exceeds the size limit, then the system shall reject the file and explain the reason.

Contoh Sebelum dan Sesudah Pakai EARS

Biar lebih terasa bedanya, lihat contoh ini.

Sekarang requirement-nya lebih jelas, lebih testable, dan tidak terlalu bergantung pada asumsi masing-masing orang.

Kenapa EARS Cocok untuk Tim yang Tidak Mau Ribet?

Banyak orang mengira requirement syntax itu cuma cocok untuk enterprise team besar atau dokumentasi yang terlalu formal. Padahal kenyataannya justru sebaliknya. EARS berguna karena dia membantu tim kecil sekalipun untuk tetap waras saat kerja cepat.

Kalau tim sering bergerak cepat, format seperti ini membantu agar revisi tidak muter-muter, ekspektasi klien lebih jelas, QA lebih gampang validasi, dan developer tidak kerja berdasarkan asumsi.

Kapan EARS Paling Berguna?

• ketika backlog atau ticket sering terasa kabur,
• ketika acceptance criteria terlalu umum,
• ketika dev dan non-dev sering beda pemahaman,
• ketika bug sering muncul karena requirement “katanya begitu”,
• atau ketika handoff dari product ke developer sering bikin revisi berulang.

Singkatnya, EARS bukan menambah beban. EARS justru mengurangi noise.

Hal yang Perlu Diingat Saat Pakai EARS

• Jangan tetap menulis kalimat yang kabur walaupun formatnya sudah benar.
• Fokus pada perilaku yang benar-benar bisa diverifikasi.
• Jangan memaksakan satu requirement untuk terlalu banyak aksi sekaligus.
• Bedakan jalur normal dan jalur error sejak awal.

Penutup

Kalau acceptance criteria masih sering ditulis seperti “harus mudah”, “harus bagus”, atau “harus aman”, maka kemungkinan besar masalahnya bukan di eksekusi, tapi di kejernihan requirement.

EARS memberi cara yang sederhana untuk memperbaiki itu. Dengan pola yang lebih rapi, requirement jadi lebih mudah dipahami, lebih mudah disepakati, lebih mudah dikerjakan, dan lebih mudah diuji.

Pada akhirnya, EARS bukan soal terlihat lebih formal. EARS soal membuat semua orang membaca hal yang sama dan memahami hal yang sama. Dan dalam proyek digital, itu nilainya besar.