Mengapa Persyaratan Penting dalam Rekayasa Perangkat Lunak?

Pada artikel ini, kita membahas pentingnya persyaratan dalam pengembangan perangkat lunak dan alasan mengapa mengabaikan tahap persyaratan bukanlah ide yang bijaksana saat membangun aplikasi.

" Perangkat lunak yang berfungsi melalui dokumentasi yang komprehensif. " Ini adalah bagian dari Agile Manifesto.

Di permukaan, pernyataan ini mungkin tampak menyiratkan bahwa persyaratan tidak penting dan tidak sepadan dengan waktu. Beberapa pengembang dan klien mereka mengabaikan dokumentasi yang tepat. Tapi itu kesalahan.

Mari kita mulai dengan sedikit penjelasan tentang apa saja persyaratan dalam pengembangan perangkat lunak.

Apa saja persyaratan dalam pengembangan aplikasi?

Ini tidak seperti definisi persyaratan berubah secara signifikan ketika diterapkan pada pengembangan perangkat lunak. Persyaratan hanya menentukan fitur apa yang harus disertakan produk dan bagaimana fitur tersebut harus bekerja. Bagaimana Anda mendekati mereka adalah yang terpenting.

Mengumpulkan dan menganalisis persyaratan adalah salah satu tahap awal dalam proses pengembangan perangkat lunak dalam metodologi Agile dan Waterfall. Selama fase persyaratan dari tahap validasi ide, kesepakatan harus dicapai antara klien dan pengembang tentang apa sebenarnya yang harus dilakukan produk akhir dan bagaimana caranya. Persyaratan dalam pengembangan aplikasi biasanya cukup detail.

Bagaimana mendefinisikan persyaratan perangkat lunak

Ada beberapa jenis persyaratan dalam pengembangan perangkat lunak.

Persyaratan bisnis

Mengapa klien membutuhkan aplikasi? Sekilas, informasi ini mungkin tampak tidak perlu atau bahkan berlebihan. Lagi pula, Anda memiliki klien yang ingin membayar Anda untuk membangun aplikasi. Mengapa Anda harus peduli dengan alasan mereka?

Nah, jika Anda bangga dengan apa yang Anda lakukan dan Anda berusaha keras untuk membangun produk berkualitas, Anda harus peduli tentang mengapa sama seperti Anda peduli tentang apa dan bagaimana.

Pentingnya persyaratan bisnis adalah bahwa mereka memberikan visi tujuan akhir. Dengan tujuan yang terlihat, pengembang dapat menetapkan prioritas. Mereka juga dapat menerapkan keahlian mereka untuk menawarkan solusi yang lebih baik untuk mencapai tujuan ini. Ada alasan mengapa analisis bisnis dimasukkan dalam proses pengembangan di sebagian besar perusahaan.

Tanpa persyaratan bisnis yang jelas, keputusan yang buruk dapat dibuat. Keputusan yang akan memperlambat pengembangan, mengganggu tenggat waktu, dan menghasilkan tahap pengembangan tambahan.

Persyaratan perangkat lunak

Ada dua jenis kebutuhan: fungsional dan nonfungsional. Secara sederhana, perbedaannya adalah sebagai berikut:

Persyaratan fungsional adalah persyaratan apa — Untuk apa sistem ini dirancang? Seperti namanya, mereka menggambarkan fungsionalitas perangkat lunak.

Persyaratan nonfungsional adalah persyaratan bagaimana — Bagaimana sistem ini melakukan apa yang dirancang untuk dilakukan? Persyaratan ini menjelaskan bagaimana setiap fitur harus berperilaku dalam kondisi apa, batasan apa yang harus ada, dan sebagainya.

Kedua berjalan beriringan. Persyaratan nonfungsional melengkapi dan mendefinisikan persyaratan fungsional. Misalnya, bayangkan kita membuat aplikasi perpesanan.

Persyaratan fungsional utama, dalam hal ini, adalah:

1. Aplikasi harus dapat mengirim pesan.
2. Aplikasi harus mendukung transfer file dan media.
3. Dll.

Ini cukup mudah, dan mudah untuk memahami mengapa persyaratan fungsional penting: mereka menguraikan fungsionalitas. Dalam contoh ini, persyaratan nonfungsional mungkin sebagai berikut: :

1. Layanan harus menawarkan fungsionalitas penuh di semua browser utama: Microsoft Edge, Google Chrome (dua versi terbaru), Mozilla Firefox (dua versi terbaru), Opera, Safari (versi terbaru).
2. Tata letak seluler harus didukung.
3. Dll.

Seperti yang dapat Anda lihat, persyaratan fungsional pada dasarnya adalah daftar fungsionalitas yang harus disertakan dalam sistem . Di sisi lain, persyaratan nonfungsional bersifat spesifik. Mereka diperlukan untuk menentukan kondisi pengembangan dan pengujian.

Memang benar bahwa proses Agile berulang memerlukan kemungkinan untuk memperkenalkan perubahan pada setiap tahap pengembangan , tetapi itu tidak menyiratkan persyaratan sebelumnya sama sekali. Anda hanya perlu membuatnya fleksibel.

Tanpa parameter yang tepat ditentukan, tidak mungkin untuk memahami apakah fitur dirancang persis seperti yang seharusnya.

Persyaratan harus dianalisis dan didokumentasikan secara menyeluruh. Mengapa? Karena begitu banyak hal bisa serba salah jika tidak.

Pedang Damocles dengan persyaratan tidak berdokumen

Pentingnya persyaratan perangkat lunak paling baik dipahami oleh spesialis jaminan kualitas. Ketika persyaratan proyek tidak ditata dengan benar, QA menerima pukulan terbesar. Bayangkan mencoba menentukan apakah perangkat lunak diimplementasikan dengan benar tanpa pedoman yang jelas tentang apa yang harus dilakukan dan bagaimana seharusnya melakukannya. Ini benar-benar gila.

Namun, masalah ini tidak hanya memengaruhi penguji. Tidak memiliki spesifikasi resmi berarti sebagai berikut:

• Tidak ada pemahaman yang jelas tentang apa yang merupakan produk jadi atau bahkan fitur.
• Klien tidak tahu apa yang diharapkan pada akhir pengembangan dan apa yang mereka bayar.
• Pengembang dibiarkan menggantung, harus mencari tahu secara spesifik fitur berdasarkan apa yang dikatakan dan bagaimana mereka sendiri memahaminya.
• Bug. Mereka ada di mana-mana.

Persyaratan tidak berdokumen menyebabkan miskomunikasi di semua sisi. Sama sekali tidak jarang klien dan pengembang memahami istilah yang sama secara berbeda. Apalagi jika kita berbicara tentang perusahaan pengembangan outsourcing yang tidak terlalu mengenal bisnis pelanggan.

Miskomunikasi, pada gilirannya, memberikan jalan lurus ke pengerjaan ulang, perubahan, dan perbaikan bug yang konstan. Ada kemungkinan semuanya akan berjalan sesuai rencana tanpa persyaratan yang terdokumentasi, tetapi itu tipis. Biasanya, rantai ini berakhir dengan tenggat waktu yang terganggu dan biaya yang membengkak.

Untuk memastikan kelancaran pengembangan proyek, semua bagian produk dan proses pengembangannya harus dipahami oleh setiap anggota tim dengan cara yang sama. Untuk memastikan bahwa pengembang melihat setiap fitur produk persis seperti yang dilakukan klien, spesifikasi persyaratan perangkat lunak (SRS) dibuat.

Setan ada dalam perinciannya: Apa yang membuat spesifikasi persyaratan perangkat lunak yang baik?

Sekarang, spesifikasi persyaratan perangkat lunak yang sebenarnya dapat sangat rinci atau hanya garis besar fitur. Tingkat detail tergantung pada sejumlah faktor.

Persyaratan berkualitas tinggi mudah dipahami oleh semua orang yang terlibat dalam proyek. Ini termasuk klien, yang mungkin atau mungkin tidak berpengalaman dalam aspek teknis. Beberapa perusahaan menuntut daftar persyaratan yang sangat teknis dan detail, sementara yang lain lebih menyukai persyaratan dalam istilah awam.

Terlepas dari seberapa penuh teknologi dokumentasi Anda, ada aturan umum untuk mengelola persyaratan perangkat lunak. Bahkan ada standar resmi: IEEE Std 830-1998, "Praktik yang Direkomendasikan untuk Spesifikasi Persyaratan Perangkat Lunak." Begini seharusnya SRS yang baik, menurut standarnya:

• Benar . Yang ini mudah. Kebenaran SRS diverifikasi oleh pelanggan dan pengembang berdasarkan kesepakatan yang mereka miliki. SRS harus sesuai dengan spesifikasi teknis dan semua dokumentasi proyek yang mengatur.

• Jelas . Salah satu tujuan utama SRS adalah untuk menghilangkan miskomunikasi. Itu sebabnya setiap spesifikasi kebutuhan harus ditulis agar hanya memiliki satu kemungkinan interpretasi. Bukan hal yang aneh bagi SRS untuk menyertakan glosarium.

• Lengkap . Semakin kompleks aplikasinya, semakin detail SRS yang dibutuhkan. SRS lengkap mencakup setiap sisi, mulai dari persyaratan kinerja hingga fungsionalitas. Ini juga menetapkan batasan tertentu untuk desain. Namun, itu tidak pernah menentukan desain yang tepat. Ini hanya menawarkan parameter.

• Konsisten . Konsistensi internal berarti tidak ada pernyataan dalam SRS yang bertentangan dengan pernyataan lain dalam SRS yang sama. Ini adalah alasan lain untuk menyertakan glosarium — sehingga objek, proses, dan spesifikasi apa pun di dalam dokumen ditetapkan dengan istilah yang tepat.

• Peringkat untuk kepentingan dan/atau stabilitas . Dalam kebanyakan kasus, ada persyaratan yang harus dimiliki dan persyaratan yang diinginkan. Penting bagi spesifikasi persyaratan perangkat lunak untuk memberi label dengan jelas pada kedua jenis tersebut. Ini akan membantu pengembang dan manajer proyek ketika mereka membuat rencana langkah demi langkah untuk proyek tersebut.

• Dapat diverifikasi . Harus ada cara untuk menguji setiap persyaratan yang Anda masukkan dalam SRS. Agar dianggap dapat diverifikasi, persyaratan harus mengandung konsep yang terukur dan konkret.

• Dapat dimodifikasi . Ini mengacu pada struktur SRS. Agar tidak mengganggu alur kerja proyek saat Anda perlu menerapkan perubahan, SRS harus jelas dan mudah diubah, dan persyaratan tidak boleh diulang.

• Dapat dilacak . Harus mudah untuk mengidentifikasi sumber dari setiap persyaratan yang ditetapkan dalam SRS.

Ini adalah rekomendasi . Pada kenyataannya, perusahaan dapat mengabaikan beberapa poin ini tergantung pada proyek, klien, dan tim. Tapi itu selalu baik untuk memiliki beberapa bimbingan.

Persyaratan berguna apakah Anda mengkhususkan diri dalam pengembangan aplikasi iOS dan Android atau pengembangan web. Mereka adalah dokumentasi tujuan umum. Dan bagaimana tampilannya umumnya tergantung pada pengembang dan klien mereka.

Karena SRS harus mudah dipahami oleh semua pihak yang terlibat, cara terbaik untuk mendesainnya juga masih bisa diperdebatkan. Beberapa lebih suka tabel, beberapa lebih suka daftar. Ada pengembang yang lebih menyukai spesifikasinya dalam bentuk visual seperti diagram dan diagram aliran data. Tidak ada satu cara yang tepat untuk membuat dokumen spesifikasi kebutuhan.

Kesimpulan

Berikut adalah poin paling umum ketika persyaratan perangkat lunak berguna:

• Memahami tujuan
• Memperkirakan biaya pengembangan
• Membuat jadwal yang komprehensif
• Menetapkan prioritas

Apakah mendokumentasikan persyaratan adalah sesuatu yang diputuskan sendiri oleh setiap pengembang. Dan nilai kebutuhan bervariasi tergantung pada skala proyek. Di Mind Studios, kami lebih suka mengatur semuanya, jadi kami mendokumentasikan semua persyaratan . Jika Anda tertarik dengan cara kami melakukannya atau memiliki pertanyaan tentang nilai persyaratan secara umum, hubungi kami melalui formulir kontak .