Software Requirement Specifications

Software Requirement Specifications

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.

Ada beberapa istilah yang digunakan dan harus diketahui untuk memahami standar SRS yang dibuat IEEE ini. Istilah-istilah tersebut adalah:

• 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.
• Customer (pelanggan) : Pihak yang membayar untuk produk dan biasanya yang menentukan persyaratan (requirements).
• Supplier (pemasok): Pihak yang membuat produk software untuk customer.
• Pengguna: Pihak yang mengoperasikan atau berinteraksi langsung dengan software. Pengguna dan customer biasanya bukan orang yang sama.

Sifat dari SKPL / SRS :

Penulis SKPL harus memperhatikan hal-hal berikut:

1. Fungsionalita.

2. Antar muka eksternal (External Interface).

3. PerformansiSejauh apa kecepatan, ketersediaan (availability), waktu tanggap (response time),waktu recovery dari berbagai fungsi perangkat lunak yang dibuat.

4. Atribut

5. Batasan perancangan 

Penulis SKPL tidak sepatutnya menuliskan spesifikasi rancangan atau kebutuhanproyek secara keseluruhan dalam SKPL. Untuk itulah penulis SKPL sepatutnya dapatmembedakan hasil pekerjaan mana yang termasuk hasil analisis dan mana yangtermasuk hasil perancangan.

Lingkungan SKPL / SRS :

Karena SKPL akan memainkan peranan penting dalam proses pengembangan perangkat lunak, penulis SKPL harus secara berhati-hati dalam memainkanperanannya (yang menuangkan hasil kerja pada suatu dokumen yang dijadikan dasar –baseline). Mengingat SKPL pada akhirnya akan menjadi dasar bagi kontrak antarapengembang dan pelanggan, maka suatu dokumen SKPL harus memenui syarat-syarat berikut:

1. Mendefinisikan kebutuhan perangkat lunak dengan benar. Kebutuhan perangkatlunak muncul karena ada pekerjaan yang harus diselesaikan atau karena adakarakteristik khusus dari proyek.

2. Tidak menjelaskan rancangan atau implementasi dengan rinci. Penjelasan tersebuttidak diperlukan karena bagi pengguna hal tersebut lebih teknis dan tidak perlu.

3. Tidak memaksakan penambahan suatu batasan dari perangkat lunak

Karakterisitk SKPL / SRS :

Karakterisitk SKPL yang baik adalah sebagai berikut:

1. Benar

2. Tidak ambigu

3. Lengkap

4. Konsisten

5. Terurut berdasarkan kepentingannya atau kestabilannya

6. Dapat diverifikasi

7. Dapat dimodifikasi

8. Dapat ditelusuri (traceable)

Refrensi / sumber :

1. http://cisini.wordpress.com/2012/10/16/srs/

2. http://mr-freeman-blog.blogspot.com/2010/03/spesifikasi-kebutuhan-perangkat-lunak.html