Keuntungan:
- Kemampuan untuk mengubah permintaan bisnis yang tidak jelas menjadi persyaratan perangkat lunak dan cerita pengguna yang jelas dan dapat diuji dengan dukungan AI
- Kemampuan untuk membandingkan pro dan kontra desain sistem, model data, dan keputusan arsitektur secara terstruktur dengan AI
- Kemampuan untuk memvalidasi secara kritis usulan desain AI terhadap persyaratan, skalabilitas, dan batasan
Mayoritas proyek perangkat lunak gagal bukan karena kode yang buruk, namun karena persyaratan yang disalahpahami. Permintaan satu kalimat seperti “Izinkan pengguna mengunduh laporan” meninggalkan banyak pertanyaan yang belum terjawab: Dalam format apa? Siapa yang bertanggung jawab? Berapa banyak catatan? Bagaimana jika lambat? Analisis persyaratan (menerjemahkan permintaan bisnis menjadi kebutuhan teknis yang jelas dan dapat diuji) dan desain perangkat lunak (membangun struktur di atas kertas untuk memenuhi kebutuhan ini) adalah tahap di mana kesalahan paling mahal dicegah sebelum menulis kode. Dalam unit ini, kita akan belajar menggunakan AI sebagai “mitra pemikiran” pada tahap ini: mitra yang mengungkap ketidakpastian, memilah-milah pilihan, namun menyerahkan keputusan akhir kepada Anda.
AI menghasilkan dua nilai besar di sini. Pertama, ia menanyakan pertanyaan yang Anda lewati; Ini memunculkan asumsi tersembunyi dan kasus tepi dalam permintaan. Kedua, dengan cepat membuat tabulasi pro dan kontra dari keputusan desain. Namun itulah bahayanya: AI akan memberikan rekomendasi umum sebagai "praktik terbaik" tanpa sepenuhnya mengetahui konteks Anda (anggaran, tim, sistem yang ada, batasan hukum). Tugas Anda adalah menyaring nasihat ini berdasarkan kebenaran Anda sendiri.
Konsep: Kisah pengguna: Kalimat pendek yang mengungkapkan kebutuhan dalam bentuk "...sebagai, saya ingin dapat...karena...". Kriteria penerimaan: Kondisi yang dapat diuji yang harus dipenuhi agar suatu pekerjaan dianggap "selesai". Persyaratan non-fungsional: Persyaratan yang berkaitan dengan "bagaimana perilakunya" dan bukan "apa yang akan dilakukannya", seperti kecepatan, keamanan, skalabilitas.
Dari Permintaan Tidak Jelas hingga Persyaratan yang Dapat Diuji
Persyaratan yang baik dapat diukur dan diverifikasi. Bukan "biarkan sistemnya cepat", tapi "biarkan hasil pencarian kembali dalam 500 ms". Berikut cara langkah demi langkah menggunakan AI untuk mempersempit ketidakpastian:
- Berikan permintaan apa adanya dan buat pertanyaannya. Mintalah AI bukan untuk solusinya, tetapi pertama-tama "cantumkan segala sesuatu yang tidak jelas dalam permintaan ini sebagai pertanyaan".
- Anda memberikan jawabannya. Hanya Anda yang mengetahui konteksnya; Jawab pertanyaan AI dengan batasan bisnis Anda yang sebenarnya.
- Apakah itu diterjemahkan ke dalam cerita pengguna dan kriteria penerimaan. Terjemahkan kebutuhan yang telah diklarifikasi menjadi item yang dapat diuji.
- Tambahkan kasus tepi dan skenario negatif. "Hasil kosong", "pengguna tidak sah", "file terlalu besar" dll.
Permintaan ekstraksi ambiguitas: "Kami akan menerjemahkan permintaan bisnis berikut ke dalam persyaratan perangkat lunak. Jangan mengusulkan solusi dulu. Pertama, ekstrak SEMUA ambiguitas dan asumsi tersembunyi yang tidak terjawab dalam permintaan ini sebagai daftar pertanyaan. Kelompokkan pertanyaan di bawah judul berikut: cakupan, pengguna/otoritas, volume data, kinerja, kondisi kesalahan, keamanan. Permintaan: 'Izinkan pengguna mengunduh riwayat pesanan sebagai laporan.'"
Permintaan cerita pengguna + kriteria penerimaan: "Bagilah kebutuhan yang diklarifikasi berikut ke dalam cerita pengguna yang sesuai dengan prinsip INVEST. Tulis 3-5 kriteria penerimaan yang dapat diuji untuk setiap cerita (dalam format Mengingat-Kapan-Lalu). Tambahkan setidaknya 2 skenario negatif (akses tidak sah, data kosong). Kebutuhan: [tulis kebutuhan yang diklarifikasi di sini]"
Membandingkan Keputusan Desain dengan AI
Desain adalah sebuah trade-off yang konstan: kecepatan versus fleksibilitas, kesederhanaan versus skalabilitas? AI menempatkan trade-off ini ke dalam spreadsheet yang cepat. Misalnya, untuk fitur "kirim pemberitahuan", Anda dapat memperdebatkan apakah akan menggunakan pendekatan sinkron (kirim sesuai permintaan) atau asinkron (antrian, kirim di latar belakang).
Permintaan perbandingan desain: "Saya sedang merancang fitur 'kirim pemberitahuan email ke pengguna'. Bandingkan dua pendekatan: (A) pengiriman sinkron selama permintaan HTTP, (B) pengiriman asinkron di latar belakang dengan meletakkannya di antrean pesan. Buatlah tabel pada sumbu berikut: waktu tunggu pengguna, toleransi kesalahan, kompleksitas, biaya infrastruktur, kesulitan dalam debugging. Ringkas dalam 2 kalimat mana yang akan saya pilih pada akhirnya dalam hal ini. Jangan membuat keputusan untuk saya."
sumbu
transmisi sinkron
Asinkron (antrian)
Waktu tunggu pengguna
Lama (menunggu kiriman)
Pendek (segera kembali)
Toleransi kesalahan
Rendah (permintaan meledak jika pengiriman meledak)
Tinggi (bisa dicoba lagi)
kompleksitas
rendah
Sedang-tinggi (infrastruktur antrian)
Biaya infrastruktur
rendah
Diperlukan komponen tambahan
Dimana itu cocok
Volume rendah, aplikasi sederhana
Volume tinggi, pengiriman kritis
Tip: Memberi tahu AI “jangan ambil keputusan untuk saya, tunjukkan saja pilihan dan ketentuannya” akan memaksa Anda untuk berpikir dan mengurangi risiko menerima saran secara membabi buta. Keputusan desain terbaik adalah keputusan yang dibuat oleh orang yang mengetahui konteks Anda (Anda).
Prompt Lemah / Prompt Kuat
LEMAH: "Rancang database untuk sistem pemesanan." (Hasil: skala mana, hubungan mana, batasan mana yang tidak jelas; skema umum yang tidak realistis.) KUAT: "Sarankan rancangan model data untuk e-niaga kecil. Entitas: Pelanggan, Pesanan, Produk, Barang Pesanan. Batasan: bisa ada banyak produk dalam satu pesanan; harga produk dapat berubah seiring waktu, namun harga saat ini harus dipertahankan dalam pesanan sebelumnya; ~500 pesanan per hari diharapkan. Hubungan dan mengapa "Jelaskan bahwa Anda membuat keputusan. Tentukan bagaimana Anda memecahkan masalah riwayat harga. Berikan sebagai daftar entitas dan bidang, bukan kode."
Perbedaan dari prompt yang kuat; skala (500 pesanan per hari), aturan bisnis (harga sebelumnya harus dipertahankan) dan format output yang diinginkan. Satu kalimat seperti "Harga di masa lalu harus dipertahankan" benar-benar mengubah desain; Jika Anda tidak menentukannya, AI akan menghasilkan diagram yang tidak akurat namun tampak masuk akal.
Kasus Mini
Kasus 1 — Asumsi tersembunyi. Sebuah tim langsung mengkodekan permintaan "pengguna dapat mengunggah foto profil". Tim lain bertanya kepada AI tentang ketidakpastian: "ukuran maksimum? format yang diizinkan? kontrol konten yang tidak pantas? hapus foto lama?" Ini menghasilkan 8 pertanyaan seperti. Tim pertama mengetahui masalah produksi ketika file berukuran 20 MB memenuhi server; Tim kedua menyelesaikannya dalam desain.
Kasus 2 — Asumsi skala salah. AI mengusulkan lapisan caching yang kompleks untuk fitur pelaporan. Ketika insinyur menunjukkan bahwa data sebenarnya hanya 30 laporan per hari, AI menyederhanakan saran tersebut. Tidak menentukan skalanya menimbulkan biaya kerumitan yang tidak perlu; menentukan menghemat 2 minggu pekerjaan yang tidak perlu.
Kasus 3 — Kesenjangan kriteria penerimaan. “Apa yang terjadi jika pembayarannya gagal?” Karena pertanyaan tidak pernah ditanyakan, sistem pemesanan akan tetap menandai pesanan sebagai "dikonfirmasi" jika pembayaran gagal. Daftar skenario negatif yang dihasilkan oleh AI mampu menangkap kesenjangan ini; Kriteria penerimaan 1 baris mencegah kehilangan uang nyata.
Kesalahan umum
- Melewati permintaan langsung ke kode. Kode yang ditulis sebelum ambiguitas diselesaikan dengan cepat menyelesaikan masalah yang salah.
- Secara membabi buta mengambil “praktik terbaik” AI. Jika Anda tidak menentukan konteks Anda (skala, anggaran, tim), rekomendasi tersebut tidak akan berhasil untuk Anda.
- Melewatkan persyaratan non-fungsional. Jika kecepatan, keamanan dan skala tidak ditentukan, desain tidak akan lengkap.
- Hanya memikirkan skenario bahagia. Skenario negatif seperti data kosong, pengguna tidak sah, status kesalahan harus disertakan dalam desain.
- Mendelegasikan keputusan kepada AI. AI menghasilkan pilihan; Anda memutuskan trade-off mana yang sesuai dengan bisnis Anda.
Singkatnya
Analisis dan desain persyaratan adalah tahap di mana kesalahan termurah ditangkap. Di sini, AI menghasilkan pertanyaan yang mengungkapkan ketidakpastian, menyusun cerita pengguna dan kriteria penerimaan, serta trade-off desain grafik. Namun hanya Anda yang mengetahui konteksnya; Tugas Anda adalah memfilter rekomendasi AI berdasarkan skala, anggaran, tim, dan batasan hukum, lalu membuat keputusan akhir. Disiplin “jangan ambil keputusan untuk saya, tunjukkan pilihannya” akan menghasilkan desain yang lebih baik dan pembelajaran yang lebih mendalam.
Tugas aplikasi
Pilih permintaan pekerjaan satu kalimat dari konteks Anda. Pertama, terapkan perintah ambiguitas pada AI dan jawab pertanyaan dengan batasan Anda yang sebenarnya. Kemudian terjemahkan kebutuhan yang telah diklarifikasi menjadi setidaknya 2 cerita pengguna dan 3 kriteria penerimaan untuk masing-masing cerita; Sertakan setidaknya 1 skenario negatif. Terakhir, buat tabel perbandingan untuk keputusan desain (sinkron/asinkron, struktur tabel, dll.) dan tulis keputusan Anda sendiri dalam 2 kalimat.
daftar periksa
- [] Saya menghilangkan ambiguitas sebagai pertanyaan sebelum meneruskan permintaan ke dalam kode.
- [ ] Saya memberikan konteksnya (skala, otoritas, kinerja, batasan hukum) pada AI.
- [] Saya membagi cerita pengguna ke dalam kriteria penerimaan yang dapat diuji.
- [ ] Saya menambahkan setidaknya satu skenario sisi bawah/tepi.
- [ ] Saya mengevaluasi keputusan desain dengan tabel trade-off.
- [ ] Saya membuat keputusan akhir berdasarkan konteks saya, saya tidak menyerahkannya kepada AI.