Cara menulis dokumen persyaratan perangkat lunak (dengan templat)

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

Terkadang, bagian-bagian yang berada di ujung yang berlawanan dalam satu organisasi harus bekerja sama—bahkan jika mereka menggunakan bahasa teknis yang berbeda. Jika pernah bekerja dalam 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 business memecah konsep umum 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 umum 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 menjalankannya.

Bayangkan Anda memiliki ide bagus untuk sebuah app. Anda memiliki visi tentang hal yang ingin dilakukan dan tampilan yang diinginkan, tetapi Anda tahu Anda tidak dapat memberikan deskripsi lisan kepada pengembang dan mengharapkan mereka untuk memenuhi ekspektasi Anda. Di sinilah peran SRS.

Mengapa menggunakan SRS?

Jika developer tidak memiliki arahan yang jelas saat membuat produk baru, Anda mungkin akan menghabiskan lebih banyak waktu dan uang dari yang diperkirakan untuk membuat perangkat lunak sesuai dengan yang Anda inginkan. 

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 terus berkembang, spesifikasi ini juga berfungsi sebagai titik komunikasi di antara semua pemangku kepentingan yang terlibat dalam proses pengembangan produk. Iterasi produk tidak dapat dihindari dalam proyek pengembangan perangkat lunak apa pun. Dengan mencatat perubahan dalam SRS, semua pihak dapat memverifikasinya dalam dokumen untuk mencegah kebingungan terkait persyaratan produk.

Jika tim masih menentukan konteks bisnis yang lebih luas di balik perangkat lunak, pasangkan SRS dengan templat dokumen persyaratan bisnis untuk menentukan gol, ruang lingkup, dan metrik keberhasilan sebelum mendokumentasikan detail teknis.

Hal yang harus dicantumkan dalam dokumen SRS

Kerangka dokumen dasar SRS 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 tampilan 10.000 kaki dari keseluruhan proyek. Saat menulis pendahuluan, jelaskan tujuan produk, audiens yang dituju, dan cara audiens akan menggunakannya. Dalam pendahuluan, pastikan untuk menyertakan:

• Ruang lingkup produk: Ruang lingkup harus berhubungan 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 dimaksudkan untuk produk. 

• Nilai produk: Mengapa produk Anda penting? Bagaimana produk akan membantu audiens yang dituju? Apa fungsi yang akan dilayani, atau masalah apa yang akan dipecahkan? Tanyakan kepada diri sendiri 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 dapat menggunakan produk Anda, tergantung perannya. Menyertakan kasus penggunaan untuk menggambarkan visi Anda juga merupakan praktik terbaik.

• Definisi dan akronim: Setiap industri atau business memiliki akronim atau jargon uniknya sendiri. Tetapkan definisi istilah yang Anda gunakan dalam SRS untuk memastikan semua pihak memahami apa yang ingin Anda sampaikan.

• 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 jelas dan ringkas. Ingatlah bahwa pendahuluan akan menjadi panduan Anda untuk garis besar SRS lainnya, dan Anda ingin semua orang yang menggunakan dokumen tersebut menafsirkannya dengan cara yang sama.

2. Persyaratan sistem dan persyaratan fungsional

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

Gunakan ikhtisar sebagai referensi untuk memastikan persyaratan memenuhi kebutuhan dasar pengguna saat mengisi detail. Ada ribuan persyaratan fungsional yang harus disertakan, tergantung 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 tangani satu persyaratan sekaligus. Makin banyak detail yang dapat Anda sertakan dalam dokumen SRS, makin sedikit pemecahan masalah yang perlu Anda lakukan nanti. 

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

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 perangkat lunak dan komponen 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 tersemat. 

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

4. Persyaratan non-fungsional (NRF)

Bagian terakhir SRS berisi detail persyaratan non-fungsional. Sementara persyaratan fungsional memberi tahu sistem apa yang harus dilakukan, persyaratan non-fungsional (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 berukuran 4”x6”, ukuran standar untuk slip kemasan. 

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

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

• Keamanan: Hal yang diperlukan untuk memastikan semua informasi sensitif yang dikumpulkan perangkat lunak Anda dari pengguna terlindungi. 

• Kapasitas: Kebutuhan penyimpanan produk Anda saat ini dan di masa mendatang, termasuk rencana tentang cara meningkatkan skala sistem Anda untuk 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 Anda dan berapa lama waktu kegagalan kritis dalam penggunaan normal. 

• Skalabilitas: Beban kerja tertinggi yang masih memungkinkan sistem Anda berfungsi seperti yang diharapkan. 

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

• Kemudahan penggunaan: Seberapa mudah produk digunakan. 

Jenis umum persyaratan non-fungsional lainnya termasuk 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 dari dokumen SRS yang luar biasa, memberikan Anda dan tim wawasan berharga tentang produk yang akan dikembangkan. 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 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 saat menggambarkan fungsi utama dan operabilitas 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 menggambarkan hubungan di antara mereka. Buat peta konsep untuk menyusun pikiran acak saat Anda mulai menyusun ide-ide Anda. Visual ini tidak perlu sangat 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 pengembang Anda meragukan diri sendiri saat membuat produk Anda. Cobalah untuk tidak memberi ruang kepada 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 menunjukkan ambiguitas dalam dokumen SRS Anda. Rencanakan untuk membahasnya dengan setiap peserta guna membandingkan pemahamannya tentang persyaratan dan membuat perubahan yang diperlukan. 

Kenali pengguna akhir Anda

Tambahkan riset lapangan 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 dengan perangkat lunak. Pertimbangkan setiap kemungkinan skenario dan nuansa yang dapat terjadi dan sertakan dalam SRS Anda. Ingat, pengembang akan mengimplementasikan hal yang sama persis dengan 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 itu dengan menjaga agar persyaratan tetap fleksibel jika hasilnya tidak memenuhi ekspektasi Anda. Menyimpan catatan perubahan yang dibuat pada dokumen untuk menghindari kesalahpahaman juga merupakan praktik terbaik. 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

Membuat SRS tidaklah mudah—begitu pula dengan pemecahan masalah tanpa akhir atau mengatasi argumen di antara anggota tim Anda. Upaya yang Anda lakukan untuk membuat dokumen spesifikasi persyaratan perangkat lunak yang komprehensif akan terbayar dengan produk menakjubkan yang dapat Anda dan pemangku kepentingan banggakan.