Mengembangkan Persyaratan dalam Lingkungan Bisnis yang Berubah

Rekayasa persyaratan adalah salah satu aspek yang paling menantang dari pengembangan perangkat lunak. Ini juga bisa dibilang aspek yang paling penting, karena meletakkan dasar untuk semua hasil proyek berikutnya. Jika persyaratannya salah, maka Anda tidak akan pernah bisa memberikan solusi yang tepat. Pengembangan persyaratan bahkan lebih ketat di lingkungan bisnis saat ini karena berbagai alasan termasuk jumlah cepat perubahan yang terjadi dalam operasi bisnis sehari-hari, peningkatan yang signifikan dari outsourcing dan pengembangan lepas pantai, dan penggunaan metode pengembangan tangkas. Di bawah ini adalah rekomendasi yang dapat digunakan untuk mengembangkan persyaratan dalam lingkungan yang kompetitif saat ini.

1.  Lebih Menekankan pada Kolaborasi dan Kurangi Kekakuan

Kebutuhan bisnis berkembang, pengguna atau pasar baru diidentifikasi, aturan bisnis dan peraturan pemerintah direvisi, dan lingkungan operasi berubah seiring waktu. Karena lingkungan bisnis yang berubah dengan cepat, persyaratan yang dikembangkan saat ini seringkali ketinggalan zaman dalam waktu 6 bulan. Proses persyaratan perlu menempatkan peningkatan penekanan pada kolaborasi dan kurang pada ketelitian dan kekakuan. Kemampuan untuk mendukung perubahan sangat penting. Pengguna perlu dilibatkan untuk keberhasilan proyek dan keterlibatan ini perlu berkelanjutan, bukan hanya partisipasi dalam lokakarya persyaratan di bagian depan proyek. Alat manajemen persyaratan otomatis (seperti Enfocus Persyaratan Suite™) yang mendukung kolaborasi antara pengembangan, pengguna, dan analis bisnis sangat penting.

2.  Libatkan Pemangku Kepentingan Secara Berkelanjutan

Penelitian Standish Group dan studi lain menunjukkan bahwa keterlibatan pengguna yang tidak memadai adalah penyebab utama kegagalan proyek perangkat lunak. Pengguna sering mengklaim bahwa mereka tidak dapat menghabiskan waktu mengerjakan persyaratan. Namun, pelanggan yang tidak senang karena produk yang dikirimkan meleset dari sasaran selalu menemukan banyak waktu untuk menunjukkan masalahnya. Tim pengembangan pada akhirnya akan mendapatkan masukan pelanggan yang dibutuhkannya. Jauh lebih murah dan jauh lebih tidak menyakitkan untuk mendapatkan masukan itu sejak awal, daripada setelah proyek selesai. Keterlibatan pengguna membutuhkan lebih dari satu atau dua lokakarya di awal proyek. Keterlibatan berkelanjutan oleh pemangku kepentingan yang diberdayakan dan antusias merupakan faktor penentu keberhasilan untuk pengembangan perangkat lunak.

3.  Persyaratan Rumit Tepat Waktu untuk Pengembangan

Karena perubahan lingkungan bisnis, persyaratan dapat berubah 1-2% per bulan. Ini berarti bahwa satu set persyaratan untuk solusi yang disampaikan dalam 6 bulan bisa turun sebanyak 12%. Capers-Jones mengatakan “35% dari persyaratan berubah dalam kehidupan proyek.” Persyaratan harus dikembangkan dan dirilis ke pengembangan secara bertahap. Misalnya, jika tim pengembangan menggunakan Scrum dan memiliki sprint 3 minggu, maka persyaratan harus dirilis ke pengembangan setiap 3 minggu. Detail persyaratan harus diuraikan “just-in-time” agar pengembangan memiliki iterasi pengembangan berikutnya.

4.  Kembangkan Persyaratan Secara Bertahap

Memunculkan satu set lengkap persyaratan sekaligus bukanlah praktik terbaik. Yang terbaik adalah menentukan cakupan solusi dan mempartisinya menjadi fitur. Mengembangkan persyaratan secara bertahap berdasarkan fitur. Cobalah untuk menggunakan pendekatan inkremental untuk pengembangan dan rilis persyaratan secara bertahap untuk pengembangan. Tinjau dan perbarui persyaratan sebelum memberikannya untuk pengembangan. Jangan mendasarkan persyaratan sampai dikirimkan ke pengembangan.

5.  Lakukan Retrospektif Setelah Setiap Peningkatan Permintaan Persyaratan

Kebutuhan bisnis menjadi lebih jelas karena pemangku kepentingan utama menjadi lebih terdidik tentang apa kebutuhan mereka yang sebenarnya. Pemangku kepentingan menjadi lebih baik dalam mendefinisikan kebutuhan mereka setelah mereka memiliki pengalaman dalam mengungkapkan dan meninjau kebutuhan mereka. Yang terbaik adalah mendiskusikan apa yang berjalan dengan baik dan apa yang dapat ditingkatkan pada akhir setiap iterasi pengembangan kebutuhan. Ini paling baik dilakukan dengan menerapkan teknik tangkas yang disebut retrospektif.

6.  Kembangkan Persyaratan Secara Iteratif

Iterasi adalah kunci sukses dalam pengembangan kebutuhan. Jangan berharap untuk mengambil satu lulus melalui elisitasi, analisis, spesifikasi, dan validasi. Anda harus merencanakan beberapa siklus, secara bertahap menyempurnakan persyaratan ke tingkat detail yang sesuai. Pengembangan persyaratan yang baik membutuhkan beberapa siklus elisitasi yang disisipkan dengan siklus tinjauan cepat. Proses berulang ini adalah cara untuk mengumpulkan informasi berkualitas lebih tinggi, menyaring kesalahpahaman, dan menambahkan kelengkapan lapisan pada suatu waktu. Perlu dicatat bahwa kegiatan elisitasi, analisis, spesifikasi, dan validasi dapat berlangsung secara bersamaan pada rangkaian persyaratan yang berbeda.

7.  Bangun Cadangan Kontinjensi ke dalam Proyek

Hampir setiap proyek perangkat lunak menjadi lebih besar dari yang diperkirakan sebelumnya, jadi perkirakan kebutuhan Anda akan bertambah seiring waktu. Menurut konsultan Capers Jones, pertumbuhan persyaratan biasanya rata-rata 1 hingga 3 persen per bulan selama desain dan pengkodean. Hal ini dapat berdampak signifikan pada anggaran untuk proyek jangka panjang. Manajer proyek harus membangun cadangan kontinjensi ke dalam anggaran dan jadwal proyek untuk mengakomodasi perubahan persyaratan dan pengeluaran tak terduga lainnya.

8. Gunakan Alat yang Tepat untuk Mengembangkan Persyaratan

Banyak organisasi masih menggunakan Microsoft Word untuk mengembangkan persyaratan. Ini hanyalah alat yang salah untuk pekerjaan di lingkungan saat ini. Ini seperti mencoba mempersiapkan tanah untuk membangun gedung pencakar langit yang besar menggunakan sekop dan beliung. Menggunakan alat manajemen persyaratan modern seperti Enfocus Requirement Suite™ sangat penting di lingkungan saat ini. Berikut adalah daftar alasan mengapa Microsoft Word bukan alat yang tepat untuk pengembangan dan pengelolaan persyaratan.

  • Persyaratan lebih banyak data intensif daripada dokumen intensif.
  • Persyaratan perlu dikelola sebagai backlog untuk mendukung proyek yang gesit dan kompleks.
    • Iterasi pengembangan
    • Tim yang berbeda
  • Persyaratan lebih dari sekedar teks.
    • Aturan Bisnis Terkait
    • Visualisasi (Model proses, diagram aliran data, gambar rangka, dll.)
    • Dokumen terkait, video, tangkapan layar, dll.
  • Persyaratan perlu dikelola secara individual dan kolektif.
    • Prioritas
    • bundel
    • Manajemen siklus hidup
  • Review dan validasi adalah proses yang berkesinambungan bukan peristiwa tunggal seperti dokumen kata.
  • Setiap jenis kebutuhan membutuhkan jenis data (Pola) yang berbeda.
  • Persyaratan perlu ditelusuri ke depan dan ke belakang dari sumber tempat mereka dibuat hingga penerapan dalam solusi.
  • Beberapa orang perlu mengerjakan persyaratan pada satu waktu. Ini tidak mungkin atau sangat sulit dengan pengolah kata seperti Word. Penting untuk melacak siapa dan kapan perubahan dilakukan.
  • Seringkali diperlukan untuk mengumpulkan data tambahan untuk melengkapi persyaratan, hal ini sering dilakukan dengan item tindakan. Mencoba melacak semua ini di Word bisa menjadi mimpi buruk.

9.  Gunakan Paket Persyaratan Elektronik bukan Dokumen Kertas Besar

Kecuali diperlukan untuk perintah kerja kontrak atau RFP, hari-hari dokumen persyaratan kertas besar sudah berakhir. Persyaratan paling baik disampaikan secara elektronik dalam bentuk bundel persyaratan. Bundel dapat berisi banyak hal selain persyaratan, seperti bahan referensi yang diperlukan untuk memahami persyaratan. Bundel persyaratan sering kali berisi:

  • Deskripsi fitur tingkat tinggi.
  • Deskripsi pemangku kepentingan yang akan terpengaruh oleh fitur tersebut.
  • Persyaratan fungsional.
  • Persyaratan nonfungsional.
  • Alasan penetapan prioritas termasuk nilai bisnis dan kompleksitas implementasi.
  • Visualisasi persyaratan termasuk gambar rangka, papan tulis, model proses, dll.
  • Dokumen terkait seperti salinan markup dari laporan yang ada, tiket masalah, dokumen kepatuhan, dll. yang diperlukan untuk memahami persyaratan.
  • Percakapan mengklarifikasi rincian persyaratan.
  • Aturan bisnis terkait yang memengaruhi persyaratan.

Jika Anda ingin mebangun PT aman dan terpercaya, Anda bisa mengunjungi kami di PendirianPT.co.id .

Leave a Comment

Your email address will not be published. Required fields are marked *