SOFTWARE REQUIREMENT SPESIFICATION ( SRS )

BAB III
SOFTWARE REQUIREMENT SPESIFICATION ( SRS )

3.1 Pengertian Software Requirements Specification (SRS) 

Srs  adalah suatu dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Pada dasarnya SRS adalah suatu dokumen yang menyatakan kebutuhan perangkat lunak sebagai hasil dari proses analisis yang dilakukan dalam konteks pengembangan perangkat lunak. 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. Dokumen ini dibuat untuk membantu membuat spesifikasi perangkat lunak yang akan dikembangkan. Isi dari dokumen ini sebagian besar adalah terjemahan dari dokumen IEEE Std 830-1993.

IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Dengan standar itu, user dapat mencurahkan semua keinginannya 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.

3.2 Manfaat SRS

Manfaatnya yaitu :

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.

3. Hal yang perlu dipertimbangkan dalam menyusun SRS :

Sifat SRS :

a.       Fungsionalitas : Untuk apa suatu perangkat lunak dibuat.

b.      Antar muka eksternal (External Interface) : Dengan apa perangkat lunak berinteraksi dengan user, system hardware, perangkat keras di luar sistem dan perangkat lunak lain.

c.       Performansi : Sejauh apa kecepatan, ketersediaan (availability), waktu tanggap (response time),waktu recovery dari berbagai fungsi perangkat lunak yang dibuat.

d.      Atribut : Seberapa tingkat portabilitas, tingkat kebenaran (correctness), tingkatpemeliharaan (maintainability), dan tingkat keamanan yang ingin dicapai.

e.       Batasan perancangan : Apakah diperlukan suatu standar, bahasa yang khusus, kebijaksanaan integritasbasisdata, batasan sumberdaya, lingkungan operasi, dan lain-lain yang membatasi pilihan-pilihan yang bisa digunakan atau keputusan-keputusan yang bisa diambilketika perancangan.

Lingkungan SRS :

Mengingat SKPL pada akhirnya akan menjadi dasar bagi kontrak antara developer dan customer , maka suatu dokumen SKPL harus memenui syarat-syarat berikut:

Mendefinisikan kebutuhan software dengan benar. Kebutuhan software muncul karena ada pekerjaan yang harus diselesaikan atau karena ada karakteristik khusus dari proyek.

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

Tidak memaksakan penambahan suatu batasan dari perangkat lunak

Karakteristik dari SRS yang baik, yaitu:

·         Correct (benar)

·         Unambiguous (tidak ambigu, tapi jelas)

·         Complete (lengkap)

·         Consistent (konsisten)

·         Ranked for importance and/or stability (prioritas penting dan atau stabilitas)

·         Verifiable (dapat diverifikasi)

·         Modifiable (bisa dimodifikasi)

·         Traceable (bisa dilacak