software requirement specification
DESCRIPTION
Software Requirement Specification. IEEE STD 830-1998. SRS Overview. Software requirement specification merupakan fungsi dan kinerja yang dialokasikan untuk perangkat lunak sebagai bagian dari sistem rekayasa perangkat lunak secara garis besar - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/1.jpg)
Software Requirement Specification
IEEE STD 830-1998
![Page 2: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/2.jpg)
SRS Overview
• Software requirement specification merupakan fungsi dan kinerja yang dialokasikan untuk perangkat lunak sebagai bagian dari sistem rekayasa perangkat lunak secara garis besar
• membahas mengenai deskripsi informasi lengkap, penjelasan rinci fungsional, representasi dari perilaku sistem, persyaratan kinerja dan kendala desain, kriteria validasi yang sesuai dan lainnya yang berkaitan dengan persyaratan (requirement).
![Page 3: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/3.jpg)
Sifat SRS
• Sifat dari SRS• Lingkungan dari SRS• Karakteristik SRS yang baik• Pengembangan bersama• Evolusi SRS• Prototyping• Menanamkan desain pada SRS• Menanamkan Project Requirement pada SRS
![Page 4: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/4.jpg)
Yang harus diperhatikan
• Functionallity, apa yang perangkat lunak seharusnya lakukan ?
• External interfaces, bagaimana software tersebut berinteraksi dengan seseorang, sistem hardware, hardware yang lain dan software yang lain yang mendukung.
• Performance, Bagaimana kecepatan software, kesiapan, respons time, recovery time, dsb
• Attributes, Portabilitas, kebenaran software, perawatan, keamanan dsb.
• Kendala desain pada waktu implementasi, apakah ada standar yang harus diterapkan, kendala bahasa, aturan integrasi database, dsb
![Page 5: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/5.jpg)
Karakteristik SRS(i)• Betul
– SRS dianggap betul jika dan hanya jika setiap requirement yang dicantumkan adalah memang apa yang harus software butuhkan.
• Tidak ambigu– SRS dikatakan tidak ambigu bila requirement yang dicantumkan hanya memiliki satu interprestasi.
• Lengkap– SRS dikatakan lengkap apabila telah memenuhi beberapa elemen seperti requirement yang signifikan ( fungsi, unjuk kerja,hambatan, dsb), mendefinisikan respon dari perangkat lunak dari setiap situasi, melengkapi label dan referensi untuk setiap gambar, tabel, dan diagram pada SRS dan definisi dari setiap istilah dan pengukuran.
![Page 6: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/6.jpg)
Karakteristik SRS(ii)
• Konsisten– SRS dikatakan konsisten bila tidak ada requirement yang bisa menimbulkan konflik.
• Stabilitas– Dapat dinyatakan dalam jumlah perubahan yang diharapkan untuk setiap persyaratan berdasarkan pengalaman atau pengetahuan tentang kejadian yang akan datang yang mempengaruhi organisasi, fungsi dan orang-orang yang didukung oleh perangkat lunak tersebut.
![Page 7: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/7.jpg)
Karakteristik SRS(iii)• Dapat diverifikasi
– SRS dikatakan dapat diverifikasi apabila setiap requirement yang dicantumkan dapat diverifikasi.
• Dapat dimodifikasi– SRS dikatakan dapat dimodifikasi bila setiap struktur dan style SRS dapat mengatasi adanya perubahan pada requirement dengan mudah, komplit, dan konsisten dengan tetap mempertahankan strukur dan style dari SRS tersebut.
• Dapat dilacak– SRS dikatakan dapat dilacak apabila sumber dari setiap requirement yang dicantumkan jelas dan mampu memfasilitasi referensi dari setiap requirement pada pengembangan selanjutnya.
![Page 8: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/8.jpg)
Pengembangan bersama
• Pengembangan perangkat lunak biasanya dimulai dari perjanjian antara supplier dan customer mengenai apa yang harus perangkat lunak kerjakan. Hal ini penting karena umumnya baik customer maupun supplier tidak mampu untuk mengerjakan kualifikasi SRS dengan baik.
![Page 9: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/9.jpg)
Evolusi SRS
• SRS dibutuhkan untuk terlibat dalam pengembangan perangkat lunak Karena perubahan atau tambahan dapat terjadi karena ketidak akuratan atau kekurangan yang biasa ditemui pada SRS.
![Page 10: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/10.jpg)
Prototyping
• Prototyping sering digunakan selama pembuatan requirement pada sebuah project. Prototypes berguna dengan alasan sebagai berikut :– Customer lebih suka untuk melihat sebuah prototype dan memberikan reaksi daripada harus membaca SRS.
– Prototype menampilkan aspek perilaku sistem. Dengan prototype kita tidak hanya dapat memberikan jawaban tapi pertanyaan. Hal ini membantu kita dalam penulisan SRS.
– SRS yang berbasis prototype sedikitnya mencegah adanya perubahan pada masa pengembangan yang artinya juga mempersingkat waktu pengembangan.
![Page 11: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/11.jpg)
Penanaman desain pada SRS
• SRS sebaiknya menspesifikasikan fungsi apa yang akan diperlihatkan pada data untuk membuat hasil pada lokasi / bagian yang mana dan didapatkan pada bagian yang mana.
![Page 12: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/12.jpg)
Penanaman project requirement pada SRS
• Cost• Jadwal pengiriman• Laporan prosedur • Metode pengembangan software• Jaminan kualitas• Kriteria validasi dan verfikasi• Prosedur penerimaan ( acceptance)
![Page 13: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/13.jpg)
SRS Outline IEEE
![Page 14: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/14.jpg)
Tujuan ( Subbab 1.1 SRS)
• Pada subsection ini harus menggambarkan tujuan SRS dan menentukan audience yang dituju untuk SRS.
![Page 15: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/15.jpg)
Lingkup masalah (subbab 1.2 SRS)
• Identifikasi produk software untuk menghasilkan sebuah nama (contoh: Report generator , Host DBMS, dsb)
• Menjelaskan apa harapan dengan adanya software ini dan bila mungkin cantumkan juga apa yang tidak diharapkan.
• Menjelaskan aplikasi spesifikasi perangkat lunak termasuk keuntungan yang didapatkan dan tujuan
![Page 16: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/16.jpg)
Definisi, akronim dan singkatan (subbab 1.3 SRS)
• Subsection ini menjelaskan definisi pada tiap istilah, akronim dan singkatan yang nantinya akan sering digunakan dalam penulisan SRS.
![Page 17: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/17.jpg)
Referensi (subbab 1.4 SRS)
• Subsection ini menyediakan daftar lengkap dari dokumen referensi yang digunakan pada SRS. Mengidentifikasikan setiap dokumen dengan judul , versi edisi, tahun, dan penerbit. Pada bagian ini penulis juga menuliskan sumber referensi yang didapatkan.
![Page 18: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/18.jpg)
Penjelasan umum dokumen (subbab 1.5 SRS)
• Pada subsection ini penulis menjelaskan mengenai bagaimana pengorganisasian SRS,
![Page 19: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/19.jpg)
Hasil Praktikum
• Buat SRS section 1 sesuai dengan project yang telah ditugaskan pada kelompok anda dan Lampirkan hasil rancangan section 1 SRS anda pada laporan praktikum.
![Page 20: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/20.jpg)
Peraturan Asistensi• Hasil praktikum dan tugas praktikum dikumpulkan selambat-
lambatnya 3 hari setelah penjelasan bab praktikum.• Revisi dikumpulkan maksimal 3 hari setelah menerima
masukan / koreksi dari saya• Asistensi dilakukan melalui email dengan ke
[email protected] dengan judul/subject email sebagai berikut :– <praktikum RPL TI Vokasi> bab x, Judul bab , kelompok:x,
nama project.– Cantumkan anggota kelompok, NIM & alamat email masing-
masing kelompok di isi email – attach hasil dan tugas praktikum berupa file doc / docx
• Hasil praktikum dan tugas praktikum di cetak / diprint setelah mendapatkan verifikasi dari saya. Dan dilampirkan pada modul praktikum.
• Keterlambatan pengumpulan tugas tidak dapat ditoleransi dengan penalty nilai 0 pada bab praktikum yang dikerjakan.
![Page 21: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/21.jpg)
Section 2 : Overall Description
• Perspektif produk / Deskripsi umum perangkat lunak (subbab 2.1 SRS)– Pada subsection ini kita menjelaskan perspektif produk kita dengan produk yang lain yang berhubungan.
– Jika produk yang kita rancang nantinya adalah sebuah produk yang independen atau dapat berdiri sendiri maka kita harus mencantumkan hal tersebut kedalam SRS.
– Bila produk yang kita rancang adalah sebuah komponen dari sistem yang lebih besar, maka pada subsection ini penulis harus menjelaskan hubungan requirement produk kita dengan sistem dan harus mengidentifikasikan antarmuka produk kita dengan sistem yang menaungi.
![Page 22: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/22.jpg)
Sub bab 2.1 SRS Perspektif produk
• Subsection ini juga harus menjelaskan bagaimana software beroperasi didalam berbagai macam batasan seperti :– Antarmuka sistem
• Daftar dari antarmuka sistem dan identifikasi fungsionalitas dari perangkat lunak.
– Antarmuka user• Menjelaskan karakteristik dari setiap antarmuka antara produk perangkat lunak dan penggunanya. Bagian ini juga menjelaskan semua aspek antarmuka orang yang menggunakan sistem tersebut.
![Page 23: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/23.jpg)
Sub bab 2.1 SRS Perspektif produk
• Antarmuka perangkat keras– Menjelaskan karakteristik antarmuka antara produk perangkat lunak dan komponen perangkat keras dari sistem.
• Antarmuka perangkat lunak– Menjelaskan penggunaan perangkat lunak lain yang dibutuhkan.
• Antarmuka komunikasi– Menjelaskan berbagai antarmuka komunikasi seperti protokol jaringan lokal,dsb.
• Memori
![Page 24: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/24.jpg)
Sub bab 2.1 SRS Perspektif produk
• Operasi– Menjelaskan berbagai mode operasi pada organisasi user, periode operasi, operasi backup atau recovery.
• Kebutuhan adaptasi di site.– Menjelaskan requirement data atau urutan inisialisasi yang spesifik pada site, misi site dan mode operasi.
![Page 25: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/25.jpg)
Fungsi Produk (subbab 2.2 SRS)
• Pada subsection ini SRS harus menyediakan ringkasan dari fungsi utama yang akan diperlihatkan software. – Fungsi harus diorganisasikan sehingga daftar fungsi tersebut bisa dimengerti oleh customer atau siapapun yang membaca dokumen ini untuk pertama kali.
– Penjelasan dapat berupa bentuk Text atau gambar untuk menjelaskan perbedaan fungsi atau hubungannya.
![Page 26: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/26.jpg)
Karakteristik user (subbab 2.3 SRS)
• Subsection ini menjelaskan karakteristik umum mengenai user seperti level pendidikan, pengalaman, dan keahlian.
![Page 27: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/27.jpg)
Batasan (subbab 2.4 SRS)
• Subsection ini menjelaskan deskripsi umum mengenai apa yang akan membatasi pengembangan produk. Hal ini mencakup:– Aturan / regulasi– Keterbatasan perangkat keras– Antarmuka terhadap aplikasi lain– Keamanan dan keselematan – Dsb
![Page 28: Software Requirement Specification](https://reader033.vdocuments.net/reader033/viewer/2022061509/56813590550346895d9cfd68/html5/thumbnails/28.jpg)
Lingkup Operasi (subbab 2.5 SRS)
• Pada subsection ini dijelaskan spesifikasi faktor yang mempengaruhi requirement yang telah dijelaskan pada SRS. Misalkan Operating system yang digunakan pada sisi klien atau server, bahasa pemrograman yang digunakan,dsb.