Transcript Karakteristik SRS(i)

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