Pertemuan 3

SRS
Herfia Rhomadhona
 DEFINISI

Software Requirement Spesification ( SRS ) atau

Spesifikasi Kebutuhan Perangkat Lunak ( SKPL )
adalah gambaran yang komprehensif dari tujuan
yang dimaksud dan lingkungan untuk perangkat
lunak yang sedang dikerjakan. SRS sepenuhnya
menggambarkan tentang apa yang perangkat lunak
akan lakukan dan bagaimana hal itu berjalan.
 DEFINISI (LANJUTAN)
• SRS meminimalkan waktu dan upaya yang diperlukan oleh pengembang untuk
mencapai tujuan yang diinginkan dan juga meminimalkan biaya pembangunan.

• Sebuah SRS yang baik mendefinisikan bagaimana aplikasi akan berinteraksi dengan
perangkat keras sistem ( hardware ), program lain ( other program )dan pengguna
manusia (human user) dalam berbagai situasi di dunia nyata.

• Parameter seperti kecepatan operasi, waktu respon, ketersediaan, portabilitas,

pemeliharaan, jejak, keamanan dan kecepatan pemulihan dari efek samping akan
dievaluasi.

• Metode mendefinisikan SRS dijelaskan oleh IEEE ( Institute of Electrical and

Electronic Engineer ) spesifikasi 830-1998.
 TUJUAN

• Tujuan dasar dari SRS adalah untuk menjembatani

kesenjangan komunikasi antara klien dan
pengembang, sehingga mereka memiliki visi
bersama tentang perangkat lunak yang akan
dibangun.
 Keuntungan utama dari SRS
yang baik 
• SRS menetapkan dasar kesepatakan antara Pengguna dan Pengembang
Jadi, melalui SRS, klien secara jelas menggambarkan apa yang
diharapkan dari pengembang.

• SRS menyediakan referensi untuk validasi produk akhir .

• SRS membantu klien menentukan apakah perangkat lunak yang

memenuhi persyaratan. Tanpa SRS yang tepat, tidak ada cara klien
dapat menentukan apakah perangkat lunak yang disampaikan adalah
apa yang diperintahkan, dan tidak ada cara pengembang dapat
meyakinkan klien bahwa semua persyaratan telah dipenuhi
 Yang harus diperhatikn ketika
merancang dan menulis SRS
• Interface
• Kemampuan fungsional ( Functional Capabilities )
• Tingkat kinerja ( Performance Levels )
• Struktur data / Elemen ( Data Structures / Element )
• Keselamatan ( Safety )
• Keandalan ( Reliability )
• Keamanan / privasi ( Security / Privacy )
• Kualitas ( Quality )
• Kendala dan keterbatasan (Constraints and Limitations)
 Lanjutan

Sebuah dokumen SRS biasanya mencapuk empat

bahan, seperti yang dibahas pada bagian berikut :
• Template
• Metode untuk mengidentifikasi kebutuhan dan
menghubungkan sumber
• Aturan operasi bisnis
• Matriks traceability
1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements
4. Appendices
5. Index
 Penjabaran dokumen SRS

• Purpose atau tujuan merupakan tujuan dari sebuah

perangkat lunak yang akan dikembangkan oleh tim
pengembang atau developer.
• Penjabaran mengenai user atau pemakan sistem
 Ruang lingkup
• Ruang lingkup dalam srs menjelaskan tentang :
• User Requirements : Pernyataan dan diagram, dari layanan sistem yang seperti apa yang diharapkan dan di bawah
batasan-batasan yang seperti apa.
• System Requirements : Mengatur fungsi, layanan dan batasan operasional sistem secara detail. Dokumen system
requirements (biasa disebut spesifikasi fungsional) harus tepat.

• User requirements lebih abstrak dibandingkan System requirements.

• Contoh :
• User requirements definition : SIAKAD harus bisa melacak semua data yang dibutuhkan oleh dosen dan mahasiswa.
• System requirements spesification :
• SIAKAD memiliki seorang admin yang bertugas mengelola data dosen, mahasiswa dan
mata kuliah.
• Mahasiswa dan Dosen memiliki password. Mereka juga memiliki akses yang berbeda.
• Dan seterusnya….
 Deskripsi Global Perangkat
Lunak
• Bagian ini merupakan penjelasan tentang perangkat lunak secara umum.
Dijelaskanmelalui perspektif perangkat lunak relatif terhadap konteksnya,
fungsi dasar perangkatlunak, karakteristik pengguna yang diarah, batasan-
batasan yang mempengaruhi perangkat lunak secara umum, serta asumsi dasar
yang digunakan dan kebergantungan perangkat lunak pada fenomena lain di
luar perangkat lunak.

• Bagian ini tidak memberikan kebutuhan rinci, hanya latar belakang dari
kebutuhantersebut.

• Bagian ini terdiri dari : Perspektif produk , Fungsi Produk ,

Karakteristik Pengguna, Batasan-batasan, Asumsi dan Ketergantungan
 Perspektif produk

• Bagian ini menjelaskan posisi perangkat lunak

relatif terhadap konteks sistem lain yang
melingkupinya. Jika produk tidak bergantung pada
sistem atau produk lain, makaharus juga
dinyatakan di sini. Dengan menjabarkan secara
tertulis mengenai sistem, pemakai, perangkat keras,
perangkat lunak, komunikasi, batasan memori dan
lingkungan operasional dan kebutuhan penyesuaian
(jika ada).
 Fungsi produk
• Bagian ini mengutarakan fungsi-fungsi dasar sistem yang utama. Pada
akhirnyafungsi-fungsi dasar sistem ini berimpitan dengan bubble pada level
1 DFD.

• Namunsebagai panduan kasar, yang disebut sebagai fungsi dasar sistem

adalah jawaban atasmasalah yang hendak diselesaikan melalui pembuatan
perangkat lunak ini

• Sebagai contoh SKPL untuk perangkat lunak apotek, bagian ini digunakan
untuk menjelaskan secara umu tentang pengelolaan obat, penerimaan resep,
pendaftaran pemasok tanpa menyebutkan kebutuhan rinci dari masing-
masing fungsi tersebut
 Karakteristik pengguna

Pengungkapan karakteristik pengguna dapat dilakukan dengan

menyatakannya padasebuah tabel dengan kolom-kolom:
Pengguna, Tanggung Jawab (tanggung jawabnyarelatif yang
berkaitan dengan perangkat lunak ini), Hak Akses (hak akses
inidihubungkan pula ke fungsi dasar sistem yang tertulis pada
bagian Fungsi Produk),Tingkat Pendidikan, Tingkat
Keterampilan (yang dibutuhan), Pengalaman
(yangdibutuhkan), Jenis Pelatihan (yaitu pelatihan yang
dibutuhkan agar pengguna ini dapatmelakukan tanggung
jawabnya, sifatnya opsional hanya diisi jika dibutuhkan)
 Batasan-batasan

• Bagian SPKL ini berisi deskripsi umum dari item lain yang
akan membatasi pilihanatau keputusan pada spesifikasi.
Hal-hal tersebut antara lain:
1. Kebijaksanaan umum organisasi/lingkungan
2. Keterbatasan karena perangkat keras,
contohnya kebutuhan signal timing
3. Standar antarmuka ke aplikasi atau sistem lain
4. Tuntutan pengoperasian secara paralel atau multi platform
 Asumsi dan ketergantungan

• Bagian ini mengungkapkan setiap factor yang

mempengaruhi kebutuhan yangdinyatakan pada
SKPL. Faktor-faktor ini bukan merupakan
pembatasan ataskeputusan yang diambil untuk
perancangan perangkat lunak, melainkan hal-hal di
luar cakupan perangkat lunak yang
dispesifikasikan, yang bila diubah dapat berakibat
padaatau mengubah kebutuhan yang tertulis di
SKPL.
 Spesific requirements

• mengcover requirements fungsional, non-

fungsional dan interface. Tetapi tidak ada standard
terstruktur dalam menuliskannya. Requiremet dapat
berupa external interfaces, mendeskripsikan
fungsionalitas dan performa sistem, menetapkan
requirements database logikal, desain constraints,
dan lain-lain
 Kebutuhan fungsional

• Kebutuhan fungsional harus mendefinisikan aksi

dasar yang harus diambil oleh perangkat lunak untuk
menerima dan memproses masukan dan
menghasilkan keluaran.
• Dapat dilakukan juga dengan pembagian kebutuhan
fungsional menjadi sub fungsional atausub proses.
• Dapat juga dengan menjabarkan rule bisnis yang
digambarkan pada DFD
 Kebutuhan non fungsional

Bagian ini menjelaskan kebutuhan secara teknis

meliputiL :
• Performa
• Keamanan
• reliability