Perencanaan Persyaratan yang Baik

Jadi, apa yang membuat persyaratan bagus? Persyaratan yang baik harus berharga dan dapat ditindaklanjuti; ia harus mendefinisikan kebutuhan serta menyediakan jalan menuju solusi. Setiap orang di tim harus memahami artinya. Persyaratan bervariasi dalam kompleksitas.

Dokumen Persyaratan yang baik dapat menjadi bagian dari grup dengan persyaratan tingkat tinggi yang dipecah menjadi sub-persyaratan.
Mereka juga dapat mencakup spesifikasi yang sangat rinci yang mencakup seperangkat persyaratan fungsional yang menggambarkan perilaku atau komponen produk akhir.
Persyaratan yang baik harus singkat dan spesifik, dan harus menjawab pertanyaan, "apa yang kita butuhkan?" Alih-alih, "bagaimana kita memenuhi kebutuhan?"
Persyaratan yang baik memastikan bahwa semua pemangku kepentingan memahami bagian mereka dari rencana; jika ada bagian yang tidak jelas atau disalahartikan, produk akhir bisa rusak atau rusak.

Mencegah kegagalan atau salah tafsir persyaratan dapat dibantu dengan menerima umpan balik dari tim secara terus menerus selama proses sebagai persyaratan berkembang. Kolaborasi berkelanjutan dan dukungan dengan semua orang adalah kunci kesuksesan.

Pengumpulan dan Analisis Kebutuhan

Persyaratan adalah suatu kondisi atau kemampuan yang dibutuhkan oleh pemangku kepentingan untuk memecahkan suatu masalah atau mencapai tujuan organisasi; suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh suatu sistem.

Analisis kebutuhan dalam rekayasa perangkat lunak mencakup tugas-tugas yang menentukan kebutuhan atau kondisi yang harus dipenuhi untuk produk baru atau yang diubah dengan mempertimbangkan kemungkinan persyaratan yang saling bertentangan dari berbagai pemangku kepentingan, menganalisis, mendokumentasikan, memvalidasi, dan mengelola perangkat lunak atau persyaratan sistem.

Persyaratannya harus -

Documented
Actionable
Measurable
Testable
Traceable

Persyaratan harus terkait dengan kebutuhan atau peluang bisnis yang teridentifikasi, dan ditetapkan ke tingkat detail yang cukup untuk desain sistem.

Seorang analis bisnis mengumpulkan informasi dengan mengamati sistem yang ada, mempelajari prosedur yang ada, berdiskusi dengan pelanggan dan pengguna akhir. Analis juga harus memiliki keterampilan imajinatif dan kreatif jika tidak ada Sistem kerja. Menganalisis persyaratan yang dikumpulkan untuk menemukan tautan yang hilang adalah analisis persyaratan.

Memperoleh Pendekatan

Untuk memperoleh tujuan, tanyakan pakar bisnis, manajer pengembangan, dan sponsor proyek pertanyaan-pertanyaan berikut -

Apa tujuan bisnis perusahaan yang akan dibantu dicapai oleh proyek ini?
Mengapa kami melakukan proyek ini sekarang?
Apa yang akan terjadi jika kita melakukannya nanti?
Bagaimana jika kita tidak melakukannya sama sekali?
Siapa yang akan mendapat manfaat dari proyek ini?
Apakah orang-orang yang akan mendapat manfaat dari itu menganggapnya sebagai perbaikan terpenting yang mungkin bisa dilakukan saat ini?
Haruskah kami melakukan proyek yang berbeda?

Tujuan yang mungkin adalah mengurangi biaya, meningkatkan layanan pelanggan, menyederhanakan alur kerja, mengganti teknologi usang, menguji coba teknologi baru, dan banyak lainnya. Juga, pastikan Anda memahami persis bagaimana proyek yang diusulkan akan membantu mencapai tujuan yang dinyatakan.

Berbagai Jenis Persyaratan

Jenis persyaratan yang paling umum yang diminati oleh seorang analis bisnis adalah sebagai berikut -

Persyaratan Bisnis

Persyaratan bisnis adalah aktivitas penting dari suatu perusahaan yang harus dilakukan untuk memenuhi tujuan organisasi sambil tetap independen solusi. Dokumen persyaratan bisnis (BRD) merinci solusi bisnis untuk suatu proyek termasuk dokumentasi kebutuhan dan harapan pelanggan.

Persyaratan Pengguna

Persyaratan pengguna harus menentukan persyaratan khusus yang diharapkan / diinginkan pengguna dari perangkat lunak yang akan dibangun dari proyek perangkat lunak. Persyaratan pengguna harus Dapat Diverifikasi, Jelas dan ringkas, Lengkap, Konsisten, Dapat Dilacak, Dapat Dilakukan.

Dokumen persyaratan pengguna (URD) atau spesifikasi persyaratan pengguna adalah dokumen yang biasanya digunakan dalam rekayasa perangkat lunak yang menetapkan apa yang diharapkan pengguna dapat dilakukan oleh perangkat lunak.

Persyaratan sistem

Persyaratan sistem berhubungan dengan penetapan persyaratan sumber daya perangkat lunak dan prasyarat yang perlu diinstal pada komputer untuk memberikan fungsi aplikasi yang optimal.

Persyaratan Fungsional

Persyaratan fungsional menangkap dan menentukan perilaku spesifik yang diinginkan dari sistem yang sedang dikembangkan. Mereka mendefinisikan hal-hal seperti kalkulasi sistem, manipulasi dan pemrosesan data, antarmuka pengguna dan interaksi dengan aplikasi, dan fungsionalitas khusus lainnya yang menunjukkan bagaimana persyaratan pengguna dipenuhi. Tetapkan nomor ID unik untuk setiap persyaratan.

Persyaratan Non Fungsional

Persyaratan non-fungsional adalah salah satu yang menentukan kriteria yang dapat digunakan untuk menilai operasi sistem daripada perilaku tertentu. Arsitektur sistem berbicara tentang rencana untuk mengimplementasikan persyaratan non-fungsional.

Persyaratan non-fungsional berbicara tentang bagaimana sistem seharusnya terlihat atau dapat disebut seperti "sistem harus". Persyaratan non-fungsional disebut sebagai kualitas sistem.

Persyaratan Transisi

Persyaratan Transisi menjelaskan kemampuan yang harus dipenuhi oleh solusi untuk memfasilitasi transisi dari kondisi perusahaan saat ini ke kondisi masa depan yang diinginkan, tetapi itu tidak akan diperlukan setelah transisi tersebut selesai.

Persyaratan ini dibedakan dari jenis persyaratan lainnya, karena sifatnya selalu sementara dan karena persyaratan tersebut tidak dapat dikembangkan hingga solusi yang ada dan yang baru ditentukan. Mereka biasanya mencakup konversi data dari sistem yang ada, kesenjangan keterampilan yang harus diatasi, dan perubahan terkait lainnya untuk mencapai keadaan masa depan yang diinginkan. Mereka dikembangkan dan ditentukan melalui penilaian solusi dan validasi.

Ketertelusuran dan Manajemen Perubahan

Ketertelusuran persyaratan adalah cara untuk mengatur, mendokumentasikan, dan melacak semua persyaratan Anda mulai dari pembuatan ide awal hingga tahap pengujian.

Matriks kemampuan penelusuran persyaratan (RTM) menyediakan metode untuk melacak persyaratan fungsional dan implementasinya melalui proses pengembangan. Setiap persyaratan disertakan dalam matriks bersama dengan nomor bagian yang terkait.

Saat proyek berlangsung, RIM diperbarui untuk mencerminkan status masing-masing persyaratan. Saat produk siap untuk pengujian sistem, matriks mencantumkan setiap persyaratan, komponen produk apa yang menanganinya, dan pengujian apa yang memverifikasi bahwa itu diterapkan dengan benar

Sertakan kolom untuk masing-masing berikut ini di RTM -

Deskripsi kebutuhan
Referensi persyaratan dalam FRD
Metode Verifikasi
Referensi persyaratan dalam Rencana Tes

Example- Menghubungkan titik-titik untuk mengidentifikasi hubungan antar item dalam proyek Anda. Ini adalah penghubung aliran hilir yang umum.

Tujuan Bisnis Tes Persyaratan Ide Desain

Anda harus dapat melacak setiap kebutuhan Anda kembali ke tujuan bisnis aslinya.

Dengan menelusuri persyaratan, Anda dapat mengidentifikasi perubahan efek riak, melihat apakah persyaratan telah diselesaikan dan apakah sedang diuji dengan benar. Ketertelusuran dan manajemen perubahan memberikan ketenangan pikiran kepada manajer dan visibilitas yang diperlukan untuk mengantisipasi masalah dan memastikan kualitas yang berkelanjutan.

Kualitas asuransi

Mendapatkan persyaratan yang disampaikan dengan benar pada kali pertama dapat berarti kualitas yang lebih baik, siklus pengembangan yang lebih cepat, dan kepuasan pelanggan yang lebih tinggi terhadap produk. Manajemen persyaratan tidak hanya membantu Anda melakukannya dengan benar, tetapi juga membantu tim Anda menghemat uang dan banyak sakit kepala selama proses pengembangan.

Persyaratan yang ringkas dan spesifik dapat membantu Anda mendeteksi dan memperbaiki masalah lebih awal, daripada nanti ketika masalah tersebut jauh lebih mahal untuk diperbaiki. Selain itu, biayanya bisa mencapai100 times lebih untuk mengoreksi cacat nanti dalam proses pengembangan setelah itu dikodekan, daripada mengoreksi lebih awal saat merupakan persyaratan.

Dengan mengintegrasikan manajemen persyaratan ke dalam proses jaminan kualitas, Anda dapat membantu tim Anda meningkatkan efisiensi dan menghilangkan pengerjaan ulang. Selain itu, pengerjaan ulang adalah tempat sebagian besar masalah biaya terjadi.

Dengan kata lain, tim pengembangan menghabiskan sebagian besar anggaran mereka untuk upaya yang tidak dilakukan dengan benar pada kali pertama. Misalnya, pengembang mengkodekan fitur berdasarkan dokumen spesifikasi lama, hanya untuk mempelajari nanti, bahwa persyaratan untuk fitur itu berubah. Jenis masalah ini dapat dihindari dengan praktik terbaik manajemen persyaratan yang efektif.

Singkatnya, manajemen persyaratan dapat terdengar seperti disiplin yang kompleks, tetapi ketika Anda menyimpulkannya menjadi konsep sederhana - ini tentang membantu tim menjawab pertanyaan, "Apakah semua orang memahami apa yang kami bangun dan mengapa?" Dari analis bisnis, manajer produk dan pemimpin proyek hingga pengembang, manajer QA dan penguji, bersama dengan pemangku kepentingan dan pelanggan yang terlibat - seringkali akar penyebab kegagalan proyek adalah kesalahpahaman tentang ruang lingkup proyek.

Ketika semua orang berkolaborasi, dan memiliki konteks dan visibilitas penuh untuk diskusi, keputusan, dan perubahan yang terkait dengan persyaratan di sepanjang siklus proyek, saat itulah kesuksesan terjadi secara konsisten dan Anda mempertahankan kualitas yang berkelanjutan. Selain itu, prosesnya lebih lancar dengan sedikit gesekan dan frustrasi di sepanjang jalan bagi semua orang yang terlibat.

Note- Penelitian telah menunjukkan bahwa tim proyek dapat menghilangkan 50-80% cacat proyek dengan mengelola persyaratan secara efektif. Menurut institut rekayasa perangkat lunak Carnegie Mellon, "60-80 persen biaya pengembangan perangkat lunak sedang dikerjakan ulang."

Mendapatkan Persetujuan Persyaratan

Penandatanganan persyaratan meresmikan kesepakatan oleh pemangku kepentingan proyek bahwa konten dan presentasi persyaratan, seperti yang didokumentasikan, akurat dan lengkap. Kesepakatan formal mengurangi risiko bahwa, selama atau setelah implementasi, pemangku kepentingan akan memperkenalkan persyaratan baru (yang sebelumnya tidak ditemukan).

Mendapatkan persetujuan persyaratan biasanya melibatkan tinjauan akhir persyaratan tatap muka, seperti yang didokumentasikan, dengan setiap pemangku kepentingan proyek. Di akhir setiap tinjauan, pemangku kepentingan diminta untuk secara resmi menyetujui dokumen persyaratan yang ditinjau. Persetujuan ini dapat dicatat baik secara fisik maupun elektronik.

Mendapatkan persetujuan persyaratan biasanya merupakan tugas terakhir dalam Komunikasi Persyaratan. Analis Bisnis akan meminta keluaran dari Peninjauan Persyaratan Formal, termasuk akomodasi dari setiap komentar atau keberatan yang diajukan selama proses peninjauan.