Cara menulis dokumen persyaratan perangkat lunak (beserta templatnya)

Apakah Anda ingat saat membaca novel abad ke-19 di sekolah dan berpikir, "Apakah ini bahasa yang sama?" Nah, kemungkinan besar Anda memiliki pemikiran yang sama persis di kantor saat berkolaborasi dengan pengembang AI yang berorientasi teknologi atau analis SEO yang paham web. Kalau saja ada CliffsNotes untuk rekan kerja.

Terkadang bagian yang berada di ujung yang berlawanan dari sebuah organisasi harus bekerja sama—meskipun mereka berbicara bahasa teknis yang berbeda. Jika Anda pernah bekerja di tim lintas fungsi, Anda tahu betapa sulitnya membuat semua orang memiliki pemahaman yang sama. 

Dokumen spesifikasi persyaratan perangkat lunak dapat membantu manajer proyek, manajer produk, dan analis bisnis memecah konsep tingkat tinggi menjadi item tindakan yang dapat diikuti setiap anggota tim selama proses pengembangan. 

Apa itu dokumen spesifikasi persyaratan perangkat lunak (SRS)?

Dokumen spesifikasi persyaratan perangkat lunak (SRS) mencantumkan persyaratan, ekspektasi, desain, dan standar untuk proyek mendatang. Ini termasuk persyaratan bisnis tingkat tinggi yang menentukan gol proyek, persyaratan dan kebutuhan pengguna akhir, serta fungsi produk dalam istilah teknis. Sederhananya, SRS memberikan deskripsi terperinci tentang cara kerja produk perangkat lunak dan cara tim pengembangan Anda harus menjalankannya.

Bayangkan Anda memiliki ide hebat untuk sebuah app. Anda memiliki visi tentang apa yang Anda inginkan dan seperti apa tampilannya, tetapi Anda tahu Anda tidak dapat hanya memberikan deskripsi lisan kepada pengembang dan mengharapkan mereka memenuhi ekspektasi Anda. Di sinilah SRS berperan.

Mengapa menggunakan SRS?

Jika pengembang tidak memiliki arahan yang jelas saat membuat produk baru, Anda mungkin akhirnya menghabiskan lebih banyak waktu dan uang dari yang diperkirakan untuk mencoba membuat perangkat lunak sesuai dengan yang Anda pikirkan. 

Menyusun dokumen SRS membantu Anda menuliskan ide di atas kertas dan menetapkan daftar persyaratan yang jelas. Dokumen ini menjadi satu-satunya sumber informasi produk Anda, jadi semua tim Anda—dari pemasaran hingga pemeliharaan—memiliki pemahaman yang sama. 

Karena spesifikasi persyaratan perangkat lunak adalah dokumen yang dinamis, dokumen ini juga dapat berfungsi sebagai titik komunikasi antara setiap pemangku kepentingan yang terlibat dalam proses pengembangan produk. Iterasi produk pasti terjadi selama proyek pengembangan perangkat lunak—dengan mencatat perubahan dalam SRS, semua pihak dapat memvalidasinya dalam dokumen. Ini akan mengurangi kebingungan terkait persyaratan produk. 

Hal yang harus dimasukkan dalam dokumen SRS

Garis besar dokumen SRS dasar memiliki empat bagian: pendahuluan, persyaratan sistem dan fungsional, persyaratan antarmuka eksternal, dan persyaratan non-fungsional.

1. Pendahuluan

Pendahuluan SRS persis seperti yang Anda harapkan—ini adalah gambaran menyeluruh tentang keseluruhan proyek. Saat menulis pendahuluan, jelaskan tujuan produk, audiens yang dituju, dan cara audiens akan menggunakannya. Dalam pendahuluan, pastikan untuk menyertakan:

• Ruang lingkup proyek: Ruang lingkup harus berkaitan dengan gol bisnis produk secara keseluruhan, yang sangat penting jika beberapa tim atau kontraktor akan memiliki akses ke dokumen. Buat daftar manfaat, tujuan, dan gol yang ditujukan untuk produk. 

• Nilai produk: Mengapa produk Anda penting? Bagaimana produk akan membantu audiens yang Anda targetkan? Fungsi apa yang akan dilayani, atau masalah apa yang akan dipecahkan? Tanyakan pada diri Anda bagaimana audiens akan menemukan nilai dalam produk. 

• Audiens yang dituju: Jelaskan audiens ideal Anda. Mereka akan menentukan tampilan dan nuansa produk serta cara Anda memasarkannya. 

• Penggunaan yang dimaksudkan: Bayangkan cara audiens akan menggunakan produk Anda. Buat daftar fungsi yang Anda sediakan dan semua kemungkinan cara audiens Anda dapat menggunakan produk Anda, tergantung peran mereka. Ini juga merupakan praktik terbaik untuk menyertakan kasus penggunaan guna menggambarkan visi Anda.

• Definisi dan akronim: Setiap industri atau bisnis memiliki akronim atau jargon uniknya sendiri. Tata definisi istilah yang Anda yang digunakan dalam SRS untuk memastikan semua pihak memahami apa yang Anda coba katakan.

• Daftar isi: Dokumen SRS yang menyeluruh kemungkinan akan sangat panjang. Sertakan daftar isi untuk membantu semua peserta menemukan hal yang mereka cari dengan tepat. 

Pastikan pendahuluan Anda jelas dan ringkas. Ingatlah bahwa pendahuluan Anda akan menjadi panduan Anda untuk keseluruhan garis besar SRS, dan Anda ingin dokumen ini ditafsirkan sama oleh semua orang yang menggunakannya.

2. Persyaratan sistem dan persyaratan fungsional

Setelah Anda memiliki pendahuluan, saatnya untuk lebih spesifik. Persyaratan fungsional menguraikan fitur dan fungsi sistem yang memungkinkan sistem Anda berfungsi sebagaimana mestinya. 

Gunakan ikhtisar Anda sebagai referensi untuk memeriksa bahwa persyaratan Anda memenuhi kebutuhan dasar pengguna saat Anda mengisi detail. Ada ribuan persyaratan fungsional yang harus disertakan, tergantung pada produk Anda. Beberapa yang paling umum adalah:

• Perilaku jika/maka

• Logika penanganan data

• Alur Kerja sistem

• Penanganan transaksi

• Fungsi administratif

• Kebutuhan peraturan dan kepatuhan

• Persyaratan kinerja

• Detail operasi yang dilakukan untuk setiap layar

Jika ini terasa berlebihan, coba atasi satu persatu persyaratan. Semakin banyak detail yang dapat Anda sertakan dalam dokumen SRS, semakin sedikit pemecahan masalah yang perlu Anda lakukan nantinya. 

Saat Anda masuk ke persyaratan terperinci, Anda juga perlu menjaga agar materi pendukung Anda tetap konsisten dan mudah diikuti. Templat dokumentasi teknis dapat menghemat waktu, mengurangi kesalahan, dan memastikan semua orang—dari pengembang hingga pengguna akhir—petunjuk yang jelas dan terbaru.

3. Persyaratan antarmuka eksternal

Persyaratan antarmuka eksternal adalah jenis persyaratan fungsional yang memastikan sistem akan berkomunikasi dengan baik dengan komponen eksternal, seperti:

• Antarmuka pengguna: Kunci untuk kegunaan aplikasi yang mencakup penyajian konten, navigasi aplikasi, dan bantuan pengguna, di antara komponen lainnya.

• Antarmuka perangkat keras: Karakteristik setiap antarmuka antara komponen perangkat lunak dan perangkat keras sistem, seperti jenis perangkat yang didukung dan protokol komunikasi.  

• Antarmuka perangkat lunak: Koneksi antara produk Anda dan komponen perangkat lunak lainnya, termasuk basis data, pustaka, dan sistem operasi. 

• Antarmuka komunikasi: Persyaratan untuk fungsi komunikasi yang akan digunakan produk Anda, seperti email atau formulir tertanam. 

Sistem tertanam bergantung pada persyaratan antarmuka eksternal. Anda harus menyertakan hal-hal seperti tata letak layar, fungsi tombol, dan deskripsi tentang bagaimana produk Anda bergantung pada sistem lain. 

4. Persyaratan nonfungsional (NRF)

Bagian terakhir SRS Anda menjelaskan persyaratan nonfungsional. Persyaratan fungsional memberi tahu sistem apa yang harus dilakukan, sedangkan persyaratan nonfungsional (NFR) menentukan cara sistem Anda akan menerapkan fitur-fitur ini. Misalnya, persyaratan fungsional mungkin memberi tahu sistem Anda untuk mencetak slip kemasan saat pelanggan memesan produk Anda. NFR akan memastikan bahwa slip kemasan dicetak pada kertas putih 4”x6”, ukuran standar untuk slip kemasan. 

Meskipun sistem masih dapat berfungsi jika Anda tidak memenuhi NFR, Anda mungkin menempatkan ekspektasi pengguna atau pemangku kepentingan dalam risiko. Persyaratan ini menjaga persyaratan fungsional tetap terkendali, sehingga masih mencakup atribut seperti keterjangkauan produk dan kemudahan penggunaan. 

Jenis NFR yang paling umum disebut 'Itys'. Yaitu:

• Keamanan: Yang diperlukan untuk memastikan informasi sensitif yang dikumpulkan perangkat lunak Anda dari pengguna dilindungi. 

• Kapasitas: Kebutuhan penyimpanan produk Anda saat ini dan di masa depan, termasuk rencana cara sistem Anda akan meningkatkan permintaan volume.

• Kompatibilitas: Persyaratan perangkat keras minimum untuk perangkat lunak Anda, seperti dukungan untuk sistem operasi dan versinya. 

• Keandalan dan ketersediaan: Seberapa sering Anda mengharapkan pengguna menggunakan perangkat lunak dan berapa lama waktu kegagalan kritis dalam penggunaan normal. 

• Skalabilitas: Beban kerja tertinggi yang membuat sistem Anda tetap berfungsi seperti yang diharapkan. 

• Pemeliharaan: Cara aplikasi Anda menggunakan integrasi berkelanjutan sehingga Anda dapat dengan cepat menyebarkan fitur dan perbaikan bug. 

• Kegunaan: Seberapa mudah menggunakan produk. 

Jenis persyaratan nonfungsional umum lainnya meliputi persyaratan kinerja, peraturan, dan lingkungan. 

Templat dokumen persyaratan perangkat lunak

Siap memulai usaha pengembangan perangkat lunak Anda sendiri? Templat SRS kami menguraikan keempat komponen utama dokumen SRS yang bagus, memberi Anda dan tim wawasan berharga tentang produk yang akan Anda kembangkan. Ingatlah untuk membuat persyaratan Anda tetap terperinci, jelas, dan ringkas, sehingga semua pihak memiliki visi yang sama.

Praktik terbaik untuk menulis dokumen SRS

Tujuan SRS adalah menjaga agar setiap tim di setiap bagian bekerja menuju gol yang jelas. Meskipun demikian, ada beberapa praktik terbaik yang harus diikuti untuk memastikan SRS Anda sesuai dengan tujuannya.

Perkaya SRS Anda dengan visual

Menyertakan visual seperti diagram, skema, dan model akan membantu anggota tim memahami proses dengan lebih baik. Ini sangat berguna ketika menggambarkan fungsi utama dan pengoperasian perangkat lunak Anda. 

Salah satu teknik yang dapat dicoba saat melakukan curah pendapat untuk proyek Anda adalah pemetaan pikiran, yang mengatur ide, fitur, dan skenario serta menggambar hubungan di antaranya. Buat peta konsep untuk menyusun pemikiran acak saat Anda mulai menyusun ide. Visual ini tidak perlu terlalu mendetail—itulah fungsi SRS Anda. Sebaliknya, fokuslah pada fungsi utama perangkat lunak dan kaitannya satu sama lain.

Buat tetap jelas dan ringkas

Hal terakhir yang Anda inginkan adalah developer Anda mempertanyakan diri sendiri saat membuat Produk Anda. Cobalah untuk tidak memberi ruang bagi anggota tim untuk berkreasi dan mengisi bagian yang kosong. Sertakan detail sebanyak mungkin saat menjelaskan persyaratan perangkat lunak Anda, dan hindari:

• Menggunakan kata-kata yang tidak jelas seperti umumnya atau kira-kira

• Menggabungkan istilah dengan “/”, yang dapat diartikan sebagai “dan” atau “atau”

• Menggunakan nilai batas yang rumit

• Menggunakan negatif ganda dan rangkap tiga

Tinjauan sejawat formal adalah cara yang baik untuk menentukan ambiguitas dalam dokumen SRS Anda. Rencanakan untuk membahasnya dengan setiap peserta untuk membandingkan pemahamannya tentang persyaratan dan membuat perubahan yang diperlukan. 

Kenali pengguna akhir Anda

Tambahkan riset bidang dan wawancara pengguna Anda di SRS untuk membangun pemahaman yang jelas tentang persyaratan, ekspektasi, dan kebutuhan pengguna akhir Anda. Ini akan membantu Anda memvisualisasikan operasi yang akan dilakukan pengguna akhir Anda dengan perangkat lunak. Pertimbangkan setiap kemungkinan skenario dan nuansa yang dapat terjadi dan sertakan dalam SRS Anda. Ingat, developer Anda akan mengimplementasikan persis seperti yang Anda sertakan dalam dokumen—tidak lebih, tidak kurang. 

Sertakan margin untuk fleksibilitas

SRS adalah dokumen yang dinamis, yang berarti Anda akan menambahkan fitur dan modifikasi baru di setiap iterasi. Pertimbangkan hal ini dengan menjaga agar persyaratan tetap fleksibel jika hasilnya tidak memenuhi ekspektasi Anda. Menyimpan catatan perubahan yang dibuat pada dokumen juga merupakan praktik terbaik untuk menghindari kesalahpahaman. Peserta harus dapat melacak setiap persyaratan ke bentuk aslinya dan melihat siapa yang membuat perubahan, kapan, dan mengapa. 

Gunakan dokumen persyaratan perangkat lunak untuk memperjelas visi Anda

Menulis SRS tidak mudah—namun, pemecahan masalah yang tak ada habisnya atau mengarahkan argumen di antara anggota tim Anda juga tidak mudah. Pekerjaan yang Anda lakukan dalam dokumen spesifikasi persyaratan perangkat lunak yang komprehensif akan terbayarkan dengan produk luar biasa yang dapat Anda dan pemangku kepentingan banggakan.