Menulis kebutuhan dari perubahannya

Butir kebutuhan yang menyentuh lima unit terpisah bukan kebutuhan yang besar, melainkan batas kode yang dipotong menurut lapisan teknis.

Sebaiknya baca lebih dulu: Batas satu unit kode.

Materi sebelumnya berhenti pada satu pengamatan: satu butir kebutuhan yang menyentuh lima unit terpisah adalah pertanda batas kodenya dipotong menurut lapisan teknis alih alih menurut permintaan yang datang. Pelajaran ini melanjutkannya dari sisi yang berlawanan. Kalau batas kode dapat dinilai dari bentuk kebutuhannya, maka kebutuhan yang ditulis dengan benar adalah alat perancangan, bukan sekadar catatan permintaan.

IngatMenyelesaikan materi tingkat expert tidak menggeser satu pun rating sumbu, dan tidak ada satu pun test yang dapat memeriksa keputusan di tingkat ini. Yang dilatih penilaian, bukan jawaban.

Kebutuhan yang menyebut solusinya sudah kehilangan gunanya

Kesalahan yang paling sering terjadi bukan kebutuhan yang kabur, melainkan kebutuhan yang terlalu konkret pada bagian yang salah. Butir yang menyebut tabel, endpoint, dan nama kolom sudah memutuskan rancangannya sebelum satu pun orang menanyakan apakah rancangan itu perlu. Yang tersisa untuk dinilai hanya apakah kodenya sesuai tulisan, dan itu pertanyaan yang selalu terjawab ya.

Menyebut solusinya

Tambahkan kolom is_verified pada tabel users.
Buat endpoint POST /users/:id/verify.
Kirim email lewat antrean verification_queue.

Menyebut perubahan yang diminta

Pengguna yang belum membuktikan alamat emailnya
tidak boleh muncul di papan peringkat publik.

Pembuktian itu berlaku selamanya dan tidak dapat dicabut
pengguna sendiri.

Kolom kiri tidak dapat ditolak maupun diperdebatkan; ia hanya dapat dikerjakan. Kolom kanan dapat ditanyakan, dan pertanyaan pertamanya sudah berharga: apakah papan peringkat satu satunya tempat yang terpengaruh? Perhatikan juga bahwa kolom kanan tidak menyebut satu pun tabel, tetapi justru dari situlah batas unitnya dapat ditentukan.

Tiga bagian yang wajib ada

  • Keadaan sekarang, disebutkan apa adanya. Tanpa ini tidak ada cara mengetahui apakah butirnya sudah selesai atau memang sudah begitu sejak awal.
  • Keadaan yang diminta, dinyatakan sebagai yang dapat dilihat pengguna, bukan sebagai yang berubah di basis data.
  • Batas yang sengaja tidak dikerjakan. Ini bagian yang paling sering hilang dan paling mahal ketika hilang.

Bagian ketiga menuntut penjelasan tersendiri. Kebutuhan tanpa batas selalu tumbuh, sebab setiap orang yang membacanya menambahkan tafsirannya sendiri secara diam diam. Menuliskan apa yang TIDAK dikerjakan mengubah tafsiran diam diam itu menjadi pertanyaan terbuka, dan pertanyaan terbuka dapat dijawab sebelum kodenya ditulis alih alih sesudah.

Tanpa batas

Pengguna dapat mengganti nama tampilannya.

Dengan batas yang disengaja

Pengguna dapat mengganti nama tampilannya.

TIDAK termasuk: riwayat nama lama, pemberitahuan
kepada orang lain, dan pemeriksaan nama kembar.
Nama kembar diizinkan untuk sekarang.

Kolom kiri satu baris dan tampak selesai. Yang membacanya di tim basis data akan mengira riwayat perlu disimpan, yang membacanya di tim notifikasi akan mengira ada pemberitahuan, dan keduanya benar menurut tulisan itu. Kolom kanan menutup ketiganya, dan yang penting bukan jawabannya melainkan bahwa jawabannya sudah diputuskan seseorang.

Menguji kebutuhan sebelum kodenya ada

Kebutuhan yang baik dapat dijatuhkan tanpa membuka satu berkas pun. Caranya menyusun satu keadaan konkret lalu menanyakan apakah tulisannya menentukan hasilnya. Kalau ada dua jawaban yang sama sama sah menurut tulisannya, butirnya belum selesai, dan menemukannya sekarang jauh lebih murah daripada menemukannya lewat laporan pengguna.

  • Ambil satu keadaan batas: nilai kosong, nilai nol, dua kejadian bersamaan, atau pengguna yang sudah pernah melakukannya.
  • Tanyakan apa yang seharusnya terjadi menurut tulisannya, bukan menurut dugaan Anda.
  • Kalau tulisannya membolehkan dua hasil, tambahkan satu baris yang memilih salah satunya beserta alasannya.

Periksa pemahaman

Sebuah butir kebutuhan berbunyi: "Tambahkan kolom last_login pada tabel users dan tampilkan di halaman profil." Mana kelemahan yang paling menentukan?

  • Kebutuhan menyebut perubahan yang diminta, bukan tabel yang disentuh.
  • Tiga bagian wajib: keadaan sekarang, keadaan yang diminta, dan batas yang sengaja tidak dikerjakan.
  • Batas yang tidak dituliskan akan ditafsirkan diam diam oleh setiap pembacanya, dan setiap tafsiran itu sah menurut tulisannya.
  • Uji butirnya dengan satu keadaan batas. Dua hasil yang sama sah berarti butirnya belum selesai.