Keuntungan:
- Keupayaan untuk membezakan keperluan berfungsi dan tidak berfungsi dan menulis ungkapan keperluan yang jelas dan boleh diukur dengan sokongan kecerdasan buatan
- Keupayaan untuk menggunakan kecerdasan buatan dengan gesaan berstruktur untuk mengekstrak cerita pengguna, kriteria penerimaan dan had skop daripada nota temu bual
- Membiasakan diri menyemak keperluan yang dijana AI untuk kesamaran, percanggahan dan peraturan yang tiada serta mengesahkannya dengan pihak berkepentingan
Analisis keperluan ialah tugas untuk mentakrifkan secara lengkap, jelas dan boleh disahkan apa yang perlu dilakukan oleh sistem. Ia adalah salah satu peringkat di mana pakar MIS menghasilkan nilai paling tinggi; kerana kesilapan di sini berkembang dengan pesat pada akhir projek. Terdapat dua jenis asas analisis keperluan. Keperluan fungsian menerangkan tugas yang harus dilakukan oleh sistem: "Sistem harus menghantar e-mel kepada pelanggan apabila ia mengesahkan pesanan." Keperluan tidak berfungsi menerangkan bagaimana sistem seharusnya: kualiti seperti prestasi, keselamatan, kebolehgunaan dan kebolehcapaian. "Skrin laporan harus dibuka dalam masa kurang daripada 2 saat pada beban purata" ialah keperluan tidak berfungsi.
Keperluan yang baik mempunyai tiga ciri: ia jelas (ia mempunyai tafsiran tunggal), ia boleh diukur (ia mempunyai ambang yang boleh diuji), dan ia boleh dikesan (ia adalah jelas keperluan perniagaan ia datang). "Sistem mesti pantas" tidak memenuhi semua ini; "cepat" adalah subjektif, tidak boleh diukur, tidak boleh diuji. Pada peringkat ini, AI ialah bantuan yang berkuasa dalam merangka keperluan dan menangkap perkataan yang tidak jelas; tetapi hanya pihak berkepentingan yang menentukan peraturan perniagaan mana yang benar.
Kisah Pengguna dan Kriteria Penerimaan
Format biasa dalam penulisan keperluan moden ialah cerita pengguna: "Sebagai [peranan], untuk [tujuan], saya mahukan [ciri]." Contoh: "Sebagai wakil jualan, saya mahukan pengiraan diskaun daripada skrin mudah alih supaya saya boleh membuat sebut harga pantas dalam medan." Ceritanya pendek dan berorientasikan perniagaan; Ia tidak mengenakan penyelesaian teknikal.
Setiap cerita harus mempunyai kriteria penerimaan: syarat yang boleh diuji yang mesti dipenuhi untuk cerita itu dianggap "ok". Corak yang kerap digunakan ialah corak "Diberikan/Bila/Kemudian": "Diberikan: pelanggan berada dalam segmen VIP. Bila: memesan lebih 10,000 TL. Kemudian: sistem menggunakan diskaun 5%." Corak ini menghapuskan kekaburan kerana ia jelas menghubungkan keadaan dan hasil yang dijangkakan.
Petua: Semasa menulis cerita pengguna kepada kecerdasan buatan, pastikan anda menyebut "jana sekurang-kurangnya 2 kriteria penerimaan dalam format Diberi/Bila/Kemudian untuk setiap cerita." Apabila model terpaksa menghasilkan penanda aras, jurang tersembunyi dalam keperluan menjadi kelihatan.
Langkah demi Langkah: Pengekstrakan Keperluan Bantuan AI
Langkah 1 — Kumpul input mentah. Log panggilan, e-mel, tangkapan skrin sedia ada, senarai aduan. Lebih banyak input sebenar, lebih sedikit fabrikasi.
Langkah 2 — Ekstrak set cerita pertama. Berikan input mentah kepada kecerdasan buatan dan minta ia menghasilkan draf cerita pengguna. Langkah ini bukan senarai lengkap, tetapi langkah pertama.
Langkah 3 — Tambah kriteria penerimaan. Hasilkan kriteria Diberi/Bila/Kemudian untuk setiap cerita. Cerita yang kriterianya tidak dapat dihasilkan sebenarnya bermakna ia tidak ditakrifkan dengan secukupnya.
Langkah 4 — Mengimbas percanggahan dan jurang. Tanya AI "adakah terdapat sebarang percanggahan, pertindihan, atau situasi yang tidak ditentukan antara keperluan ini?" Tanya dan periksa. Tapis hasilnya sebagai manusia.
Langkah 5 — Utamakan dan sahkan. Utamakan cerita dengan pihak berkepentingan berdasarkan nilai perniagaan dan segera. Keputusan keutamaan adalah milik unit perniagaan, bukan AI.
Jangan Lupa Keperluan Bukan Fungsian
Kebanyakan projek mempunyai kesukaran dalam bidang kerana mereka melupakan yang tidak berfungsi semasa menulis keperluan fungsian. Laporan mungkin berfungsi "dengan betul", tetapi jika ia mengambil masa 45 saat untuk dibuka, tiada siapa yang akan menggunakannya. Jadual berikut menunjukkan jenis keperluan tidak berfungsi yang biasanya diabaikan dan contoh penulisan boleh diukur.
Genre
ungkapan buruk
ungkapan yang boleh diukur
Prestasi
"Mestilah cepat"
"Respons pertanyaan < 2 saat pada purata beban"
kebolehcapaian
"Semua orang mesti boleh menggunakannya"
"Patuhi WCAG 2.1 AA; navigasi papan kekunci penuh"
Keselamatan
"Sepatutnya selamat"
"Data peribadi disulitkan semasa rehat; akses adalah berasaskan peranan"
ketersediaan
"Sepatutnya mudah"
"Pengguna baharu melengkapkan pesanan dalam 3 langkah tanpa latihan"
Ketersediaan / kesinambungan
"Tidak sepatutnya terhempas"
"Masa beroperasi bulanan ≥ 99.5%"
Tiga Kes Mini: Mengikut Nombor
Kes 1 — Harga keperluan yang tidak boleh diukur. Skrin, yang dibangunkan di bank dengan keperluan "skrin laporan harus dibuka dengan cepat", dibuka dalam masa 22 saat di bawah beban medan. Pembangun berpendapat dia memberikan perkataan "cepat" dalam persekitarannya (2 saat). Jika keperluan telah ditulis sebagai "< 3 saat pada waktu puncak, daya pengeluaran sebenar", masalahnya akan terperangkap dalam ujian. Kos pembangunan semula selama 3 minggu dan kos tambahan yang boleh diukur.
Kes 2 — Jurang ditangkap oleh kriteria penerimaan. Semasa menulis kriteria penerimaan untuk cerita "sistem menggunakan diskaun" dalam projek e-dagang, pihak berkepentingan menyedari bahawa apa yang akan berlaku jika diskaun bercanggah dengan kupon dan diskaun VIP tidak dibincangkan sama sekali. Satu soalan Diberi/Bila/Kemudian menghalang ralat diskaun berganda sebelum siaran langsung; Ralat ini menyebabkan kerugian hasil yang serius dalam projek yang serupa.
Kes 3 — Peraturan buatan AI. Dalam projek HR, AI menambahkan ayat "permintaan cuti diluluskan secara automatik dalam masa 24 jam" pada draf keperluan. Tiada kelulusan automatik sedemikian dibincangkan dalam mesyuarat; Model itu telah membuat peraturan yang kelihatan "munasabah." Di sebelah setiap keperluan, pakar menulis "sumber: wawancara/dokumen yang mana?" Dengan menambah lajur, dia mengalih keluar 4 ayat tidak bersumber.
Gesaan Lemah / Gesaan Kuat
Gesaan yang lemah:
Tulis cerita pengguna untuk projek ini.
Gesaan kuat:
Peranan anda: Anda seorang penganalisis perniagaan MIS. Ekstrak cerita pengguna daripada nota temu duga di bawah. Peraturan:- Format: “Sebagai [peranan], untuk [tujuan], saya mahukan [ciri].”- Tulis SEKURANG-KURANGNYA 2 kriteria penerimaan untuk setiap cerita dalam format Diberi/Bila/Kemudian.- Tambahkan lajur "Sumber" di sebelah setiap cerita: mana-mana ayat yang tidak jelas asalnya?- Labelkan mana-mana ayat yang tidak jelas?- [UNCAIN] [UNCAIN] [UNCAIN] [UNCAIN] pemasangan.- Tulis keperluan tidak berfungsi yang boleh diukur (prestasi, keselamatan, kebolehcapaian) dalam bahagian yang berasingan. Nota temu bual:[teks]
Gesaan yang berkuasa menguatkuasakan format cerita, kriteria penerimaan, kebolehkesanan sumber dan keperluan tidak berfungsi sekaligus; Ini menjadikannya lebih mudah untuk mengawal output.
Empat Templat Boleh Disalin
1) Penjelasan keperluan:
Semak keperluan di bawah. Tandai setiap pernyataan yang samar-samar, tidak boleh dibandingkan, atau terbuka kepada lebih daripada satu tafsiran dan tulis soalan yang menjelaskan untuk setiap satu. Jangan reka jawapan. Keperluan: [teks]
2) Pengimbasan percanggahan:
Dalam senarai keperluan di bawah, cari item yang bercanggah antara satu sama lain, berulang atau tinggalkan jurang logik. Laporkan setiap penemuan dengan nombor item dan justifikasi satu ayat. Senarai: [teks]
3) Menjana kriteria penerimaan:
Tulis sekurang-kurangnya 4 kriteria penerimaan untuk cerita pengguna berikut dalam format Diberi/Bila/Kemudian, termasuk kes had dan pengecualian. Senaraikan juga mana-mana perkara yang masih tidak jelas. Cerita: [teks]
4) Garis skop:
Draf item "Dalam Skop" dan "Di Luar Skop" sebagai jadual dua lajur mengikut keperluan berikut. Label [PENGESAHAN DIPERLUKAN] untuk mana-mana item yang anda tidak pasti. Keperluan: [teks]
Kesilapan biasa
- Berfikir penyelesaian adalah satu keperluan. "Tambah menu lungsur" ialah penyelesaian, bukan keperluan. Keperluan mengatakan "pengguna mesti boleh memilih negara daripada senarai yang ditentukan"; Pasukan IT mereka bentuk penyelesaiannya.
- Melangkau yang tidak berfungsi. Hanya menulis "apa yang perlu dilakukan" dan melupakan "bagaimana untuk menjadi" (kelajuan, keselamatan, kebolehcapaian) adalah kelemahan yang paling biasa dan paling mahal.
- Menggunakan kata adjektif yang tidak terukur. Perkataan seperti "cepat, mudah, selamat, mesra pengguna" adalah tidak sah tanpa ambang.
- Tidak menyedari peraturan yang telah dibuat oleh AI. Model ini mungkin menambah peraturan "munasabah" tetapi sebenarnya tidak dituturkan; Minta sumber untuk setiap keperluan.
- Meninggalkan keutamaan kepada AI. Perkara yang perlu dilakukan terlebih dahulu ialah keputusan nilai perniagaan; Unit perniagaan memberikan ini.
Awas: Ayat yang paling berbahaya dalam analisis keperluan ialah "semua orang sudah tahu perkara ini". Andaian yang tidak dinyatakan tidak menjadikannya dalam dokumentasi, tidak sekali-kali menjadikannya dalam kod dan muncul dalam medan. Tanya AI "apa yang diandaikan tetapi tidak ditulis dalam keperluan ini?" menjadikan andaian tersembunyi ini kelihatan.
Secara ringkasnya
Analisis keperluan mentakrifkan apa yang sistem harus lakukan dengan cara yang jelas, boleh diukur dan boleh dikesan. Keperluan fungsional menerangkan pekerjaan, keperluan tidak berfungsi menerangkan kualiti, dan yang terakhir sering dilupakan. Cerita pengguna dan Kriteria penerimaan Diberi/Bila/Kemudian ialah alat berkuasa yang menghapuskan ketidakpastian. Kecerdasan buatan mempercepatkan pengeluaran papan cerita, kriteria penerimaan, pengesanan konflik dan soalan penjelasan dengan ketara; Walau bagaimanapun, ketepatan peraturan perniagaan, skop dan keputusan keutamaan, dan sumber setiap ayat adalah tanggungjawab manusia. Jangan memuktamadkan sebarang keperluan yang tidak bersumber dan tidak boleh diukur.
Tugasan permohonan
Tulis permintaan perniagaan satu perenggan untuk "sistem janji temu dalam talian" khayalan (cth., "Pelanggan sepatutnya boleh membuat janji temu dalam talian, kakitangan sepatutnya dapat melihat kalendar"). (1) Buat sekurang-kurangnya 5 cerita pengguna dan 2 kriteria penerimaan untuk setiap satu dengan gesaan yang kuat daripada permintaan ini. (2) Cari sekurang-kurangnya 2 jurang tersembunyi dalam kriteria yang dihasilkan oleh model (cth. pelantikan dua kali pada masa yang sama, peraturan pembatalan). (3) Sertakan sekurang-kurangnya 3 keperluan tidak berfungsi dalam bentuk yang boleh diukur. (4) Kenal pasti sekurang-kurangnya 3 item sebagai "Di Luar Skop". (5) Tandakan peraturan yang mungkin telah dibuat oleh model dan tulis cara anda mengesahkannya.
senarai semak
- [ ] Saya menulis keperluan berfungsi dan tidak berfungsi secara berasingan.
- [ ] Setiap keperluan adalah jelas, boleh diukur dan boleh diuji.
- [ ] Setiap cerita mempunyai kriteria penerimaan Diberi/Bila/Kemudian.
- [ ] Saya boleh mengesan sumber (perbualan/dokumen) setiap keperluan.
- [ ] Saya menandakan peraturan yang mungkin dibuat oleh AI dan meninggalkannya untuk pengesahan.
- [ ] Saya melakukan keutamaan bersama-sama dengan unit perniagaan.