04/10/2015

1
 04/10/2015

 Spesifikasi Perangkat Lunak (Software

Requirements Spesification(SRS) adalah
sebuah dokumen yg berisi pernyataan
lengkap dari apa yang dapat dilakukan
oleh perangkat lunak,tanpa menjelaskn
bagaimana hal tersebut dikerjakan oleh
perangkat lunak.

2
 04/10/2015

 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 dari SRS

 Lingkungan dari SRS
 Karakteristik SRS yang baik
 Pengembangan bersama
 Evolusi SRS
 Prototyping
 Menanamkan desain pada SRS
 Menanamkan Project Requirement
pada SRS

3
 04/10/2015

 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

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

4
 04/10/2015

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

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

5
 04/10/2015

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

 SRS dibutuhkan untuk terlibat dalam

pengembangan perangkat lunak
Karena perubahan atau tambahan
dapat terjadi karena ketidak akuratan
atau kekurangan yang biasa ditemui
pada SRS.

6
 04/10/2015

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

 SRS sebaiknya menspesifikasikan fungsi

apa yang akan diperlihatkan pada data
untuk membuat hasil pada lokasi /
bagian yang mana dan didapatkan
pada bagian yang mana.

7
 04/10/2015

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

8
 04/10/2015

 Pada subsection ini harus

menggambarkan tujuan SRS dan
menentukan audience yang dituju untuk
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

9
 04/10/2015

 Subsection ini menjelaskan definisi pada

tiap istilah, akronim dan singkatan yang
nantinya akan sering digunakan dalam
penulisan 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.

10
 04/10/2015

 Pada subsection ini penulis menjelaskan

mengenai bagaimana
pengorganisasian SRS,

 Buat SRS section 1 sesuai dengan project

yang telah ditugaskan pada kelompok
anda dan Lampirkan hasil rancangan
section 1 SRS anda.

11
 04/10/2015

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

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

12
 04/10/2015

 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

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

13
 04/10/2015

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

 Subsection ini menjelaskan karakteristik

umum mengenai user seperti level
pendidikan, pengalaman, dan keahlian.

14
 04/10/2015

 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

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

15
 04/10/2015

 Suatu SRS harus mencantumkan tentang

deskripsi dgn lingkungannya.
 Mencakup antar muka untuk perangkat
keras,perangkat lunak,komunikasi dan
pemakai.
 SRS bisa terdiri dari banyak doku –
mentasi yang saling melengkapi.

 Suatu SRS harus dapat :

1. Menguraikan definisi masalah
2. Menguraikan masalah dengan tepat
dengan cara tepat pula.
 Objektif SRS :
1. Persetujuan kerja dengan pelanggan
2. Daftar kebutuhan teknis yang harus
dipenuhi perangkat lunak.

16
 04/10/2015

 Syarat pembentukan SRS:

1. Mudah diidentifikasi
2. Diuraikan dengan jelas,simple,
sederhana dan concise (jelas,tidak
ambiguous)
3. Bisa divalidasi dan bisa ditest.
4. Mampu untuk ditelusuri kembali.

 Hindari hal-hal berikut saat pembentukn SRS

:
1. Over spesification (penjelasan
berlebih dan berulang-ulang sehinga
tidak jelas.
2. Tindakan unconcistency.
3. Ambiguity dalam kata atau kalimat
4. Menuliskan hal yang tidak bisa dilakukan.

17
 04/10/2015

 Dalam suatu SRS ada 2 aspek yang

harus dilihat :
1. Fungsi
2. Non Fungsi
 Fungsi  menjelaskan fungsi dari
perangkat lunak(digunakan untuk apa
keperluan apa),sifat dan datanya.

1. Dependability
a. Reliability
b. Maintability
c. Seccurity
d. Integrity
2. Ergonomic
3. Performance
4. Constraint.

18
 04/10/2015

1. Benar (correct)  Spesifikasi yang ditulis

benar.
2. Tepat (precise)  Berpengaruh terhadap
hasil perancangan dan pembuatan
Software Requirement Design.
3. Unambiguouity  Setiap permintaan harus
punya satu interpretasi atau hanya satu
arti dalam satu kalimat.

4. Lengkap  Jika dilihat dari 2 sudut

pandang :
a. Dokumen membuat Tabel Isi,nomor
halaman,nomor gambar,nomor
tabel.
b. Tidak ada bagian yang hilang (to
be define) dari tulisan.

19
 04/10/2015

5. Bisa diverifikasi (verifiable)  Bisa

diperiksa dan dicek kebenarannya.
Setiap kebutuhan selalu dimulai
dengan dokumen yang bisa diperiksa.
6. Konsisten  Nilai-nilai kebutuhan harus
tetap sama baik dalam karakteristik
maupun spesifik.

7. Understandable  Dapat dimengerti

oleh pemogram,analis sistem atau
sistem engineer.
8. Bisa Dimodifikasi (Modifieable)  Bisa
diubah-ubah dan pengubahannya
sangat sederhana tetapi tetap
konsisten dan lengkap.

20
 04/10/2015

9. Dapat Ditelusuri (Traceable)  Jika

ditelusuri harus tahu mana bagian yang
diubah.
10. Harus dapat dibedakan bagian What
(bagian spesifikasi) dan How (bagian
yang menjelaskan What).
11. Dapat mencakup dan melingkupi
seluruh sistem.

12. Dapat melingkupi semua lingkungan

operasional.
13. Bisa menggambarkan sistem seperti
yang dilihat pemakai.
14. Harus dilokalisasi dengan coupling yaitu
hubungan ketergantungan antara dua
modul.

21
 04/10/2015

1. Pemakai (User)  Yang

mengoperasikan /menggunakan
produk final dari perangkat lunak yang
dibuat.
2. Client  Orang atau perusahaan yang
mau membuat sistem (Yang
menentukan).

3. Sistem Analis(Sistem Engineer)  Yang

biasa melakukan kontak teknik pertama
dengan client. Bertugas menganalisis
persoalan,menerima dan menulis
requirement.
4. Software Engineer  Yang bekerja
setelah kebutuhan perangkat lunak
dibuat.

22
 04/10/2015

5. Programmer  Menerima spesifikasi

perancangan perangkat lunak,
membuat kode dalam bentuk modul,
menguji dan memeriksa modul.
6. Test Integration Group  Kumpulan
orang yang melakukan test dan
mengintegrasi modul.

7. Maintenance Group  Memantau dan

merawat performansi sistem perangkat
lunak yang dibuat selama pelaksanaan
dan pada saat modifikasi muncul.
8. Technical Support  Orang-orang yang
mengelola pengembangan PL.
9. Staff & Clerical Work  Bertugas mengetik,
memasukkan data dan membuat
dokumen.

23
 04/10/2015

1. Ketelitian dari pembuatnya.

2. Kualitas dan spesifikasi perangkat lunak
yang dihasilkan.
3. Integritas
4. Proses pembuatan yang mantap.
5. Mudah dikembangkan.
6. Jumlah versi yang tidak banyak.

7. Ketelitian dari model pengembangan

yang digunakan untuk meramal atribut
perangkat lunak.
8. Efektivitas rencana test dan integrasi.
9. Tingkat persiapan untuk sistem
perawatan (mempersiapkan pencarian
bugs).

24
 04/10/2015

1. PENDAHULUAN
1.1. Tujuan
1.2. Ruang Lingkup
1.3. Defenisi
1.4. Referensi
1.5. Sistematika

2. DESKRIPSI UMUM
2.1. Perspektif
2.2. Kegunaan
2.3. Karakteristik Pengguna
2.4. Batasan-batasan
2.5. Asumsi dan Ketergantungan

25
 04/10/2015

3. SPESIFIKASI KEBUTUHAN
3.1. Kebutuhan Fungsional
3.1.1. Pendahuluan
3.1.2. Input
3.1.3. Proses
3.1.4. Output

3.2. Kebutuhan Antar Muka Eksternal

3.2.1. Antar Muka Pengguna
3.2.2. Antar Muka Perangkat Keras
3.2.3. Antar Muka Perangkat Lunk
3.2.4. Antar Muka Komunikasi
3.3. Kebutuhan Performansi,
3.4. Kendala Desain.

26
 04/10/2015

3.5. Atribut
3.5.1. Keamanan Sistem
3.5.2. Pemeliharaan.
3.6. Kebutuhan Lain
3.6.1. Database
3.6.2. Pengoperasian
3.6.3. Penyesuaian Tempat

Link Video

 https://www.youtube.com/watch?v=vA
EbMzNb_nM

27