Software Requirement Specification (SRS)
Mematuhi setiap detail dan persyaratan yang ditentukan dalam proyek perangkat lunak yang dilakukan, adalah tujuan yang harus dicapai pengembang untuk memenuhi harapan pelanggan mereka dan membuat proyek berhasil. Software Requirements Specification (SRS) dianggap sebagai salah satu fase paling kritis dari pengembangan perangkat lunak/produk.
Software Requirements Specification (SRS) adalah deskripsi rinci tentang sistem perangkat lunak yang akan dikembangkan dengan persyaratan fungsional dan non-fungsionalnya, termasuk bagaimana pengguna akan berinteraksi dengan sistem perangkat lunak. Untuk mengembangkan sistem perangkat lunak, kita harus memiliki pemahaman yang jelas tentang sistem yang akan dibuat tersebut. Untuk mencapai ini, kita perlu berkomunikasi terus menerus dengan pelanggan untuk mengumpulkan semua persyaratan. SRS dianggap sebagai salah satu tahap awal dari Software Development Lifecycle (SDLC). SRS dapat dianggap seperti peta yang mengarahkan Anda ke produk Anda.
SRS yang baik mendefinisikan bagaimana Sistem Perangkat Lunak akan berinteraksi dengan semua modul internal, perangkat keras, program lain dandengan pengguna manusia. Sangat disarankan untuk meninjau dokumen Software Requirements Specification sebelum mulai menulis test cases dan membuat rencana apa pun untuk pengujian. Untuk menulis SRS yang jelas, ringkas, dan mudah diikuti, Anda harus memahami proyek Anda, tetapi Anda juga harus memahami pedoman SRS.
Mengapa kita perlu menulis SRS?
1. Anda bisa mendapatkan perkiraan biaya, risiko, dan waktu yang akurat.
2. Klien akan dapat membentuk visi proyek mereka dengan lebih jelas.
3. Pelanggan dan pengembang akan memiliki ide yang sama tentang produk.
4. Membantu mengidentifikasi fungsi yang optimal.
5. Dasar untuk pembentukan dokumentasi teknis lainnya.
6. Proses pengembangan akan optimal dan waktu akan minimal.
7. Tidak akan ada duplikasi tugas.
8. Memungkinkan Anda menyusun masalah dan menyelesaikannya dengan lebih mudah dan lebih cepat.
Karakteristik SRS
Ada hal-hal tertentu yang harus diupayakan pengembang untuk dicapai dalam dokumen SRS mereka, yaitu :
· Kualitas yang baik
· Karakteristik yang memenuhi tujuan
· Persyaratan yang dapat diidentifikasi
1. Kualitas yang Baik
Kualitas SRS yang baik adalah kualitas yang bertujuan membantu pengembang memahami cakupan proyek.
Kualitas SRS yang baik dapat diukur dari beberapa kriteria berikut.
· Memecah Masalah
SRS yang baik akan memecah masalah menjadi beberapa bagian yang dapat diselesaikan dengan lebih mudah. Ini juga membantu meningkatkan pemahaman tentang masalah dan membuatnya lebih mudah untuk ditangani.
· Menawarkan Masukan Desain.
SRS Anda harus berisi detail desain untuk membantu implementasi dan penerapan.
· Persyaratan diurutkan berdasarkan kepentingan.
Memberi peringkat persyaratan berdasarkan kepentingan dengan jelas memberi tahu pengembang dan pemangku kepentingan di mana letak prioritasnya. Jika proyek datang pada tenggat waktu tertentu, seperti akhir sprint, memiliki sistem peringkat membantu pengembang mengubah prioritas dengan mudah.
· Lengkap, Ringkas, dan Dapat Dimodifikasi.
Produk jadi harus menawarkan gambaran total proyek pengembangan sesingkat mungkin untuk meningkatkan pemahaman. Itu harus mudah dimodifikasi untuk memperhitungkan umpan balik dan perubahan.
2. Karakteristik yang Memenuhi Tujuan
Setiap proyek harus memiliki serangkaian tujuan yang telah ditetapkan sebelumnya. Karakteristik ini digunakan untuk memastikan tujuan terpenuhi dan proyek tetap berada di jalur yang benar.
Karakteristik yang memenuhi tujuan dapat diukur dari beberapa kriteria berikut.
· Lingkup Pekerjaan Deskriptif
Memiliki ruang lingkup pekerjaan yang jelas adalah salah satu tujuan terpenting. Lingkup memandu pengembang menyelesaiakan proyek.
· Mendefinisikan Fitur untuk End User
Customer requirements mencakup fitur tertentu untuk end user yang harus ditentukan dalam SRS.
· Memberikan Peluang untuk Peninjauan Kembali dengan Stakeholder
Salah satu tujuan dari dokumen ini adalah untuk transparansi antara manajer proyek dan stakeholder.
· Perkiraan Biaya
SRS harus dapat memperkirakan biaya pengembangan dan penerapan, serta biaya operasional.
3. Persyaratan yang Dapat Diidentifikasi
Pengembang harus memperhatikan karakteristik ini dan melakukan perubahan seperlunya.
Pedoman SRS
Konten dalam SRS dapat bervariasi dari satu proyek ke proyek lainnya. Meski begitu, setiap proyek, betapapun berbedanya, harus mengikuti seperangkat pedoman yang ditentukan. Pedoman tersebut antara lain yaitu :
1. Persyaratan Fungsional
Persyaratan fungsional dokumen yang berfungsi untuk menyediakan kerangka kerja dalam implementasi harus jelas.
2. Model Analisis
Model analisis memungkinkan Anda menelusuri spesifikasi persyaratan tertentu.
3. Model Kognitif
Ini adalah model pengembangan yang membantu pengembang memahami bagaimana suatu sistem akan dirasakan oleh orang lain, biasanya end user.
4. Isi & Struktur Spesifikasi
Ini mencakup semua data di setiap entitas
5. Spesifikasi
Spesifikasi itu sendiri harus cukup kuat untuk menceritakan kisah proyek pengembangan, dan cukup fleksibel untuk memungkinkan perubahan dalam ruang lingkup
Struktur SRS
Berikut adalah panduan IEEE untuk SRS. Ini adalah kumpulan standar yang paling banyak digunakan saat membuat SRS dan dapat disesuaikan dengan kebutuhan masing-masing instansi.
- Tujuan/Pengantar
Bagian tujuan harus merangkum seluruh dokumen SRS. Ini mirip dengan ringkasan dokumen bisnis. Komponen bagian ini mencakup Definisi, System overview, Referensi.
2. Deskripsi keseluruhan
Deskripsi keseluruhan memberikan gambaran tentang persyaratan dan subbagian lainnya. Persyaratan akan dijelaskan secara lebih rinci di bagian persyaratan khusus. Fungsi dari deskripsi keseluruhan adalah untuk mempertimbangkan faktor penentu yang mempengaruhi persyaratan.
Komponen bagian ini mencakup Perspektif produk (Antarmuka Sistem, Antarmuka pengguna, Antarmuka Perangkat Keras, Antarmuka Perangkat Lunak, Antarmuka Komunikasi, Kendala Memori), Kendala desain (Operasi, Site Adaptation Requirements), Fungsi produk, Karakteristik Pengguna, Kendala, asumsi dan dependensi
3. Persyaratan khusus
Tujuan dari bagian persyaratan khusus adalah untuk merinci semua persyaratan yang diperlukan untuk pengembangan. Bagian ini memberikan kerangka kerja bagi desainer untuk membuat produk sesuai dengan persyaratan.
Komponen bagian ini mencakup Persyaratan antarmuka eksternal, Persyaratan fungsional, Karakteristik pengguna, Persyaratan kinerja, Logical database requirement, Atribut Sistem Perangkat Lunak (Reliability, Availability, Security, Maintainability, Portability), Persyaratan Khusus.
Membuat SRS
Tujuan dari dokumen ini adalah untuk membantu kelancaran pelaksanaan pengembangan program. SRS Anda harus fleksibel, dapat dimodifikasi, dan dapat diskalakan sehingga dapat berubah sesuai dengan tuntutan proyek.
Tips menulis SRS, yaitu :
1. Jelaskan semuanya dengan sangat singkat dan jelas sebanyak mungkin.
2. Jangan memasukkan hal-hal yang mungkin tidak perlu didokumentasikan.
3. Seseorang yang membaca SRS harus memahami dengan tepat apa yang tertulis
4. Gunakan diagram DFD (Data Flow Diagram). Spesifikasi tidak bisa lengkap jika kita tidak tahu apa yang ada di pintu masuk ke perangkat lunak yang dijelaskan, dan apa yang ada di output. Semuanya harus disertakan.
Menguji SRS
1. Kebenaran Software Requirements Specification harus diperiksa karena seluruh fase pengujian bergantung pada SRS.
2. Ambiguitas harus dihindari. Terkadang di SRS, beberapa kata memiliki lebih dari satu arti dan ini mungkin membingungkan penguji sehingga sulit untuk mendapatkan referensi yang tepat. Disarankan untuk memeriksa kata-kata yang ambigu dan memperjelas artinya untuk pemahaman yang lebih baik.
3. Persyaratan harus lengkap. Ketika tester menulis test case, apa yang sebenarnya dibutuhkan dari aplikasi, adalah hal pertama yang harus jelas. Jika aplikasi perlu mengirim data spesifik dengan ukuran tertentu maka harus disebutkan dengan jelas di SRS bahwa berapa banyak data dan berapa batas ukuran yang harus dikirim.
4. Persyaratan yang konsisten. SRS harus konsisten dengan dirinya sendiri dan konsisten dengan dokumen acuannya.
5. Verifikasi hasil yang diharapkan. Software Requirements Specification tidak boleh memiliki pernyataan seperti “Bekerja seperti yang diharapkan”, harus dinyatakan dengan jelas bahwa apa yang diharapkan karena penguji yang berbeda akan memiliki aspek pemikiran yang berbeda dan dapat menarik hasil yang berbeda dari pernyataan ini.
6. Beberapa aplikasi memerlukan kondisi khusus untuk pengujian dan juga lingkungan tertentu untuk hasil yang akurat. SRS harus memiliki dokumentasi yang jelas tentang jenis lingkungan apa yang diperlukan untuk disiapkan.
7. Prakondisi didefinisikan dengan jelas. Jika tidak terpenuhi dengan baik maka hasil yang sebenarnya akan selalu berbeda dengan hasil yang diharapkan. Pastikan bahwa dalam SRS, semua prasyarat disebutkan dengan jelas.
8. Requirements ID memudahkan untuk mengkategorikan modul sehingga hanya dengan melihatnya, penguji akan tahu modul mana yang harus dirujuk. SRS harus memilikinya untuk mendefinisikan modul tertentu.
