Panduan Terlengkap untuk Manajemen Persyaratan dan Ketertelusuran

Berapa Lama Dibutuhkan?

Pernahkah Anda bertanya-tanya berapa banyak waktu yang diperlukan untuk membuat persyaratan untuk proyek Anda yang akan datang? Analis dan manajer bisnis sering menanyakan pertanyaan ini.

Untuk sebagian besar masalah yang terkait dengan perangkat lunak dan pengembangan produk, tidak ada jawaban yang cocok untuk semua; tanggapannya benar-benar bergantung pada keadaan unik Anda.

Beberapa variabel berkontribusi terhadap masalah ini, rata-rata industri terkemuka menunjukkan berapa persen upaya proyek yang harus dikhususkan untuk pengembangan persyaratan seperti pengumpulan dan elisitasi.

Bagaimana Anda dapat menentukan jumlah waktu dan upaya yang tepat yang diperlukan untuk aktivitas seperti pengumpulan persyaratan? Tidak mengherankan, data dari berbagai tolok ukur tidak selalu cocok satu sama lain. Masih bisa diperdebatkan apakah proyek "biasa" ini mirip dengan proyek Anda. Untuk membantu Anda mengatasi masalah ini, saya telah mengadaptasi beberapa ide dari buku saya “More about Software Requirements” di artikel ini – lihatlah!

Tolok Ukur Industri

Untuk memberikan contoh kegunaan potensial dari tolok ukur, silakan lihat Tabel 1. Data yang disajikan menunjukkan rata-rata industri untuk berbagai persyaratan elisitasi dan upaya pembuatan prototipe mengenai proyek yang berukuran 10,000 titik fungsi (sekitar satu juta baris kode), bersumber dari "Penilaian Perangkat Lunak, Tolok Ukur, dan Praktik Terbaik" dari Capers Jones. Seberapa relevan angka-angka ini dengan proyek Anda sendiri?

Memanfaatkan tolok ukur industri seperti ini bukan tanpa kekurangannya. Data gagal memberi tahu kami apakah proyek benar-benar berhasil atau apakah ada korelasi antara keberhasilan dan upaya yang dilakukan untuk memunculkan persyaratan. Informasi ini hanya memberi kita rata-rata dari apa yang telah dilakukan, sehingga sulit untuk secara akurat menggambarkan keberhasilan masing-masing proyek.

Mengalokasikan 10% atau kurang dari upaya tim untuk tugas-tugas seperti pengumpulan persyaratan terbukti bermanfaat, asalkan mereka tidak terjebak dalam kelumpuhan analisis. Bertentangan dengan kepercayaan populer, menginvestasikan lebih banyak upaya untuk meningkatkan proses pengembangan kebutuhan Anda sebenarnya akan mempercepat produksi. Memanfaatkan konsep ini memberikan pengembalian investasi yang besar untuk proyek apa pun!

Saat saya mengerjakan proyek yang lebih kecil saat bekerja di Kodak, tim kami sering mengalokasikan 15% hingga 18% dari total upaya untuk aktivitas kebutuhan. Kami menemukan bahwa investasi ini mengurangi jumlah perubahan setelah pengiriman yang diperlukan. Sulit untuk menghubungkan sebab dan akibat dengan pasti, tetapi kemungkinan tingkat pemeliharaan kami yang rendah sebagian besar disebabkan oleh peningkatan partisipasi pengguna yang signifikan.

Mencoba mencari tahu dengan tepat berapa banyak waktu yang diperlukan untuk mengumpulkan proyek Anda berikutnya adalah pertanyaan yang rumit, dan bisa sulit untuk diukur secara akurat. Namun untungnya, Gambar 1 memberi kita wawasan tentang variabel yang dapat mempersingkat atau memperpanjang proses tersebut; membantu Anda memperkirakan lebih efektif saat membuat persyaratan yang diperlukan tersebut.

Pengalaman Anda Sendiri

Untuk memulai, mungkin berguna untuk meninjau data dari proyek sebelumnya untuk menentukan upaya apa yang didedikasikan khusus untuk pengumpulan persyaratan. Ini akan memungkinkan Anda untuk menilai seberapa sukses proses pengembangan Anda di masa lalu dan menggunakan informasi ini saat memperkirakan biayanya untuk upaya di masa mendatang. Sebagai faktor tambahan, sesuaikan perkiraan awal Anda dengan merujuk Gambar 1 yang menguraikan perbedaan antara proyek yang akan datang dan proyek tolok ukur serta mempertimbangkan pertimbangan relevan lainnya mengenai proyek Anda yang sedang dikerjakan. Dengan menilai setiap elemen yang tercantum dalam Gambar 1 pada skala mulai dari 0 (tidak berpengaruh) hingga 5 (sangat berpengaruh), evaluasi ini dapat membantu Anda mendeteksi faktor risiko yang dapat memperpanjang proses pengembangan persyaratan Anda.

Bersamaan dengan elemen lain, penting untuk mempertimbangkan siklus hidup proyek. Jangan berasumsi bahwa semua persyaratan harus diakumulasikan di awal seperti pada pendekatan berurutan atau air terjun (diilustrasikan dengan garis putus-putus pada Gambar 2). Daripada memiliki "fase persyaratan" yang khas, pikirkan tentang serangkaian persyaratan yang melintasi setiap tahap pengembangan. Saat Spesifikasi Persyaratan Sistem (SRS) kami berkembang dan permintaan perubahan mulai muncul, kami harus tetap rajin mengelola baseline persyaratan secara aktif. Ini adalah proses berkelanjutan yang membutuhkan perhatian yang konsisten.

Pendekatan Iteratif dan Inkremental

Pendekatan pengembangan tangkas, seperti Scrum, mengambil rute progresif. Hal ini memungkinkan pengguna untuk mendapatkan fitur produk yang berpotensi berguna dengan cepat dan dengan mudah memodifikasi kebutuhan mereka sesuai kebutuhan. Dengan demikian pengembang dapat mengikuti tuntutan bisnis yang selalu berubah dengan mudah. Dengan proyek yang gesit, jarang ada kebutuhan untuk inisiatif daftar permintaan yang besar karena upaya pengumpulan persyaratan yang kecil namun teratur (garis padat pada Gambar 2).

Alih-alih berfokus pada awal proyek, upaya persyaratan dalam proyek agile tersebar di berbagai tahapan. Eksplorasi awal mengarah pada fungsionalitas perincian backlog berdasarkan tingkat prioritasnya. Saat tiba waktunya untuk pengembangan dan pengujian, tim menyempurnakan persyaratan sehingga mereka memiliki detail yang cukup untuk melanjutkan setiap iterasi dengan percaya diri.

Bertahun-tahun yang lalu, saya adalah bagian dari tim pengembangan perangkat lunak yang memanfaatkan pendekatan inkremental untuk memastikan kesuksesan. Setiap siklus, proyek kami akan dirilis dalam fase tiga minggu dengan bagian pertama didedikasikan untuk merencanakan persyaratan dan mengembangkan untuk peningkatan spesifik tersebut. Kami mendapatkan hasil yang luar biasa dari metode ini karena metode ini membawa fungsionalitas yang berguna setiap beberapa minggu ke basis pengguna korporat. Tim bekerja dengan rajin untuk menghadirkan fungsionalitas baru dengan cepat secara bertahap, memberikan pembaruan yang sering kepada pengguna. Wawasan pengguna ini sangat berharga untuk memandu proyek dan membantu memastikan bahwa nilai maksimum dicapai dengan penyelesaiannya.

Tidak semua inisiatif cocok untuk disampaikan dalam potongan kecil. Saat membangun kembali aplikasi yang ada, sistem baru harus memiliki tingkat fungsionalitas yang substansial sebelum pengguna dapat beralih ke sana. Terlepas dari seberapa banyak tim Anda menyelesaikan setiap siklus proyek, mereka harus memahami persyaratan untuk urutan tertentu untuk mencegah pengulangan dan penulisan ulang desain, kode, atau pengujian yang berlarut-larut.

Perencanaan Kebutuhan Elisitasi

Ini seringkali lebih rumit daripada yang terlihat saat Anda mulai mengompilasi persyaratan untuk proyek baru. Saat melakukan brainstorming aktivitas yang perlu dilakukan oleh analis Anda, ingatlah apakah mereka harus melakukan tugas seperti ini:

Menumbuhkan hubungan dengan juara produk melalui negosiasi.
Mengumpulkan wawasan melalui workshop interaktif dan wawancara mendalam.
Memeriksa catatan dan produk yang ada untuk menggali potensi perbaikan.
Membangun, menyebarluaskan, dan menguraikan survei.
Merancang, dan menilai prototipe, mempelajari model, dan perspektif kebutuhan lainnya untuk sukses.
Mencapai kesuksesan melalui penilaian risiko, memastikan protokol keselamatan dan keamanan diamati, menganalisis potensi kegagalan, dan melakukan pemeriksaan bahaya.
Mencatat detail kebutuhan Anda ke dalam repositori data.
Meneliti dengan cermat tuntutan yang dirinci dalam spesifikasi persyaratan.
Menyusun kasus uji dari persyaratan yang tercantum, dan mengevaluasi kinerjanya dengan cermat.
Setelah peninjauan atau pengujian menyeluruh, sesuaikan spesifikasi persyaratan untuk memastikan akurasi.

Untuk dapat memperkirakan dengan lebih baik upaya yang diperlukan untuk proyek masa depan, penting untuk mempelajari tentang berbagai tugas yang mungkin harus dilakukan oleh tim Anda sebagai bagian dari perolehan, analisis, spesifikasi, dan validasi persyaratan. Pengetahuan ini selanjutnya akan membantu Anda memahami berapa banyak waktu yang dibutuhkan setiap tugas dan membantu meningkatkan kinerja proyek Anda. Ini tidak berarti bahwa semua aktivitas perlu dilakukan pada setiap usaha, melainkan memahami apa yang perlu dilakukan mengarah pada hasil yang sukses.

Jangan lupa untuk membagikan postingan ini!