Software Requirements Specification (SRS)

Apa itu SRS/SKPL?

• Sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak
• Mencantumkan deskripsi perangkat lunak dengan lingkungannya (Mencakup antarmuka untuk perangkat keras, perangkat lunak, komunikasi dan pemakai).
• SRS umumnya dikembangkan bersama oleh calon pengguna dan para pengembang system/perangkat lunak

Faktor-faktor yang dipertimbangkan dlm pembuatan SRS

1. Untuk Siapa perangkat lunak dikembangkan ?
   • Siapa yang menyediakan dana ?
   • Kepada siapa proposal pengembangan perangkat lunak akan diberikan ?
   • Yakinkan calon pengguna bahwa perangkat lunak yang akan dibuat memang dibutuhkan
2. Masalah apa yang akan diselesaikan dengan kehadiran perangkat lunak yang baru ?
   • Seorang analis perlu berfikir dengan seksama masalah apa yang akan diselesaikan dengan kehadiran perangkat lunak baru.
   • Harus dingat.! Komputer hanya alat bantu. Komputer tidak dapat memecahkan semua masalah yang ada pada suatu perusahaan.
3. Dimana perangkat lunak akan diimplementasikan ?
   • Karakteristik yang berbeda terhadap kebutuhan calon pengguna akan mempengaruhi model dan desain perangkat lunak yang dikembangkan, termasuk implementasi di lapangan
4. Kapan perangkat lunak yang baru sudah harus dijalankan ?
   • para pengembang harus memperhatikan kapan waktu dimulainya pengerjaan proyek pengembangan perangkat lunak baru dan kapan waktu perangkat lunak tersebut sudah harus dikembangkan
   • Berpengaruh terhadap model pengembangan perangkat lunak yang akan dipergunakaan.

Fungsi dokumen SRS

1. Mencatat semua kebutuhan calon pengguna perangkat lunak.
2. Sebagai kontrol saat proses pengembangan perangkat lunak dilakukan, sehingga setiap tahapan pengerjaan pengembangan sesuai dengan yang diharapkan.
3. Digunakan sebagai acuan pada saat pengujian dilakukan sehingga hasil akhir sesuai dengan yang dibutuhkan.
4. Dijadikan pedoman jika terdapat perbedaan pendapat antara calon pemakai dengan pengembang sistem terhadap hasil dari pengembangan perangkat lunak
5. Bukti bahwa pengembang telah melakukan tahap software reguirements analysis.

Kriteria dokument SRS yang baik

1. Benar (correct)
2. Tepat (precise)
3. Unambiguouity
4. Lengkap (complete)
5. Bisa diverifikasi (verifiable)
6. Konsisten
7. Understandable
8. Bisa dimodifikasi (modifiedable)
9. Dapat ditelusuri (traceable)
10. Harus dapat dibedakan bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan bagaimana menjelaskan what tadi)
11. Dapat mencakup dan melingkupi seluruh sistem
12. Dapat melingkupi semua lingkungan operasional, misalnya interaksi fisik dan operasional.
13. Bisa menggambarkan sistem seperti yang dilihat oleh pemakai.
14. Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan  ketidak konsistenan.
15. Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat.

Hindari hal-hal berikut saat pembentukan SRS

1. Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas)
2. Tindakan unconcistency
3. Ambiguity dalam kata atau kalimat
4. Menuliskan “mimpi-mimpi” , yaitu hal-hal yang tidak bisa dilakukan

Orang yang terlibat dalam pembuatan SRS

1. Pemakai (user)
   • Merupakan orang yang akan mengoperasikan/menggunakan produk final dari perangkat lunak yang dibuat.
2.  Sponsor/ Client
   •  Orang atau perusahaan yang mau membuat sistem (yang menentukan).
3.  Sistem analyst (sistem engineer)
   •  Adalah orang yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan, menerima requirement dan menulis requirement.
4.  Software engineer
   •  Merupakan orang yang bekerja setelah kebutuhan perangkat lunak dibuat (bekerja sama dengan sistem engineer berdasarkan SRS)
5.  Programmaer
   •  Orang yang akan menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa (tes) modul.
6. Test integration group
   • Kumpulan orang yang melakukan tes dan mengintegrasi modul.
7.  Maintenance group
   •  Orang yang memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan).
8. Technical Support
   • Orang-orang yang mengelola (manage) pengembang perangkat lunak, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi.
9. Staff dan Clerical Work
   • Bertugas mengetik, memasukkan data dan membuat dokumen.