Review & Summarize
Review & Summarize
REKAYASA KEBUTUHAN PERANGKAT LUNAK
REKAYASA KEBUTUHAN PERANGKAT LUNAK
•
•
ABOERYZAL
ABOERYZAL
AHMED
AHMED
KOESYAIRY
KOESYAIRY
/
/
5212100071
5212100071
•Review & summarize the
s o f t w a r e r e q u i r e m e n t
s p e c i f i c a t i o n
(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.
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 t ersebut, 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 t ersedia 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.>
<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 m embangun sebuah glossary terpisah yang mencakup beberapa proyek atau seluruh organisasi, dan hanya m encakup 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.>
