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

• 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).

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

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

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.

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.

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.

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.

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.

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.

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.

Penanaman project requirement pada SRS

• Cost• Jadwal pengiriman• Laporan prosedur • Metode pengembangan software• Jaminan kualitas• Kriteria validasi dan verfikasi• Prosedur penerimaan ( acceptance)

SRS Outline IEEE

Tujuan ( Subbab 1.1 SRS)

• Pada subsection ini harus menggambarkan tujuan SRS dan menentukan audience yang dituju untuk SRS.

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

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.

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.

Penjelasan umum dokumen (subbab 1.5 SRS)

• Pada subsection ini penulis menjelaskan mengenai bagaimana pengorganisasian SRS,

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.

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

sabrian@ub.ac.id 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.

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.

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.

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

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.

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.

Karakteristik user (subbab 2.3 SRS)

• Subsection ini menjelaskan karakteristik umum mengenai user seperti level pendidikan, pengalaman, dan keahlian.

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

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.