SRS

Review & Summarize



REKAYASA KEBUTUHAN PERANGKAT LUNAK
• ABOERYZAL AHMED KOESYAIRY / 5212100071
• IMAM AFANDI AHMAD / 5212100703
Review & summarize the software requirement
specification (SRS) documentation standards.


Apa itu Software requierement specification (SRS)?


Dalam mengembangkan suatu perangkat lunak, suatu developer harus melewati suatu
tahap yang disebut dengan tahap rekayasa kebutuhan perangkat lunak. Dengan adanya
tahapan ini diharapkan seorang atau tim developer dapat mengembangkan perangkat
lunak yang sesuai dengan kebutuhan dan keinginan penggunanya. Tahapan ini
merupakan tahapan yang krusial bagi para pengembang perangkat lunak karena
kegagalan terbesar dalam pengembangan perangkat lunak dikarenakan gagalnya
pengembang memahami kebutuhan pelanggan atau pengguna perangkat lunak tersebut.
Dalam proses rekayasa kebutuhan perangkat lunak ini seorang atau tim developer
melakukan banyak kegiatan seperti analisa kebutuhan pengguna, melakukan studi
kelayakan hingga membuat dokumen hasil dari rekayasa kebutuhan perangkat lunak
tersebut.


Pembuatan dokumen spesifikasi perangkat lunak dari rekayasa kebutuhan perangkat
lunak biasa disebut Software Requirement Specifications (SRS). Software Requirement
Specifications (SRS) adalah dokumen yang berisi tentang berbagai kebutuhan yang harus
ada dan dipenuhi oleh perangkat lunak yang akan dikembangkan oleh seorang atau tim
pengembang sesuai dengan kebutuhan dari calon pengguna perangkat lunak itu sendiri.
Dokumen spesifikasi kebutuhan perangkat lunak ini dibuat dengan cara menganalisa dan
menggali informasi dari penggunanya.


Untuk membuat dokumen spesfikasi perangkat lunak ini seorang atau tim pengembang
perangkat lunak harus mengikuti standar-standar yang ada. salah satu standar spesifikasi
kebutuhan perangkat lunak yang sangat baik digunakan adalah standar IEEE.


Bagaimana Software requirement specification berdasarkan IEEE?


SRS sendiri berhubungan dengan kontrak, pengguna, pemasok/sponsor, dan customer.
Untuk mengembangkan SRS itu sendiri ada hal-hal yang harus diperhatikan. hal-hal
tersebut antara lain :


Sifat SRS (Nature SRS)


SRS dapat dilakukan oleh beberapa kastemer, sponsor, ataupun pengguna. Namun tidak
dapat dilakukan dengan banyak pengembang dalam suatu pengembangan perangkat
lunak.


Lingkungan SRS


SRS harus benar dalam menspesifikasikan kebutuhan. Selain itu SRS sebaiknya tidak
menjelaskan setiap pelaksanaan pengembangan, dan SRS tidak harus memaksakan
suatu hal dalam perangkat lunak yang dapat menyebabkan kendala.


Karakteristik


Dokumen spesifikasi kebutuhan perangkat lunak yang baik menurut IEEE memiliki
karakteristik-karakteristik seperti berikut ini :


1. Correct (benar)
2. Unambiguous (tidak ambigu, tapi jelas)
3. Complete (lengkap)
4. Consistent (konsisten)
5. Ranked for importance and/or stability (prioritas penting dan atau stabilitas)
6. Verifiable (dapat diverifikasi)
7. Modifiable (bisa dimodifikasi)
8. Traceable (bisa dilacak)


Penyusunan SRS secara bersama-sama


Penyusunan SRS dapat disusun atau dibuat bersama-sama dengan kastemer,pengguna,
maupun pemasok/sponsor. Hal ini jika dilakukan dapat mempermudah pengembang
dalam penyusunan SRS.


Evolusi SRS


Hal ini dilakukan untuk memperbaiki dan memvalidkan SRS yang sedang dibuat.


Prototyping


Dengan membuat prototipe, pengembang dapat mempermudah pengguna dalam
mengevaluasi maupun memvalidasi perangkat lunak yang sedang dikembangkan
daripada hanya melihat dokumen SRS yagn berupa kata-kata saja.


Mencantumkan desain sistem di SRS


Dengan mencantumkan desain, pengguna akan lebih mengerti tentang komponen-
komponen yang ada di perangkat lunak yang sedang dikembangkan. Penyusun SRS
harus jelas dalam membedakan kendala desain perangkat lunak yang sedang
dikembangkannya.


Pencantuman persyaratan proyek di SRS


Persyaratan-persyaratan dalam proyek dipisahkan dari SRS. Persyaratan proyek
merupakan pemahaman antara pelanggan dan pemasok tentang kontrak dan hal-hal
yang berkaitan dengan produksi perangkat lunak seperti biaya, metode pengembangan,
Jaminan Kualitas, prosedur validasi dan kriteria verifikasi dll.




Contoh template dokumen SRS standard
1. Introduction
1.1 Purpose
<Mengidentifikasi software requirement dari produk yang ditentukan dalam dokumen ini,
termasuk revisi atau nomor rilis. Menggambarkan ruang lingkup produk yang tercakup
dalam SRS ini, terutama jika SRS ini hanya menjelaskan bagian dari sistem atau
subsistem tunggal>
1.2 Document Conventions
<Jelaskan standar atau konvensi tipografi yang diikuti saat menulis SRS ini, seperti font
atau highlighting yang memiliki makna khusus. Sebagai contoh, apakah setiap pernyataan
kebutuhan memiliki prioritasnya sendiri.>
1.3 Intended Audience and Reading Suggestions
<Menjelaskan berbagai jenis pembaca yang dimaksudkan oleh dokumen tersebut, seperti
pengembang, manajer proyek, staf pemasaran, pengguna, penguji, dan penulis
dokumentasi. Jelaskan apa sisa yang terkandung dalam SRS ini dan bagaimana ia
diorganisir. Sarankan urutan untuk membaca dokumen, dimulai dari bagian gambaran
kemudian melanjutkan melalui bagian yang paling relevan untuk setiap jenis pembaca.>
1.4 Product Scope
<Berikan penjelasan singkat dari perangkat lunak yang ditentukan dan tujuannya,
termasuk manfaat yang relevan, sasaran, dan tujuan.>
1.5 References
<Daftar dokumen lain atau alamat Web dimana SRS ini merujuk. Berikan informasi yang
cukup sehingga pembaca bisa mengakses salinan dari setiap referensi, termasuk judul,
penulis, nomor versi, tanggal, dan sumber atau lokasi.>
2. Overall Description
2.1 Product Perspective
<Jelaskan konteks dan asal mula produk yang ditentukan dalam SRS ini. Dapat berupa
sebuah diagram sederhana yang menunjukkan komponen-komponen utama dari sistem
secara keseluruhan, interkoneksi subsistem, dan interface eksternal yang dapat
membantu.>
2.2 Product Functions
<Meringkas fungsi utama produk. Mengatur fungsi untuk membuat produk yang ada
dalam SRS ini mudah dimengerti oleh setiap pembaca SRS, >
2.3 User Classes and Characteristics
<Mengidentifikasi berbagai kelas pengguna yang diantisipasi akan menggunakan produk
ini. Kelas pengguna dapat dibedakan berdasarkan frekuensi penggunaan, subset dari
fungsi produk yang digunakan, keahlian teknis, tingkat keamanan atau hak istimewa, dan
tingkat pendidikan atau pengalaman. Jelaskan karakteristik yang bersangkutan dari
masing-masing kelas pengguna. Persyaratan tertentu mungkin hanya berhubungan untuk
kelas pengguna tertentu.>
2.4 Operating Environment
<Menggambarkan keadaan lingkungan dimana perangkat lunak akan beroperasi,
termasuk platform perangkat keras, sistem operasi dan versi.>

2.5 Design and Implementation Constraints
<Jelaskan setiap item atau masalah yang akan membatasi pilihan yang tersedia bagi para
pengembang. Ini mungkin termasuk: kebijakan perusahaan atau peraturan, keterbatasan
hardware (persyaratan waktu, persyaratan memori); interface untuk aplikasi lain, teknologi
yang spesifik, alat-alat, dan database yang akan digunakan, operasi paralel, persyaratan
bahasa, protokol komunikasi, pertimbangan keamanan; konvensi desain atau standar
pemrograman (misalnya, jika organisasi pelanggan akan bertanggung jawab untuk
menjaga perangkat lunak yang dikirimkan).>
2.6 User Documentation
<Daftar komponen dokumentasi pengguna (seperti user manual, on-line help, dan tutorial)
yang akan disampaikan bersama dengan perangkat lunak.>
2.7 Assumptions and Dependencies
<Cantumkan setiap asumsi faktor (bertentangan dari fakta yang diketahui) yang dapat
mengpengaruhi kebutuhan dalam SRS. Ini dapat mencakup komponen pihak ketiga atau
komersial yang direncanakan untuk diggunakan, isu-isu seputar perkembangan atau
lingkungan operasi, atau kendala. Proyek ini dapat terpengaruh jika asumsi ini tidak
benar, tidak dibagi, atau berubah. Juga mengidentifikasi dependensi proyek yang memiliki
faktor-faktor eksternal, seperti komponen perangkat lunak yang Anda berniat untuk
menggunakan kembali dari proyek lain, kecuali mereka sudah didokumentasikan di
tempat lain (misalnya, dalam visi dan lingkup dokumen atau rencana proyek).>
3. External Interface Requirements
3.1 User Interfaces
<Jelaskan karakteristik yang logis dari setiap antarmuka antara produk perangkat lunak
dan pengguna. seperti gambar layar sampel, setiap standar GUI atau panduan gaya
keluarga produk yang akan diikuti, layar kendala tata letak, tombol standar dan fungsi
(misalnya, help) yang akan muncul pada setiap layar, keyboard, standar tampilan pesan
error, dan sebagainya. Tentukan komponen user interface perangkat lunak yang
diperlukan. Rincian dari desain antarmuka pengguna harus didokumentasikan dalam
spesifikasi antarmuka pengguna yang terpisah.>
3.2 Hardware Interfaces
<Jelaskan karakteristik logis dan fisik dari setiap antarmuka antara produk perangkat
lunak dan komponen perangkat keras sistem. Ini mungkin termasuk jenis seperti
perangkat yang didukung, sifat data dan kontrol interaksi antara perangkat lunak dan
perangkat keras, dan protokol komunikasi yang akan digunakan.>
3.3 Software Interfaces
<Jelaskan hubungan antara produk dengan komponen lain perangkat lunak secara
khusus (nama dan versi), termasuk database, sistem operasi, peralatan, perpustakaan,
dan komponen komersial terpadu. Mengidentifikasi item data atau pesan yang masuk ke
sistem dan jelaskan tujuannya masing-masing. Jelaskan layanan yang dibutuhkan dan
sifat komunikasi yang ada. Identifikasi data yang akan dibagi di seluruh komponen
perangkat lunak.>
3.4 Communications Interfaces
<Menjelaskan persyaratan yang terkait dengan fungsi komunikasi yang diperlukan oleh
produk, termasuk e-mail, web browser, protokol komunikasi server jaringan, formulir
elektronik, dan sebagainya. Mendefinisikan format pesan yang bersangkutan. Identifikasi
standar komunikasi yang akan digunakan, seperti FTP atau HTTP. Tentukan masalah
apapun, keamanan, komunikasi atau enkripsi, kecepatan transfer data, dan mekanisme
sinkronisasi.>
4. System Features
<Pada template ini menggambarkan aturan persyaratan fungsional produk dengan fitur
sistem, layanan utama yang disediakan oleh produk. Anda dapat memilih untuk mengatur
bagian ini dengan menggunakan kasus, modus operasi, kelas pengguna, kelas objek,
hirarki fungsional, atau mengkombinasikannnya, apa pun yang mengartkani paling logis
untuk produk Anda.>
4.1 System Feature 1
<Jangan benar-benar menuliskan "Sistem Fitur 1." buatlah sesuai system feature produk
yang kita buat>
4.1.1 Description and Priority
<Berikan penjelasan singkat dari fitur tersebut dan tunjukkan apakah itu dari High,
Medium, atau prioritas rendah. dapat meliputi peringkat komponen prioritas tertentu,
seperti manfaat, denda, biaya, dan risiko (masing-masing dinilai pada skala yang relatif
rendah dari 1 sampai yang tertinggi 9).>
4.1.2 Stimulus/Response Sequences
<Daftar urutan tindakan pengguna dan respons sistem yang merangsang perilaku yang
ditetapkan untuk fitur ini. Ini akan sesuai dengan unsur-unsur dialog terkait dengan kasus
penggunaan.>
4.1.3 Functional Requirements
<Merinci persyaratan fungsional terkait dengan fitur. Ini adalah kemampuan perangkat
lunak yang harus ada agar pengguna dapat mengetahui layanan yang diberikan oleh fitur
tersebut, atau untuk mengeksekusi kasus penggunaan. Termasuk bagaimana produk
harus merespon kondisi kesalahan yang diantisipasi atau input yang tidak valid.
Persyaratan harus ringkas, lengkap, jelas, dapat diverifikasi, dan perlu. Gunakan "TBD"
sebagai tempat untuk menunjukkan bila informasi yang diperlukan belum tersedia.>
<Setiap persyaratan harus diidentifikasi secara unik dengan nomor urut atau tag yang
berarti dari beberapa jenis.>
REQ-1:
REQ-2:
4.2 System Feature 2 (and so on)
5. Other Nonfunctional Requirements
5.1 Performance Requirements
<Jika ada persyaratan kinerja untuk produk dalam berbagai keadaan, dirinci disini dan
jelaskan beserta alasannya. Tujuannya untuk membantu para pengembang memahami
maksud dan membuat pilihan desain yang cocok. Tentukan hubungan waktu untuk sistem
real time. Membuat persyaratan seperti spesifik mungkin.>
5.2 Safety Requirements
<Menentukan persyaratan yang berkaitan dengan kerugian atau kerusakan dari
penggunaan produk. Mendefinisikan pengamanan atau tindakan yang harus diambil,
serta tindakan yang harus dicegah. Mengacu pada setiap kebijakan eksternal atau
peraturan yang mempengaruhi desain produk atau penggunaan. Mendefinisikan
sertifikasi keselamatan yang harus dipenuhi.>
5.3 Security Requirements
<Menentukan persyaratan mengenai masalah keamanan atau privasi seputar
penggunaan produk atau perlindungan data yang digunakan atau diciptakan oleh produk.
Menentukan persyaratan otentikasi identitas pengguna. Mengacu pada setiap kebijakan
atau peraturan yang mengandung masalah keamanan yang mempengaruhi produk
eksternal. Mendefinisikan sertifikasi keamanan atau privasi yang harus dipenuhi.>
5.4 Software Quality Attributes
<Mentukan setiap karakteristik kualitas tambahan untuk produk yang akan penting untuk
pelanggan maupun pengembang. Beberapa yang perlu dipertimbangkan adalah:
adaptasi, ketersediaan, ketepatan, fleksibilitas, interoperabilitas, rawatan, portabilitas,
kehandalan, usabilitas, ketahanan, testability, dan kegunaan. Dalam bab ini tulislah lebih
spesifik, kuantitatif, dan dapat diverifikasi bila memungkinkan. Setidaknya, memperjelas
preferensi relatif untuk berbagai atribut, seperti kemudahan penggunaan untuk lebih
mudah belajar.>
5.5 Business Rules
<Merupakan aturan-aturan dalam operasi produk yang akan dibuat. Namun bukan
merupakan persayaratan fungsional dari produk perangkat lunak yang sedang
dikembangkan.>
6. Other Requirements
<Tentukan persyaratan lain yang tidak tercakup di tempat lain di SRS. Ini mungkin
termasuk persyaratan database, kebutuhan internasionalisasi, persyaratan hukum,
sasaran penggunaan kembali untuk proyek tersebut, dan sebagainya. Menambahkan
bagian baru yang berkaitan dengan proyek tersebut.>
Appendix A: Glossary
<Mendefinisikan semua persyaratan yang diperlukan untuk benar menafsirkan SRS,
termasuk akronim dan singkatan. Kita mungkin ingin untuk membangun sebuah glossary
terpisah yang mencakup beberapa proyek atau seluruh organisasi, dan hanya mencakup
istilah khusus untuk satu proyek di setiap SRS.>
Appendix B: Analysis Models
<Opsional, mencakup model analisis terkait, seperti diagram aliran data, diagram kelas,
diagram negara-transisi, atau diagram entity-relationship.>
Appendix C: To Be Determined List

<Kumpulkan daftar bernomor dari TBD (akan ditentukan) referensi yang tetap berada di SRS
sehingga mereka dapat dilacak hingga penutupan.>