RINGKASAN TENTANG SOFTWARE REQUIREMENT SPESIFICATION

NIM : C1A 110021 2 Daftar Isi 1. Definisi …………………………………………………………………………………………………………… 4 2. Tujuan ……………………………………………………………………………………………………………. 4 3. Jenis informasi yang harus SRS sertakan/masukan………………………………………… 5 4. Mulai dengan SRS template …………………………………………………………………………… 5 5. Mengidentifikasi dan menghubungkan kebutuhan dengan suber………………… 8 6. Menetapkan aturan bisnis untuk kontingensi dan tanggung jawab………………. 9 7. Membentuk matriks kebutuhan ketertelusuran……………………………………………. 9 8. Yang harus diketahui tentang menulis SRS…………………………………………………….. 10 9. Kesimpulan…………………………………………………………………………………………………….. 11 3 Daftar Tabel Tabel 1. Contoh kerangka dasar SRS……………………………………………………………………………. 6 Tabel 2. Contoh garis besar SRS yang lebih rinci………………………………………………………….. 7 Tabel 3. Contoh identifikasi kebutuhan dan menghubungkan ke sumber………………….. 9 Tabel 4. 10 bahasa karakteristik kualitas SRS………………………………………………………………. 10 4 SOFTWARE REQUIREMENT SPESIFICATION 1. 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. 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. SRS juga berfungsi sebagai cetak biru untuk menyelesaikan sebuah proyek dengan pertumbuhan biaya sesedikit mungkin. SRS juga sering disebut "parent" dokumen karena semua management dokumen berikutnya seperti spesifikasi deasin, laporan kerja, spesifikasi arsitektur perangkat lunak, pengujian dan validasi rencana dan rencana dokumentasi terkait dengan itu. Sangat penting untuk dicatat SRS berisi persyaratan fungsional dan nonfungsional saja, tidak menawarkan saran desain, solusi yang memungkinkan untuk tekhnologi atau bisnis, atau informasi lain selain dari apa yang tim pengembang pahami yang menjadi kebutuhan sistem pelanggan. 2. Tujuan Sebuah rancangan yang baik, penulisan SRS yang baik harus dapat menyelesaikan empat tujuan utama :  Memberikan umpan balik kepada pelanggan. SRS adalah jaminan pelanggan bahwa organisasi pengembang memahai isu -isu atau permasalahan yang harus diselesaikan dan sifat perangkat lunak yang dibutuhkan untuk mengatasi masalah tersebut. Oleh karena itu, SRS harus ditulis dalam bahasa alamin secara jelas yang mungkin juga termasuk grafik, table, diagram aliran dta, grafik keputusan dan sebagainya.  Masalah terurai menjadi beberapa bagian. Tindakan sederhana seperti menuliskan persyaratan perangkat lunak dalam format yang dirancang dengan baik mengatur informasi, menempatakan batas disekitar masalah, mengukuhkan ide, dan membantu memecah masalah menjadi bagian -bagian yang teratur.  Berfungsi sebagai masukan untuk spesifikasi desain. Seperti disebutkan sebelumnya , SRS berfungsi sebagai dokumen induk ke dokumen berikutnya seperti, spesifikasi desain perangkat lunak dan laporan kerja. Oleh karena itu, SRS harus berisi rincian yang memadai dalam persyaratan sistem fungsional sehingga solusi desain dapat dibuat. Ini berfungsi sebagai cek validasi produk. Dan SRS juga  Berfungsi sebagai dokumen induk untuk pengujian dan validasi strategi yang akan diterapkan pada persyaratan untuk verifikasi.

Tujuan dari penulisan dokumen ini adalah untuk memberikan penjelasan mengenai perangkat lunak yang akan dibangun baik berupa gambaran umum maupun penjelasan detail dan menyeluruh.

Software Requirements Specification Sistem Informasi Tour & Travel

SMARTICS Journal, 2019

Laporan ini berisi tentang hasil penelitian terkait software requirement specification informasi manajemen pada Usaha Dagang Wonorejo yang memiliki menu Sales and Marketing, Manufacturing and Production, Finance and Accounting. Pada pembuatan software requirement specification ini disusun berdasarkan ISO/IEC/IEEE 29148-2011, metode penelitiannya meliputi studi literatur dari buku atau tesis yang berkaitan dengan pembuatan dokumen software requirement, dokumen yang digunakan menjadi refrensi untuk studi literatur adalah tesis dari peneliti terdahulu, selain itu penulis juga menggunakan teori ISO/IEC/IEEE 29148-2011 sebagai dasar pembuatan dokumen software requirement specification sehingga dokumen tersebut akan memiliki standar internasional, lalu juga melakukan observasi lapangan dengan cara terjun secara langsung ke perusahaan untuk mempelajari alur bisnis yang diterapkan diperusahaan dan melakukan wawancara pada pihak yang terkait didalam perusahaan sehingga data yang didapat lebih akurat dan lebih obyektif. Dokumen software requirement specification ini juga dilengkapi dengan logical database dari menu sales and marketing, menu manufacturing and production, dan menu finance and accounting sehingga dengan pemaparan logical database yang terdapat didalam dokumen software requirement specification tersebut bisa digunakan untuk memudahkan penelitian yang selanjutnya guna melakukan analisis sehingga pengembang berikutnya akan lebih mudah untuk membuat dokumen software requirement specification yang lebih baik dari sebelumnya.

Jurnal Generic, 2013

Dunia perguruan tinggi telah memanfaatkan informasi untuk mengefisiensikan proses-proses akademik yang ada di dalamnya yang disebut dengan Sistem Informasi Akademik (SIAK). SIAK dalam kaitannya dengan proses pengembangan perangkat lunak adalah pada tahapan dalam melakukan pembangunan aplikasi SIAK tersebut dimana sebagian besar tahapan pembangunannya dan pengembangannya masih bersifat ad hoc. Jika dicermati, SIAK ini dibangun menurut kebutuhan yang dapat dilihat dari prosesnya. Dari analisis implementasi SIAK, pada beberapa institusi akan diperoleh beberapa proses yang umum. Proses yang umum ini akan merepresentasikan keumuman dalam kebutuhan spesifikasi perangkat lunak. Dalam penelitian ini akan dilakukan analisis pada beberapa aplikasi SIAK yang digunakan pada beberapa institusi pendidikan tinggi untuk dilihat keumuman prosesnya. Fokus penelitian pada registrasi akademik sebagai bagian dari SIAK. Format representasi pattern yang diimplementasikan pada hasil analisis akan mengacu pada penelitian Eko K Budiardjo dengan Software Requirement Specification (SRS) Pattern-nya. SRS pattern yang berhasil diidentifikasi pada penelitian ini adalah Registrasi KRS/IRS Mahasiswa, Perubahan KRS/IRS mahasiswa, dan persetujuan KRS/IRS mahasiswa. Penelitian ini menyimpulkan bahwa SRS pattern bisa direpresentasikan dengan memahami proses registrasi akademik yang sudah diimplementasikan untuk mendapatkan kebutuhan software yang spesifik.