Keuntungan:
- Kemampuan untuk membedakan persyaratan fungsional dan non-fungsional serta menulis ekspresi kebutuhan yang jelas dan terukur dengan dukungan kecerdasan buatan
- Kemampuan untuk menggunakan kecerdasan buatan dengan petunjuk terstruktur untuk mengekstrak cerita pengguna, kriteria penerimaan, dan batas cakupan dari catatan wawancara
- Biasakan memeriksa persyaratan yang dihasilkan AI untuk mengetahui adanya ambiguitas, kontradiksi, dan aturan yang hilang dan mengonfirmasinya dengan pemangku kepentingan
Analisis persyaratan adalah tugas untuk mendefinisikan secara lengkap, jelas, dan dapat diverifikasi apa yang harus dilakukan suatu sistem. Ini adalah salah satu tahapan di mana spesialis MIS menghasilkan nilai paling besar; karena kesalahan di sini tumbuh secara eksponensial di akhir proyek. Ada dua tipe dasar analisis kebutuhan. Persyaratan fungsional menggambarkan pekerjaan yang harus dilakukan sistem: “Sistem harus mengirim email kepada pelanggan ketika mengkonfirmasi pesanan.” Persyaratan non-fungsional menggambarkan bagaimana sistem seharusnya: kualitas seperti kinerja, keamanan, kegunaan dan aksesibilitas. "Layar laporan akan terbuka dalam waktu kurang dari 2 detik pada beban rata-rata" adalah persyaratan non-fungsional.
Persyaratan yang baik mempunyai tiga karakteristik: jelas (memiliki interpretasi tunggal), dapat diukur (memiliki ambang batas yang dapat diuji), dan dapat ditelusuri (jelas dari mana kebutuhan bisnis tersebut berasal). "Sistemnya harus cepat" tidak memenuhi satu pun dari hal ini; “cepat” itu subjektif, tidak bisa diukur, tidak bisa diuji. Pada tahap ini, AI merupakan bantuan yang ampuh dalam menyusun persyaratan dan menangkap kata-kata yang ambigu; namun hanya pemangku kepentingan yang memutuskan aturan bisnis mana yang nyata.
Kisah Pengguna dan Kriteria Penerimaan
Format umum dalam penulisan persyaratan modern adalah kisah pengguna: "Sebagai [peran], untuk [tujuan], saya menginginkan [fitur]." Contoh: "Sebagai perwakilan penjualan, saya ingin perhitungan diskon dari layar ponsel sehingga saya dapat membuat penawaran harga dengan cepat di lapangan." Ceritanya pendek dan berorientasi bisnis; Ini tidak memaksakan solusi teknis.
Setiap cerita harus memiliki kriteria penerimaan: kondisi yang dapat diuji yang harus dipenuhi agar cerita tersebut dianggap "baik". Pola yang sering digunakan adalah pola "Diberikan/Kapan/Lalu": "Diberikan: pelanggan berada di segmen VIP. Kapan: memesan lebih dari 10.000 TL. Kemudian: sistem menerapkan diskon 5%." Pola ini menghilangkan ambiguitas karena secara jelas menghubungkan kondisi dan hasil yang diharapkan.
Tip: Saat menulis cerita pengguna ke kecerdasan buatan, pastikan untuk mengatakan "hasilkan setidaknya 2 kriteria penerimaan dalam format Diberikan/Kapan/Lalu untuk setiap cerita." Ketika model dipaksa untuk menghasilkan tolok ukur, kesenjangan tersembunyi dalam persyaratan menjadi terlihat.
Langkah demi Langkah: Ekstraksi Persyaratan Berbantuan AI
Langkah 1 — Kumpulkan masukan mentah. Log panggilan, email, tangkapan layar yang ada, daftar keluhan. Semakin nyata masukannya, semakin sedikit fabrikasinya.
Langkah 2 — Ekstrak kumpulan cerita pertama. Berikan masukan mentah pada kecerdasan buatan dan buatlah rancangan cerita pengguna. Langkah ini bukanlah daftar lengkap, melainkan langkah awal.
Langkah 3 — Tambahkan kriteria penerimaan. Hasilkan kriteria Diberikan/Kapan/Kemudian untuk setiap cerita. Sebuah cerita yang kriterianya tidak dapat dibuat sebenarnya berarti bahwa cerita tersebut tidak didefinisikan secara memadai.
Langkah 4 — Memindai kontradiksi dan kesenjangan. Tanyakan kepada AI “apakah ada kontradiksi, duplikasi, atau situasi yang tidak terdefinisi antara persyaratan ini?” Tanyakan dan periksakan. Filter hasilnya sebagai manusia.
Langkah 5 — Prioritaskan dan konfirmasi. Prioritaskan cerita dengan pemangku kepentingan berdasarkan nilai dan urgensi bisnis. Keputusan prioritas berada di tangan unit bisnis, bukan AI.
Jangan Lupakan Persyaratan Non-Fungsional
Sebagian besar proyek mengalami kesulitan di lapangan karena melupakan proyek non-fungsional saat menulis persyaratan fungsional. Laporan mungkin berfungsi “dengan benar”, tetapi jika dibuka dalam waktu 45 detik, tidak ada yang akan menggunakannya. Tabel berikut menunjukkan jenis persyaratan non-fungsional yang umum diabaikan dan contoh penulisan yang terukur.
Aliran
ekspresi buruk
ekspresi terukur
Kinerja
"Harus cepat"
"Respon kueri <2 detik pada beban rata-rata"
aksesibilitas
"Semua orang harus bisa menggunakannya"
"Sesuai dengan WCAG 2.1 AA; navigasi keyboard lengkap"
Keamanan
"Seharusnya aman"
"Data pribadi dienkripsi saat disimpan; akses berbasis peran"
ketersediaan
"Seharusnya mudah"
"Pengguna baru menyelesaikan pesanan dalam 3 langkah tanpa pelatihan"
Ketersediaan/kontinuitas
"Seharusnya tidak mogok"
"Waktu aktif bulanan ≥ 99,5%"
Tiga Kasus Mini: Berdasarkan Angka
Kasus 1 - Harga dari suatu kebutuhan yang tidak dapat diukur. Layar, yang dikembangkan di bank dengan persyaratan bahwa "layar laporan harus terbuka dengan cepat", dibuka dalam 22 detik di bawah beban lapangan. Pengembang mengira dia memberikan kata "cepat" di lingkungannya (2 detik). Jika persyaratannya ditulis sebagai "< 3 detik pada jam sibuk, throughput aktual", masalahnya akan tertangkap dalam pengujian. Pembangunan kembali membutuhkan waktu 3 minggu dan biaya tambahan yang terukur.
Kasus 2 — Kesenjangan yang ditangkap oleh kriteria penerimaan. Saat menulis kriteria penerimaan untuk cerita "sistem menerapkan diskon" dalam proyek e-niaga, pemangku kepentingan memperhatikan bahwa apa yang akan terjadi jika diskon bertentangan dengan kupon dan diskon VIP tidak dibahas sama sekali. Satu pertanyaan Diberikan/Kapan/Kemudian mencegah kesalahan diskon ganda sebelum ditayangkan; Kesalahan ini menyebabkan hilangnya pendapatan yang serius pada proyek serupa.
Kasus 3 - Aturan buatan AI. Dalam proyek SDM, AI menambahkan kalimat “permintaan cuti disetujui secara otomatis dalam waktu 24 jam” ke dalam draf persyaratan. Tidak ada persetujuan otomatis yang dibahas dalam pertemuan tersebut; Model tersebut telah membuat aturan yang tampaknya “masuk akal”. Di samping setiap persyaratan, pakar menulis “sumber: wawancara/dokumen yang mana?” Dengan menambahkan kolom tersebut, ia menghapus 4 kalimat yang tidak bersumber.
Prompt Lemah / Prompt Kuat
Perintah yang lemah:
Tulis cerita pengguna untuk proyek ini.
Perintah yang kuat:
Peran Anda: Anda adalah seorang analis bisnis MIS. Ekstrak cerita pengguna dari catatan wawancara di bawah ini. Aturan: - Format: “Sebagai [peran], untuk [tujuan], saya ingin [fitur].” - Tulis SETIDAKNYA 2 kriteria penerimaan untuk setiap cerita dalam format Diberikan/Kapan/Lalu. - Tambahkan kolom “Sumber” di samping setiap cerita: dari kalimat mana asalnya? - Beri label [TIDAK PASTI] aturan apa pun yang tidak jelas dalam catatan; pas.- Tulis persyaratan non-fungsional yang terukur (kinerja, keamanan, aksesibilitas) di bagian terpisah. Catatan wawancara:[teks]
Perintah yang kuat menerapkan format cerita, kriteria penerimaan, ketertelusuran sumber, dan persyaratan non-fungsional sekaligus; Hal ini membuat lebih mudah untuk mengontrol output.
Empat Templat yang Dapat Disalin
1) Klarifikasi persyaratan:
Tinjau persyaratan di bawah ini. Tandai setiap pernyataan yang tidak jelas, tidak dapat dibandingkan, atau terbuka untuk lebih dari satu penafsiran dan tuliskan pertanyaan klarifikasi untuk masing-masing pernyataan. Jangan mengarang jawabannya. Persyaratan: [teks]
2) Pemindaian kontradiksi:
Dalam daftar persyaratan di bawah, temukan item yang bertentangan satu sama lain, berulang, atau meninggalkan kesenjangan logis. Laporkan setiap temuan dengan nomor item dan satu kalimat justifikasi. Daftar: [teks]
3) Menghasilkan kriteria penerimaan:
Tulis setidaknya 4 kriteria penerimaan untuk cerita pengguna berikut dalam format Diberikan/Kapan/Kemudian, termasuk kasus batas dan pengecualian. Cantumkan juga poin-poin yang masih belum jelas. Cerita: [teks]
4) Garis besar ruang lingkup:
Buat konsep item "Dalam Cakupan" dan "Di Luar Cakupan" sebagai tabel dua kolom sesuai dengan persyaratan berikut. Labeli [KONFIRMASI DIPERLUKAN] untuk item apa pun yang Anda tidak yakin. Persyaratan: [teks]
Kesalahan umum
- Memikirkan solusi adalah sebuah kebutuhan. "Tambahkan menu tarik-turun" adalah solusi, bukan keharusan. Persyaratannya mengatakan "pengguna harus dapat memilih negara dari daftar yang ditentukan"; Tim TI merancang solusinya.
- Melewatkan yang non-fungsional. Sekadar menuliskan “apa yang harus dilakukan” dan melupakan “bagaimana menjadi” (kecepatan, keamanan, aksesibilitas) adalah celah yang paling umum dan paling mahal.
- Menggunakan kata sifat yang tidak dapat diukur. Kata-kata seperti "cepat, mudah, aman, ramah pengguna" tidak valid tanpa batasan.
- Tidak memperhatikan aturan yang dibuat oleh AI. Model tersebut mungkin menambahkan aturan yang “masuk akal” namun tidak benar-benar diucapkan; Mintalah sumber daya untuk setiap kebutuhan.
- Menyerahkan prioritas pada AI. Yang harus dilakukan pertama kali adalah keputusan nilai bisnis; Unit bisnis memberikan ini.
Perhatian: Kalimat paling berbahaya dalam analisis persyaratan adalah "semua orang sudah mengetahui hal ini". Asumsi yang tidak terucapkan tidak masuk ke dalam dokumentasi, tidak pernah masuk ke dalam kode, dan muncul di lapangan. Tanyakan kepada AI “apa yang diasumsikan tetapi tidak tertulis dalam persyaratan ini?” membuat asumsi tersembunyi ini terlihat.
Singkatnya
Analisis persyaratan mendefinisikan apa yang harus dilakukan sistem dengan cara yang jelas, terukur, dan dapat dilacak. Persyaratan fungsional menggambarkan pekerjaan, persyaratan non-fungsional menggambarkan kualitas, dan yang terakhir ini sering dilupakan. Kisah pengguna dan kriteria penerimaan Diberikan/Kapan/Kemudian adalah alat ampuh yang menghilangkan ketidakpastian. Kecerdasan buatan secara signifikan mempercepat produksi papan cerita, kriteria penerimaan, deteksi konflik, dan pertanyaan klarifikasi; Namun kebenaran aturan bisnis, ruang lingkup dan prioritas keputusan, serta sumber setiap kalimat adalah tanggung jawab manusia. Jangan menyelesaikan persyaratan apa pun yang tidak bersumber dan tidak dapat diukur.
Tugas aplikasi
Tulis permintaan bisnis satu paragraf untuk “sistem janji temu online” imajiner (misalnya, “Klien harus dapat membuat janji temu secara online, staf harus dapat melihat kalender”). (1) Buat setidaknya 5 cerita pengguna dan 2 kriteria penerimaan untuk masing-masing cerita dengan permintaan kuat dari permintaan ini. (2) Temukan setidaknya 2 kesenjangan tersembunyi dalam kriteria yang dihasilkan oleh model (misalnya penunjukan ganda pada waktu yang sama, aturan pembatalan). (3) Mencantumkan paling sedikit 3 persyaratan non-fungsional dalam bentuk yang terukur. (4) Identifikasi setidaknya 3 item sebagai "Di Luar Cakupan". (5) Tandai aturan yang mungkin dibuat oleh model tersebut dan tuliskan bagaimana Anda akan mengonfirmasinya.
daftar periksa
- [ ] Saya menulis persyaratan fungsional dan non-fungsional secara terpisah.
- [ ] Setiap persyaratan jelas, terukur, dan dapat diuji.
- [ ] Setiap cerita memiliki kriteria penerimaan Diberikan/Kapan/Kemudian.
- [ ] Saya dapat melacak sumber (percakapan/dokumen) dari setiap persyaratan.
- [ ] Saya menandai kemungkinan aturan yang telah dibuat oleh AI dan meninggalkannya untuk konfirmasi.
- [ ] Saya melakukan penentuan prioritas bersama dengan unit bisnis.