PERTEMUAN 3 SOFTWARE REQUIREMENT SPESIFICATION (SRS)

2.1 Pengertian software requirement spesification (SRS)

Secara sederhana, Software Requirement Specifications (SRS) adalah dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Dokumen ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai software. Pembuatannya pun seharusnya mengikuti standar yang ada dan paling diakui oleh para praktisi rekayasa software di dunia. Oleh karena itu, standar yang akan dibahas di sini adalah standar dari IEEE. IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Lengkap. Dengan standar itu, si penggguna dapat mencurahkan semua keinginannya terkait software tersebut dengan jelas dan akurat sehingga sang developer pun dapat memahami apa yang diinginkan pengguna dengan tepat. Bahkan, bagi perorangan, standar ini dapat membantunya dalam mengembangkan outline SRS yang baku khusus untuk perusahaannya, membantunya membuat dokumen SRS dengan format dan isi yang standar (minimal), serta membantunya mengembangkan rincian-rincian pendukung lainnya.

2.2 Manfaat software requirement spesification (SRS)

RS yang baik akan bermanfaat bagi customer, supplier, ataupun perorangan. Manfaat-manfaat tersebut antara lain: 1. Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang akan dibuat 2. Mengurangi beban dalam proses pengembangan software 3. Sebagai bahan perkiraan biaya dan rencana penjadwalan 4. Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya 5. Memfasilitasi transfer, semisal software tersebut ingin ditransfer ke pengguna atau mesin-mesin yang lain. Customer pun merasa mudah jika ingin mentransfer software ke bagian-bagian lain dalam organisasinya. Bahkan, jika terjadi pergantian personil developer, proyek dapat mudah ditransfer ke personil baru dengan memahami SRS ini. 6. Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara customer dan developer.

2.3 Istilah-Istilah software requirement spesification (SRS)

Ada beberapa istilah yang digunakan dan harus diketahui untuk memahami standar SRS yang dibuat IEEE ini. Istilah-istilah tersebut adalah: a. Kontrak: dokumen yang mengikat secara hukum dan disepakati oleh customer dan supplier, termasuk syarat-syarat teknologi dan organisasi, biaya, serta jadwal pengerjaan. Kontrak bisa mengandung sesuatu yang kurang formal tetapi bermanfaat, seperti komitmen atau harapan dari pihak yang terlibat. b. Customer (pelanggan) : Pihak yang membayar untuk produk dan biasanya yang menentukan persyaratan (requirements). c. Supplier (pemasok): Pihak yang membuat produk software untuk customer. d. Pengguna: Pihak yang mengoperasikan atau berinteraksi langsung dengan software. Pengguna dan customer biasanya bukan orang yang sama.

2.4 Cara menyusun dokumen software requirement spesification (SRS)

Cara terbaik untuk menyusun dokumen SRS adalah memulainya dengan membuat kerangka dan informasi umum tentang software yang akan Anda kembangkan dan menambahkan detail untuk menyempurnakan draf dokumennya. Berikut adalah enam langkah yang bisa dilakukan untuk menyusun dokumen SRS Anda: 1. Membuat sebuah outline dokumen Langkah paling awal dalam membuat dokumen SRS adalah dengan menyusun kerangka atau outline dokumen. Anda dapat menyusunnya dengan kreasi Anda sendiri atau menggunakan template dari dokumen SRS sebagai pedoman awal. Berikut ini contoh mendasar dari sebuah kerangka dalam dokumen SRS: a. Pengantar b. Tujuan Pengembangan c. Audiens d. Tujuan Penggunaan e. Cakupan Pengembangan f. Definisi Berbagai Fungsi g. Deskripsi Keseluruhan h. Kebutuhan Pengguna i. Asumsi dan Dependensi j. Fitur dan Kebutuhan Sistem 2. Mendefinisikan Tujuan Anda Setelah Anda menyusun outline, Anda harus menyempurnakannya dengan menentukan tujuan softwareyang akan Anda buat dalam awalan dokumen SRS. Bagian ini merupakan penjelasan mengenai audiens yang dituju dan cara mereka menggunakan softwareyang akan dibuat. 3. Memberikan Gambaran Umum Bagian berikutnya setelah Anda menentukan tujuan produk yang akan Anda hasilkan adalah merangkum cara kerjanya. Bagian ini merupakan penjelasan mengenai deskripsi yang cukup general tentang fitur di dalam software dan cara fitur-fitur tersebut berjalan sesuai dengan kebutuhan penggunanya. Anda juga perlu menjelaskan tentang asumsi yang Anda buat tentang fungsi dari software dan apapun yang bergantung padanya dalam ekosistem teknologi saat ini. 4. Mendeskripsikan Spesifikasi Fungsional dan Non-Fungsional Sekarang Anda telah sampai pada bagian yang lebih spesifik yakni mendeskripsikan sistem fungsional dan non-fungsional. Penyusunan tiga hal sebelum masuk ke dalam bagian ini membuat Anda memiliki referensi untuk memastikan bahwa segala hal yang Anda lakukan telah memenuhi kebutuhan dasar dari pengguna softwareAnda. Hal tersebut juga memudahkan Anda dalam mengisi hal yang lebih detail ke depannya, seperti bagian spesifikasi fungsional dan non-fungsional ini. Bagian ini merupakan deskripsi detail tentang kebutuhan sistem softwareAnda. Hal ini bisa dikatakan sebagai komponen paling penting dalam dokumen SRS Anda. Jelaskan kebutuhan sistem fungsional dengan cukup detail sehingga software developerAnda dapat mulai bekerja seperti yang Anda inginkan dan juga jangan lupakan sistem non-fungsional seperti performance software dan sekuritasnya. Dalam bagian ini juga Anda dapat menambahkan use cases untuk menjelaskan tentang cara pengguna berinteraksi dengan sistem Anda. Di sinilah Anda memerinci tujuan proyek dan mengukur indikator kemajuan proyek selama proses pengembangan software Anda berlangsung. 5. Menambahkan Detail Pelengkap Terakhir dalam penyusunan draf dokumen SRS, Anda perlu menambahkan detail pelengkap sehingga pihak ketiga selaku pengembang perangkat lunak Anda dapat memulai dan menyelesaikan pekerjaan mereka dalam bentuk lampiran, daftar istilah, dan referensi yang juga Anda ketahui. 6. Mengajukan Persetujuan Terhadap Dokumen Ketika Anda sudah menambahkan berbagai hal detail yang dibutuhkan, kini saatnya meminta persetujuan dari pihak-pihak yang dianggap berwenang (seperti atasan Anda atau jajaran manajerial) terhadap draf dokumen SRS yang telah Anda buat. Kadang dibutuhkan presentasi kepada orang-orang yang terlibat dalam proses software development nantinya untuk menjelaskan draf dokumen SRS ini. Tidak menutup kemungkinan akan ada permintaan perubahan atau revisi sehingga Anda harus memperbarui draf dokumen SRS Anda. Tetapi Anda jangan berkecil hati. Ini artinya pihak-pihak yang terlibat, baik dari pengembang software Anda dan para pemangku kepentingan di perusahaan Anda, membuat dokumen tersebut lebih tepat sehingga proyek software development yang direncanakan tidak akan keluar jalur.