SRS (Software Requirement Specifications)

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.

SRS yang baik akan bermanfaat bagi customer, supplier, ataupun perorangan. 
Manfaat-manfaat tersebut antara lain:

• Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang akan dibuat
• Mengurangi beban dalam proses pengembangan software
• Sebagai bahan perkiraan biaya dan rencana penjadwalan
• Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya
• 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.
• Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara customer dan developer.

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.

Untuk menyusun SRS, beberapa hal perlu dipertimbangkan, yaitu:

• Sifat SRS;
• Lingkungan SRS;

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)
• Penyusunan SRS secara bersama-sama;
• Evolusi SRS ;
• Membuat prototipe, seperti model atau contoh;
• Mencantumkan desain sistem di SRS;
• Pencantuman persyaratan proyek di SRS. Untuk persyaratan proyek ada dokumen tersendiri

Pada akhirnya IEEE membuat template sebuah SRS, yang isinya antara lain:

1. Introduction (Purpose, Scope, Definitions, acronyms, and abbreviations, References, Overview)
2. Overall description (Product perspective, Product functions, User characteristics, Constraints, Assumptions and dependencies)
3. Specific requirements
4. Appendixes
5. Index

Untuk specific requirements sendiri ada beberapa template yang dibuat oleh IEEE, salah satunya adalah:

- External interface requirements: User interfaces, Hardware interfaces, Software interfaces, Communications interfaces

-    Functional requirements: 

      Mode 1

      Functional requirement 1.1

      .

      .

      .

-    Functional requirement 1.n

      Mode 2

      .

      .

      .

      Mode m

          Functional requirement m.1

          .

          .

          .

         Functional requirement m.n

- Performance requirements

- Design constraints

- Software system attributes

- Other requirements

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  pengembangsistem 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

Aspek yg harus terlihat di SRS

1.     Fungsi

§  Menjelaskan fungsi dari perangkat lunak (digunakan untuk apa keperluan apa), 

    sifat perangkat lunak dan datanya

2.     Non-Fungsi

§  reliability

§  maintainbility

§  security

§  integrity

§  Ergonomic

§  Performance

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.

dikutip dari (http://cisini.wordpress.com/ dan http://blog.binadarma.ac.id/)