Software Requirements Spefication (SRS)

Presentasi berjudul: "Software Requirements Spefication (SRS)"— Transcript presentasi:

1 Software Requirements Spefication (SRS)

2 S R S : 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

3 Faktor-faktor yg dipertimbangkan dlm pembuatan SRS:
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

4 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.

5 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

6 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.

7 Fungsi dokumen SRS: mencatat semua kebutuhan calon pengguna perangkat lunak. sebagai kontrol saat proses pengembangan perangkat lunak dilakukan, sehingga setiap tahapan pengerjaan pengembangan sesuai dengan yang diharapkan. Digunakan sebagai acuan pada saat pengujian dilakukan sehingga hasil akhir sesuai dengan yang dibutuhkan. Dijadikan pedoman jika terdapat perbedaan pendapat antara calon pemakai dengan pengembang sistem terhadap hasil dari pengembangan perangkat lunak Bukti bahwa pengembang telah melakukan tahap software reguirements analysis.

8 Kriteria dokument SRS yang baik:
Benar (correct) Tepat (precise) Unambiguouity Lengkap (complete) Bisa diverifikasi (verifiable) Konsisten Understandable Bisa dimodifikasi (modifiedable) Dapat ditelusuri (traceable)

9 Harus dapat dibedakan bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan bagaimana menjelaskan what tadi) Dapat mencakup dan melingkupi seluruh sistem Dapat melingkupi semua lingkungan operasional, misalnya interaksi fisik dan operasional. Bisa menggambarkan sistem seperti yang dilihat oleh pemakai. Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan ketidak konsistenan. Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat.

10 Hindari hal-hal berikut saat pembentukan SRS
Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas) Tindakan unconcistency Ambiguity dalam kata atau kalimat Menuliskan “mimpi-mimpi” , yaitu hal-hal yang tidak bisa dilakukan

11 Aspek yg harus terlihat di SRS:
Fungsi Menjelaskan fungsi dari perangkat lunak (digunakan untuk apa keperluan apa), sifat perangkat lunak dan datanya. Non-Fungsi reliability maintainbility security integrity Ergonomic Performance

12 orang yang terlibat dalam pembuatan SRS
Pemakai (user) Merupakan orang yang akan mengoperasikan/menggunakan produk final dari perangkat lunak yang dibuat. Sponsor/ Client Orang atau perusahaan yang mau membuat sistem (yang menentukan). Sistem analyst (sistem engineer) Adalah orang yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan, menerima requirement dan menulis requirement. Software engineer Merupakan orang yang bekerja setelah kebutuhan perangkat lunak dibuat (bekerja sama dengan sistem engineer berdasarkan SRS) Programmaer Orang yang akan menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa (tes) modul.

13 Test integration group
Kumpulan orang yang melakukan tes dan mengintegrasi modul. Maintenance group Orang yang memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan). Technical Support Orang-orang yang mengelola (manage) pengembang perangkat lunak, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi. Staff dan Clerical Work Bertugas mengetik, memasukkan data dan membuat dokumen.

14 Contoh Layout Dokumen SRS
PENDAHULUAN Tujuan Ruang Lingkup Definisi Referensi Sistematika DESKRIPSI UMUM Perspektif Kegunaan Karakteristik Pengguna Batasan-batasan Asumsi dan Ketergantungan SPESISIKASI KEBUTUHAN Kebutuhan Fungsional Pendahuluan Input Proses Output

15 - Standard Compliance - Perangkat Keras - Keamanan Sistem
Kebutuhan Antarmuka Eksternal Antarmuka Pengguna Antarmuka Perangkat Keras Antarmuka Perangkat Lunak Antarmuka Komunikasi Kebutuhan Performasi Kendala Desain - Standard Compliance - Perangkat Keras #. Atribut - Keamanan Sistem - Pemeliharaan Kebutuhan Lain Database Pengoperasian Penyesuaian Tempat