Software Requirements Spefication

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

1. 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
2. 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.
3. 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
4. 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.
Fungsi dokumen SRS:
1. mencatat semua kebutuhan calon pengguna perangkat
lunak.
2. sebagai kontrol saat proses pengembangan perangkat
lunak dilakukan, sehingga setiap tahapan pengerjaan
pengembangan sesuai dengan yang diharapkan.
3. Digunakan sebagai acuan pada saat pengujian
dilakukan sehingga hasil akhir sesuai dengan yang
dibutuhkan.
4. Dijadikan pedoman jika terdapat perbedaan pendapat
antara calon pemakai dengan pengembang sistem
terhadap hasil dari pengembangan perangkat lunak
5. Bukti bahwa pengembang telah melakukan tahap
software reguirements analysis.
Kriteria dokument SRS yang baik:
1. Benar (correct)
2. Tepat (precise)
3. Unambiguouity
4. Lengkap (complete)
5. Bisa diverifikasi (verifiable)
6. Konsisten
7. Understandable
8. Bisa dimodifikasi (modifiedable)
9. Dapat ditelusuri (traceable)
10. Harus dapat dibedakan bagian what (bagian spesifikasi)
dan how (bagian yang menjelaskan bagaimana
menjelaskan what tadi)
11. Dapat mencakup dan melingkupi seluruh sistem
12. Dapat melingkupi semua lingkungan operasional,
misalnya interaksi fisik dan operasional.
13. Bisa menggambarkan sistem seperti yang dilihat oleh
pemakai.
14. Harus toleran (bisa menerima) terhadap
ketidaklengkapan, ketidakpastian (ambiguous) dan
ketidak konsistenan.
15. Harus bisa dilokalisasi dengan sebuah coupling, yaitu
hubungan ketergantungan antara dua model yang tidak
terlalu erat.
 Hindari hal-hal berikut saat
pembentukan SRS

1. Over specification (penjelasan berlebih

dan berulang-ulang sehingga menjadi
tidak jelas)
2. Tindakan unconcistency
3. Ambiguity dalam kata atau kalimat
4. Menuliskan “mimpi-mimpi” , yaitu hal-hal
yang tidak bisa dilakukan
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
 orang yang terlibat dalam
pembuatan SRS
1. Pemakai (user)
Merupakan orang yang akan mengoperasikan/menggunakan produk final
dari perangkat lunak yang dibuat.

2. Sponsor/ Client
Orang atau perusahaan yang mau membuat sistem (yang menentukan).

3. Sistem analyst (sistem engineer)

Adalah orang yang biasa melakukan kontak teknik pertama dengan
client. Bertugas menganalisis persoalan, menerima requirement dan
menulis requirement.

4. Software engineer
Merupakan orang yang bekerja setelah kebutuhan perangkat lunak
dibuat (bekerja sama dengan sistem engineer berdasarkan SRS)

5. Programmaer
Orang yang akan menerima spesifikasi perancangan perangkat lunak,
membuat kode dalam bentuk modul, menguji dan memeriksa (tes)
modul.
6. Test integration group
Kumpulan orang yang melakukan tes dan
mengintegrasi modul.

7. Maintenance group
Orang yang memantau dan merawat performansi
sistem perangkat lunak yang dibuat selama
pelaksanaan dan pada saat modifikasi muncul (80%
dari pekerjaan).

8. Technical Support
Orang-orang yang mengelola (manage) pengembang
perangkat lunak, termasuk konsultan atau orang yang
mempunyai kepandaian lebih tinggi.

9. Staff dan Clerical Work

Bertugas mengetik, memasukkan data dan membuat
dokumen.
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
– 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