4 Kerangka Dasar Software Requirement Specification (SRS) dan Cara Membuatnya

Terkadang penting bagi departemen-departemen yang berseberangan dalam suatu organisasi untuk bekerja sama—bahkan jika mereka berbicara dalam bahasa teknis yang berbeda. Jika Anda pernah bekerja dalam tim yang lintas fungsi, Anda pasti tahu betapa sulitnya menjaga semua orang agar memiliki pemahaman yang sama. 

Dokumen Software Requirement Specification (SRS) dapat membantu project manager, product manager, dan business analyst memecah konsep high-level menjadi item-item tindakan yang dapat diikuti oleh setiap anggota tim selama proses pengembangan. 

Apa itu Software Requirement Specification (SRS)?

Software Requirement Specification (SRS) adalah dokumen yang mencantumkan persyaratan, ekspektasi, desain, dan standar untuk proyek mendatang. Ini termasuk persyaratan bisnis high-level yang menentukan tujuan proyek, persyaratan dan kebutuhan pengguna akhir, dan fungsionalitas produk dalam istilah teknis. Sederhananya, SRS memberikan deskripsi terperinci tentang cara kerja produk perangkat lunak dan cara tim Anda membuatnya berfungsi sebagaimana mestinya.

Bayangkan Anda memiliki ide bagus untuk membuat sebuah aplikasi. Anda memiliki visi tentang apa diinginkan dan bagaimana tampilannya, tetapi Anda sadar bahwa Anda tidak bisa hanya memberikan deskripsi lisan kepada tim pengembang dan mengharapkan mereka memenuhi harapan Anda. Maka di sinilah SRS berperan.

Mengapa Menggunakan SRS?

Jika tim pengembang tidak memiliki arahan yang jelas saat membuat sebuah aplikasi, Anda mungkin akan menghabiskan lebih banyak waktu dan uang untuk membuatnya sesuai dengan apa yang Anda pikirkan. 

Menyusun dokumen SRS akan membantu Anda untuk menuangkan ide dan menetapkan persyaratan (requirements) yang jelas. Dokumen ini menjadi satu-satunya acuan yang sah untuk produk Anda, sehingga semua tim—dari pemasaran hingga pemeliharaan—berada di halaman yang sama.

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

Apa Saja yang Harus Dimasukkan dalam Dokumen SRS

Kerangka dasar dokumen SRS terdiri dari empat bagian: Introduction (Pendahuluan), requirements sistem dan fungsional, requirements antarmuka eksternal, and non-functional requirements (NFR).

1. Pendahuluan

Pendahuluan dalam dokumen SRS adalah gambaran umum proyek secara keseluruhan. Saat menulis pengantar, jelaskan tujuan produk, audiens yang dituju, dan bagaimana audiens akan menggunakan produk tersebut. Pastikan untuk menyertakan hal-hal berikut dalam pengantar Anda:

• Ruang lingkup produk: Ruang lingkup ini harus berkaitan dengan tujuan bisnis secara keseluruhan dari produk, yang sangat penting jika banyak tim akan memiliki akses ke dokumen tersebut. Daftarkan manfaat, tujuan, dan sasaran produk yang dimaksud.
• Nilai produk: Mengapa produk Anda penting? Bagaimana produk ini akan membantu audiens yang dituju? Fungsi apa yang akan dilayaninya, atau masalah apa yang akan diselesaikannya? Pertimbangkan bagaimana audiens Anda akan menemukan nilai dalam produk tersebut
• Sasaran audiens: Deskripsikan audiens ideal Anda. Mereka akan menentukan tampilan dan nuansa produk Anda serta bagaimana Anda memasarkan produk tersebut
• Penggunaan yang dituju: Bayangkan bagaimana audiens Anda akan menggunakan produk Anda. Daftarkan fungsi yang Anda sediakan dan semua kemungkinan cara audiens Anda dapat menggunakan produk Anda sesuai dengan peran mereka. Merupakan praktik yang baik untuk menyertakan use case untuk menggambarkan visi Anda.
• Definisi dan akronim: Setiap industri atau bisnis memiliki akronim atau istilah yang unik. Jelaskan definisi istilah-istilah yang Anda gunakan dalam SRS Anda untuk memastikan semua pihak memahami apa yang Anda maksud
• Daftar isi: Dokumen SRS yang menyeluruh kemungkinan akan sangat panjang. Sertakan daftar isi untuk membantu semua peserta menemukan apa yang mereka cari. 

Pastikan pendahuluan Anda jelas dan ringkas. Ingat bahwa pendahuluan ini akan menjadi panduan untuk seluruh kerangka SRS, dan Anda ingin agar semua orang yang menggunakan dokumen tersebut menafsirkannya dengan cara yang sama.

2. Requirements Sistem dan Fungsional

Setelah Anda menulis pendahuluan, saatnya untuk bagian yang lebih spesifik. Persyaratan fungsional menguraikan fitur dan fungsi sistem yang memungkinkan sistem Anda berfungsi sebagaimana mestinya. Gunakan gambaran umum Anda sebagai referensi untuk memeriksa apakah persyaratan Anda memenuhi kebutuhan dasar pengguna saat Anda mengisi detailnya. Ada ribuan persyaratan fungsional yang dapat disertakan tergantung pada produk Anda. Beberapa yang paling umum adalah:

• Perilaku if/then
• Logika penanganan data
• Alur kerja sistem
• Penanganan transaksi
• Fungsi administratif
• Kebutuhan regulasi dan kepatuhan
• Persyaratan kinerja
• Detail operasi yang dilakukan untuk setiap layar

Jika ini terasa banyak, coba ambil satu persyaratan pada satu waktu. Semakin banyak detail yang Anda sertakan dalam dokumen SRS Anda, semakin sedikit pemecahan masalah yang perlu Anda lakukan di kemudian hari.

3. Requirements Antarmuka Eksternal

Requirements antarmuka eksternal antarmuka eksternal adalah jenis persyaratan fungsional yang memastikan sistem dapat berkomunikasi dengan benar dengan komponen eksternal, seperti:

• Antarmuka pengguna: Kunci 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, libraries, dan sistem operasi. 
• Antarmuka komunikasi: Persyaratan untuk fungsi komunikasi yang akan digunakan oleh produk Anda, seperti email atau formulir yang disematkan. 

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

4. Non-Functional Requirements (NFR)

Bagian terakhir dari SRS Anda akan menjelaskan persyaratan non-fungsional. Sementara persyaratan fungsional memberitahu sistem apa yang harus dilakukan, persyaratan non-fungsional (NFR) menentukan bagaimana sistem Anda akan mengimplementasikan fitur-fitur tersebut. Misalnya, persyaratan fungsional mungkin mengarahkan sistem Anda untuk mencetak slip pengepakan ketika pelanggan memesan produk Anda. NFR akan memastikan bahwa slip pengepakan dicetak pada kertas putih berukuran 4″x6″, ukuran standar untuk slip pengepakan. 

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

Jenis NFR yang paling umum disebut ‘-itys’. Jenis-jenis tersebut adalah:

• Security: Apa yang dibutuhkan untuk memastikan informasi sensitif dari pengguna yang dikumpulkan perangkat lunak Anda dapat terlindungi dengan baik. 
• Capacity: Kebutuhan penyimpanan untuk saat ini dan masa depan, termasuk rencana bagaimana sistem Anda akan berkembang untuk memenuhi volume permintaan yang meningkat.
• Compatibility: Persyaratan perangkat keras minimum untuk perangkat lunak Anda, seperti dukungan untuk sistem operasi dan versinya. 
• Reliability and availability: Seberapa sering Anda mengharapkan pengguna menggunakan perangkat lunak Anda.
• Scalability: Beban kerja tertinggi di mana sistem Anda masih akan bekerja seperti yang diharapkan. 
• Maintainability: Bagaimana aplikasi Anda harus bisa menggunakan integrasi berkelanjutan sehingga Anda dapat dengan cepat mengimplementasikan fitur dan memperbaiki bug. 
• Usability: Seberapa mudah produk tersebut digunakan. 

Jenis persyaratan non-fungsional lainnya yang umum termasuk persyaratan kinerja, regulasi, dan lingkungan. 

Best Practice untuk Membuat Dokumen SRS

Tujuan dari SRS adalah memastikan setiap tim di setiap departemen bisa bekerja menuju tujuan yang jelas. Dengan demikian, ada beberapa best practice yang perlu diikuti untuk memastikan SRS Anda berfungsi sebagaimana mestinya.

1. Perkaya SRS dengan Visualisasi

Menyertakan visual seperti diagram, skema, dan model akan membantu anggota tim memahami proses dengan lebih baik. Visual ini sangat berguna saat menggambarkan fungsi utama dan operabilitas perangkat lunak Anda. 

Salah satu teknik yang bisa dicoba saat brainstorming proyek Anda adalah mind mapping, yang mengorganisasikan ide, fitur, dan skenario serta menggambarkan hubungan di antara mereka. Buatlah mind map untuk menyusun pikiran-pikiran acak saat Anda mulai menyusun ide-ide Anda. Visual ini tidak perlu terlalu detail—itulah fungsi SRS Anda. Sebaliknya, fokuslah pada fungsi utama perangkat lunak Anda dan bagaimana fungsi-fungsi tersebut saling terkait.

2. Buatlah Secara Jelas dan Ringkas

Usahakan agar tidak ada ruang bagi anggota tim untuk berkreasi dan mengisi kekosongan. Sertakan detail sebanyak mungkin saat menggambarkan persyaratan perangkat lunak Anda, dan hindari:

• Menggunakan Menggunakan kata-kata yang tidak jelas seperti “umumnya” atau “kira-kira”
• Menggabungkan istilah dengan “/”, yang bisa diartikan sebagai “dan” atau “atau”

• Menggunakan nilai batas yang rumit
• Menggunakan negatif ganda dan tiga kali lipat

Tinjauan rekan yang formal adalah cara yang baik untuk mengidentifikasi ambiguitas dalam dokumen SRS Anda. Rencanakan untuk meninjau dokumen tersebut bersama setiap peserta untuk membandingkan pemahaman mereka tentang persyaratan dan membuat perubahan yang diperlukan.

3. Kenali End-user

Tambahkan penelitian lapangan dan wawancara pengguna Anda ke dalam SRS untuk membangun pemahaman yang jelas tentang persyaratan, harapan, dan kebutuhan pengguna Anda. Ini akan membantu Anda memvisualisasikan operasi yang akan dilakukan oleh pengguna Anda. Pertimbangkan setiap kemungkinan skenario dan situasi yang dapat terjadi untuk disertakan dalam SRS Anda. Ingat, tim pengembang Anda akan mengimplementasikan apa yang Anda sertakan dalam dokumen—tidak lebih, tidak kurang. 

4. Sertakan Margin untuk Fleksibilitas

SRS Anda adalah dokumen yang terus berkembang, artinya Anda akan menambahkan fitur dan modifikasi baru dengan setiap iterasi. Pertimbangkan hal tersebut dengan menjaga persyaratan tetap fleksibel jika hasilnya tidak sesuai dengan harapan Anda. Menyimpan catatan setiap perubahan yang dilakukan pada dokumen untuk menghindari kesalahpahaman merupakan praktik yang baik. Tim harus dapat melacak setiap persyaratan ke sumber aslinya dan melihat siapa yang melakukan perubahan, kapan, dan mengapa.

Anda ingin membangun aplikasi dengan metode pengembangan dan manajemen proyek yang andal? Segera hubungi NEXT-IT dengan cara klik tautan ini untuk berkonsultasi lebih lanjut secara GRATIS. Sampai berjumpa!