Software Requirement Spesification (SRS)

Software Requirement Spesification (SRS)

Muhammad Imam Naufal JD 
NIM (1901301068)

1.Pengertian Software Requirement Spesification (SRS )

Software Requirement Spesification ( SRS ) atau Spesifikasi Kebutuhan Perangkat Lunak ( SKPL ) adalah gambaran yang komprehensif dari tujuan yang dimaksud dan lingkungan untuk perangkat lunak yang sedang dikerjakan. SRS sepenuhnya menggambarkan tentang apa yang perangkat lunak akan lakukan dan bagaimana hal itu berjalan.

2.Tujuan dasar (SRS )

Tujuan dasar dari SRS adalah untuk menjembatani kesenjangan komunikasi antara klien dan pengembang, sehingga mereka memiliki visi bersama tentang perangkat lunak yang akan dibangun.

3.Keuntungan utama dari SRS

  • SRS menetapkan dasar kesepatakan antara Pengguna dan Pengembang Jadi, melalui SRS, klien secara jelas menggambarkan apa yang diharapkan dari pengembang.

  • SRS menyediakan referensi untuk validasi produk akhir .

  • SRS membantu klien menentukan apakah perangkat lunak yang memenuhi persyaratan. Tanpa SRS yang tepat, tidak ada cara klien dapat menentukan apakah perangkat lunak yang disampaikan adalah apa yang diperintahkan, dan tidak ada cara pengembang dapat meyakinkan klien bahwa semua persyaratan telah dipenuhi.

4.   Yang harus diperhatikan ketika merancang dan menulis SRS.

✘Interface

✘Kemampuan fungsional ( Functional Capabilities )

✘Tingkat kinerja ( Performance Levels )

✘Struktur data / Elemen ( Data Structures / Element )

✘Keselamatan ( Safety )

✘Keandalan ( Reliability )

✘Keamanan / privasi ( Security / Privacy )

✘Kualitas  ( Quality )

✘Kendala dan keterbatasan  (Constraints and Limitations).

5.Penjabaran dokumen SRS

✘  Purpose atau tujuan merupakan tujuan dari sebuah perangkat lunak yang akan dikembangkan oleh tim pengembang atau developer.

✘  Penjabaran mengenai user atau pemakan sistem.

6.Ruang Lingkup SRS

✘Ruang lingkup dalam srs menjelaskan tentang :

○User Requirements : Pernyataan dan diagram, dari layanan sistem yang seperti apa yang diharapkan dan di bawah batasan-batasan yang seperti apa.

○System Requirements : Mengatur fungsi, layanan dan batasan operasional sistem secara detail. Dokumen system requirements (biasa disebut spesifikasi fungsional) harus tepat.

✘User requirements lebih abstrak dibandingkan System requirements.

Contoh :

○User requirements definition : SIAKAD harus bisa melacak semua data yang dibutuhkan oleh dosen dan mahasiswa.

○System requirements spesification :

■SIAKAD memiliki seorang admin yang bertugas mengelola data dosen, mahasiswa dan mata kuliah.

■Mahasiswa dan Dosen memiliki password. Mereka juga memiliki akses yang berbeda.

■Dan seterusnya.

7.Deskripsi Global Perangkat Lunak SRS

    • Bagian ini merupakan penjelasan tentang perangkat lunak secara umum. Dijelaskanmelalui perspektif perangkat lunak relatif terhadap konteksnya, fungsi dasar perangkatlunak, karakteristik pengguna yang diarah, batasan-batasan yang mempengaruhi perangkat lunak secara umum, serta asumsi dasar yang digunakan dan kebergantungan perangkat lunak pada fenomena lain di luar perangkat lunak.

    • Bagian ini tidak memberikan kebutuhan rinci, hanya latar belakang dari kebutuhantersebut.

    • Bagian ini terdiri dari : Perspektif produk , Fungsi Produk , Karakteristik Pengguna,  Batasan-batasan. Asumsi dan Ketergantungan.

8.Perspektif produk SRS

        Bagian ini menjelaskan posisi perangkat lunak relatif terhadap konteks sistem lain yang melingkupinya. Jika produk tidak bergantung pada sistem atau produk lain, makaharus juga dinyatakan di sini. Dengan menjabarkan secara tertulis mengenai sistem, pemakai, perangkat keras, perangkat lunak, komunikasi, batasan memori dan lingkungan operasional dan kebutuhan penyesuaian (jika ada).

9.Fungsi produk SRS

  ✘ Bagian ini mengutarakan fungsi-fungsi dasar sistem yang utama. Pada akhirnyafungsi-fungsi dasar sistem ini berimpitan dengan bubble pada level 1 DFD.

  ✘ Namunsebagai panduan kasar, yang disebut sebagai fungsi dasar sistem adalah jawaban atasmasalah yang hendak diselesaikan melalui pembuatan perangkat lunak ini

  ✘ Sebagai contoh SKPL untuk perangkat lunak apotek, bagian ini digunakan untuk menjelaskan secara umu tentang pengelolaan obat, penerimaan resep, pendaftaran pemasok tanpa menyebutkan kebutuhan rinci dari masing-masing fungsi tersebut.

10.Karakteristik Pengguna SRS

      Pengungkapan karakteristik pengguna dapat dilakukan dengan menyatakannya padasebuah tabel dengan kolom-kolom: Pengguna, Tanggung Jawab (tanggung jawabnyarelatif yang berkaitan dengan perangkat lunak ini), Hak Akses (hak akses inidihubungkan pula ke fungsi dasar sistem yang tertulis pada bagian Fungsi Produk),Tingkat Pendidikan, Tingkat Keterampilan (yang dibutuhan), Pengalaman (yangdibutuhkan), Jenis Pelatihan (yaitu pelatihan yang dibutuhkan agar pengguna ini dapatmelakukan tanggung jawabnya, sifatnya opsional hanya diisi jika dibutuhkan).

11.Batasan - Batasan SRS

       Bagian SPKL ini berisi deskripsi umum dari item lain yang akan membatasi pilihanatau keputusan pada spesifikasi. Hal-hal tersebut antara lain: 

    1. Kebijaksanaan umum organisasi/lingkungan

   2. Keterbatasan karena perangkat keras, contohnya kebutuhan signal timing

   3. Standar antarmuka ke aplikasi atau sistem lain

   4. Tuntutan pengoperasian secara paralel atau multi platform.

12.Asumsi Ketergantungan Pada SRS

       Bagian ini mengungkapkan setiap factor yang mempengaruhi kebutuhan yangdinyatakan pada SKPL. Faktor-faktor ini bukan merupakan pembatasan ataskeputusan yang diambil untuk perancangan perangkat lunak, melainkan hal-hal di luar cakupan perangkat lunak yang dispesifikasikan, yang bila diubah dapat berakibat padaatau mengubah kebutuhan yang tertulis di SKPL.

13.Spesific requirements

       mengcover requirements fungsional, non-fungsional dan interface. Tetapi tidak ada standard terstruktur dalam menuliskannya. Requiremet dapat berupa external interfaces, mendeskripsikan fungsionalitas dan performa sistem, menetapkan requirements database logikal, desain constraints, dan lain-lain.

14.Kebutuhan Fungsional SRS

   ✘ Kebutuhan fungsional harus mendefinisikan aksi dasar yang harus diambil oleh perangkat lunak untuk menerima dan memproses masukan dan menghasilkan keluaran.

   ✘ Dapat dilakukan juga dengan pembagian kebutuhan fungsional menjadi sub fungsional atausub proses.

   ✘ Dapat juga dengan menjabarkan rule bisnis yang digambarkan pada DFD.

15.Kebutuhan Non Fungsional SRS

      Kebutuhan non fungsional

Bagian ini menjelaskan kebutuhan secara teknis meliputi :

 • Performa

• Keamanan

• reliability.