Batasi masalah

Pertanyaan

Fitur apa yang sebenarnya harus ada, dan apa yang boleh gagal?

Hasil yang bisa diamati: kamu bisa menulis satu halaman batasan masalah yang memuat alur pengguna, kebutuhan fungsional, kebutuhan nonfungsional dengan angka, dan daftar hal yang sengaja tidak dikerjakan.

Prasyarat dan contoh

Kamu sudah nyaman dengan HTTP dan operasi CRUD. Tidak perlu pengalaman sistem terdistribusi.

Bayangkan sebuah alat internal untuk memperpendek tautan. Permintaannya: "buat seperti bit.ly, tapi untuk tim kami". Kalimat itu tidak bisa dikerjakan. Berapa lama tautan hidup? Apakah perlu analitik klik? Apakah tautan bisa dihapus? Apakah harus bisa dipakai dari aplikasi lain? Tanpa jawaban, setiap percakapan berikutnya berubah menjadi perdebatan fitur, bukan keputusan teknis.

Membatasi masalah bukan menolak fitur. Ini memilih fitur mana yang membentuk arsitektur, dan mana yang bisa ditambahkan nanti tanpa membongkar fondasi.

Mekanisme

Kerjakan empat lapis berikut secara berurutan. Jangan melompat ke teknologi.

1. Alur pengguna. Tuliskan jalur terpendek dari niat ke hasil. Untuk URL shortener:

1. Pengguna menempel URL panjang.
2. Sistem mengembalikan tautan pendek yang unik.
3. Orang lain membuka tautan itu dan diarahkan ke URL asli.

Tiga langkah itu sudah memberi tahu dua operasi inti: menulis pemetaan, dan membaca pemetaan. Semua fitur lain adalah tambahan di sekitar dua operasi ini.

2. Kebutuhan fungsional. Nyatakan perilaku yang bisa diperiksa, bukan solusi. "Pengguna bisa memperpendek URL" adalah kebutuhan. "Sistem memakai Redis" bukan kebutuhan, melainkan pilihan implementasi yang mungkin belum perlu.

3. Kebutuhan nonfungsional. Ubah kata sifat menjadi angka dan satuan. "Cepat" bukan kebutuhan. "Redirect selesai di bawah 100 ms pada p99, untuk 200 request per detik saat puncak" adalah kebutuhan. Sertakan juga ketersediaan, durabilitas, konsistensi, dan batas biaya.

4. Hal yang tidak dicakup. Tulis eksplisit. Contoh: tanpa analitik klik, tanpa antarmuka admin, tanpa tautan kustom, tanpa API publik, tanpa retensi selamanya. Daftar ini melindungi keputusan desain: tanpa analitik, jalur baca tetap murni dan murah.

Urutan ini penting karena satu kebutuhan nonfungsional dapat membatalkan sebuah keputusan fungsional. Jika kamu menyatakan "tautan harus tetap bisa dibuka setelah 10 tahun", penyimpanan menjadi bagian dari fondasi, bukan detail nanti.

Saat rancangan ini gagal

Kegagalan paling umum bukan salah hitung, melainkan batasan yang tidak jujur.

• Non-goals yang sebenarnya wajib. Kamu menulis "tanpa analitik", lalu produk memintanya di minggu kedua. Jalur tulis yang tadinya satu operasi kini butuh penulisan kedua, dan kamu sudah memilih skema yang tidak mendukungnya.
• Kebutuhan yang ditulis sebagai solusi. "Harus pakai microservices" mengunci arsitektur sebelum kendala diketahui. Ketika kendala sebenarnya adalah query lambat, keputusan itu tidak membantu.
• Batasan tanpa konsekuensi. Menulis "harus tersedia 99,99%" tanpa menyebut apa yang terjadi saat gagal membuat target itu tidak bisa dipakai untuk memilih mekanisme apa pun.

Contoh tandingan: sebuah tim menetapkan "tanpa antrean" untuk menjaga kesederhanaan. Setelah volume naik, pekerjaan pengiriman email memblokir request pengguna. Batasan itu sebenarnya salah sejak awal karena mengabaikan kebutuhan respons cepat. Yang seharusnya dinyatakan adalah "respons pengguna tidak menunggu pekerjaan pihak ketiga" — dan itu memang mengizinkan antrean sebagai konsekuensi, bukan sebagai mode.

Latihan

Ambil shortener internal dengan konteks berikut: 40 engineer, dipakai untuk dokumentasi internal, tautan dibagikan di chat.

Tuliskan:

1. tiga alur pengguna,
2. empat kebutuhan fungsional yang bisa diperiksa,
3. tiga kebutuhan nonfungsional dengan angka dan satuan,
4. dua hal yang secara eksplisit tidak dicakup.

Lihat pembahasan+

Contoh jawaban yang memadai:

Alur: (a) membuat tautan dari URL dokumen, (b) membuka tautan dan diarahkan, (c) mencabut tautan yang salah.

Fungsional: membuat kode unik untuk URL http/https; mengarahkan kode ke URL asli; menolak URL non-http; mencabut tautan sehingga tidak lagi mengarah.

Nonfungsional: redirect p95 di bawah 100 ms pada 20 request per detik; tautan aktif tetap bisa dibuka setelah 2 tahun; kode unik tidak boleh bertabrakan pada 1 juta tautan.

Tidak dicakup: analitik klik, tautan kustom, aplikasi seluler, API publik, retensi tak terbatas.

Perhatikan bahwa setiap nonfungsional punya satuan, dan setiap non-goal menghapus satu jalur desain. Jawaban yang baik bisa dibaca oleh engineer lain tanpa bertanya "maksudnya apa?".

Terkait

• Lanjut ke M01.02 Jelaskan beban kerja untuk mengubah batasan ini menjadi angka.
• Lab L01 memakai tiga beban kerja berbeda untuk menunjukkan bahwa batasan yang sama bisa punya kendala pertama yang berbeda.
• Rancangan D01 (URL shortener satu mesin) dan D02 (versi berkembang) belum tersedia.

Catatan

• Asumsi: tim kecil, tidak ada kebutuhan kepatuhan khusus, dan URL yang dipendekkan bukan rahasia.
• Yang tidak dibahas: pemilihan bahasa/framework, model data, dan strategi keamanan tautan.
• Metode: praktik umum penulisan requirement, bukan kutipan dari satu sumber tertentu.
• Terakhir ditinjau: 25 Oktober 2026.