Panduan Menyusun Dokumen Software Requirement Specification (SRS)

Contents

Share the article

Contents

Dokumen Software Requirement Specification (SRS) merupakan sebuah penjelasan tentang cara pengembangan dari sebuah software. Secara sederhana, SRS berisikan roadmap tentang semua pihak yang terlibat dalam sebuah proyek development software. Dokumen ini menawarkan spesifikasi fungsional dan non-fungsional dari perangkat lunak dan juga mencakup use cases yang menggambarkan interaksi pengguna yang berada di dalam sistem dari awal hingga akhir.

Daftar isi

  • Pentingnya Sebuah Dokumen Software Requirement Specification (SRS)
  • Apa Saja Yang Termasuk Di Dalam Dokumen SRS?
  • Perbedaan Antara Spesifikasi Fungsional dan Non-Fungsional
  • Bagaimana Menyusun Dokumen SRS?
    • Membuat outline dokumen
    • Mendefinisikan Tujuan Development Software
    • Memberikan Gambaran Umum
    • Mendeskripsikan Spesifikasi Fungsional dan Non-Fungsional
    • Menambahkan Detail Pelengkap
    • Mendapatkan Persetujuan Dokumen SRS
  • Kesimpulan

Pentingnya Sebuah Dokumen Software Requirement Specification (SRS)

Software Requirement Specification (SRS)

Apabila Anda ingin membuat sebuah aplikasi chatting dengan tampilan dan fitur-fitur tertentu dan ingin aplikasi ini ditujukan khusus untuk perusahaan, mungkin Anda akan berpikir untuk menghilangkan beberapa fitur yang digunakan aplikasi chatting komersial yang digunakan banyak orang dan hanya berfokus pada fitur yang dibutuhkan oleh internal karyawan perusahaan. Akan tetapi, posisi Anda saat ini adalah bukan orang atau pihak yang punya concern terhadap pengembangan sebuah aplikasi. Hal ini menyebabkan Anda mulai berpikir untuk melakukan outsource atau kerja sama dengan pihak ketiga untuk mengembangkan aplikasi chatting tersebut.

Masalahnya kemudian adalah Anda perlu memastikan bahwa pihak ketiga tersebut tahu persis tentang tujuan yang ingin Anda capai dan dapat mewujudkan ide Anda membuat sebuah aplikasi chatting menjadi kenyataan. Jika Anda hanya berharap semua itu tanpa memberikan detail yang diperlukan pihak ketiga, bisa jadi biaya yang dikeluarkan dan waktu pengerjaan aplikasi menjadi terlalu mahal. Pihak ketiga yang merupakan software developer Anda bisa salah langkah dalam mengerjakan terutama dalam aktivitas pemrograman atau coding dari aplikasi Anda.

Oleh karena itu, Anda membutuhkan dokumen yang dapat menyampaikan semua gagasan Anda dan mencakup semua detail yang dibutuhkan oleh pihak ketiga. Anda harus menyampaikan ide dan gagasan Anda ke dalam bahasa yang dipahami oleh pihak ketiga.

Software Requirement Specification (SRS) adalah sebuah dokumen yang menjelaskan hal-hal yang diinginkan oleh klien dan hal-hal yang dapat disediakan oleh vendor atau perusahaan yang di outsource. Dokumen SRS bisa dianggap sebagai dokumentasi perjanjian tertulis yang mencakup detail aplikasi yang dikerjakan.

Sebagaimana dokumen-dokumen lain yang berisikan penjelasan detail mengenai hal yang akan dikerjakan, dokumen SRS juga dapat membantu pihak ketiga memperkirakan biaya dan waktu pengerjaan. Dokumen ini juga dapat membantu kepada developer dari pihak ketiga untuk menentukan teknologi yang diperlukan untuk menyelesaikan pekerjaan. Bukan hanya itu, beberapa hal ini juga dapat terbantu berkat adanya dokumen SRS:

  • UI/UX Desainer dari pihak ketiga juga mendapatkan gambaran tentang proyek secara utuh sehingga dapat menyesuaikan desain dengan use case yang tersedia dalam SRS.
  • Software Tester mendapatkan informasi untuk menyiapkan pengujian terhadap fitur-fitur yang akan dikembangkan dan disesuaikan dengan kebutuhan bisnis klien.
  • End users dapat memahami tentang gambaran umum software yang akan dikerjakan dan hasil yang ingin dicapai.
  • Bahkan investor pun bisa mendapat informasi lengkap tentang fitur-fitur yang ada di dalam sistem sehingga bisa membuat keputusan investasi yang tepat.

Apa Saja Yang Termasuk Di Dalam Dokumen SRS?

Dokumen SRS harus memiliki informasi yang cukup detail untuk pihak ketiga selaku pengembang atau developer software. Dokumen ini tidak hanya mendeskripsikan software yang akan dibuat, tetapi juga harus memuat informasi mengenai tujuan pembuatan software dan ekspektasi mengenai kinerja seharusnya dari software yang akan dihasilkan. Beberapa hal yang harus diperhatikan dalam membuat dokumen SRS adalah tersedianya informasi yang jelas dan tidak ambigu, detail, lengkap, terdapat aspek prioritas pekerjaan, serta ekspektasi output yang jelas.

Biasanya dokumen SRS mencakup hal-hal berikut ini:

  • Project overview
  • Tujuan dari software yang akan dikembangkan
  • Deskripsi software secara keseluruhan
  • Berbagai fungsionalitas yang ada di dalam sistem
  • Performa software dalam tahap produksi (production stage)
  • Kebutuhan non-fungsional dalam sistem
  • External interfaces atau hubungan interaksi software dengan perangkat yang lain
  • Batasan dari desain atau gambaran yang akan dijalankan oleh sistem

Perbedaan Antara Spesifikasi Fungsional dan Non-Fungsional

Spesifikasi fungsional adalah hal-hal teknis yang dilakukan di dalam sistem. Spesifikasi ini menjelaskan berbagai fungsi yang dilakukan sistem dalam software untuk membantu pekerjaan pengguna (user). Sistem fungsional ini juga menentukan respons terhadap masukan atau perintah dari user dan memperhitungkan segala proses yang terjadi di dalamnya. Anda dapat mempertimbangkan sistem fungsional sebagai deskripsi mendetail tentang fitur aplikasi dan kebutuhan penggunanya. Apabila sistem fungsional ini tidak ada dalam dokumen SRS, sama saja dengan meniadakan fungsi dari sistem dalam aplikasi.

Berbeda dengan fungsional, spesifikasi non-fungsional menjelaskan tentang bagaimana sistem itu dapat melakukan sistem fungsional. Spesifikasi ini tidak mempengaruhi fungsionalitas aplikasi. Jika tidak ada spesifikasi ini, sistem tetap akan melakukan perintah atau masukan yang diinginkan oleh penggunanya. Meski demikian, sistem non-fungsional tetap penting untuk dimasukkan ke dalam dokumen SRS karena menentukan karakteristik yang mempengaruhi user experience. Alih-alih berfokus pada kebutuhan penggunanya, sistem non-fungsional berfokus pada ekspektasi pengguna untuk meningkatkan kenyamanan saat menggunakan aplikasi. Oleh karena itu, sistem ini biasanya mencakup berbagai hal terkait performance software: aksesibilitas, sekuritas aplikasi, keandalan (reliability), response time, testability, privacy, tolerance, documentation, compliance, dan lain sebagainya.

Sebagai contoh sederhana,

Teknis kebutuhan fungsional : Sistem dapat mengirim email ketika kondisi tertentu dipenuhi seperti user sudah subscribe, sign up, mengisi form tertentu

Teknis kebutuhan non-fungsional: Email harus dapat dikirim dengan latency yang tidak lebih besar dari 12 jam

Bagaimana Menyusun Dokumen SRS?

Cara terbaik untuk menyusun dokumen SRS adalah memulainya dengan membuat kerangka dan informasi umum tentang software yang akan Anda kembangkan dan menambahkan detail untuk menyempurnakan draf dokumennya. Berikut adalah enam langkah yang bisa dilakukan untuk menyusun dokumen SRS Anda:

1. Membuat sebuah outline dokumen

Langkah paling awal dalam membuat dokumen SRS adalah dengan menyusun kerangka atau outline dokumen. Anda dapat menyusunnya dengan kreasi Anda sendiri atau menggunakan template dari dokumen SRS sebagai pedoman awal. Berikut ini contoh mendasar dari sebuah kerangka dalam dokumen SRS:

  1. Pengantar
  2. Latar Belakang Proyek
  3. Tujuan Pengembangan
  4. Audiens
  5. Cakupan Pengembangan
  6. Definisi Berbagai Fungsi
  7. Deskripsi Keseluruhan
  8. Kebutuhan Pengguna
  9. Asumsi dan Dependensi
  10. Fitur dan Kebutuhan Sistem
    • Sistem Fungsional
    • Sistem External Interface
    • Fitur dalam Sistem
    • Sistem Non-Fungsional

2. Mendefinisikan Tujuan Anda

Setelah Anda menyusun outline, Anda harus menyempurnakannya dengan menentukan tujuan software yang akan Anda buat dalam awalan dokumen SRS. Bagian ini merupakan penjelasan mengenai audiens yang dituju dan cara mereka menggunakan software yang akan dibuat.

3. Memberikan Gambaran Umum

Bagian berikutnya setelah Anda menentukan tujuan produk yang akan Anda hasilkan adalah merangkum cara kerjanya. Bagian ini merupakan penjelasan mengenai deskripsi yang cukup general tentang fitur di dalam software dan cara fitur-fitur tersebut berjalan sesuai dengan kebutuhan penggunanya. Anda juga perlu menjelaskan tentang asumsi yang Anda buat tentang fungsi dari software dan apapun yang bergantung padanya dalam ekosistem teknologi saat ini.

4. Mendeskripsikan Spesifikasi Fungsional dan Non-Fungsional

Sekarang Anda telah sampai pada bagian yang lebih spesifik yakni mendeskripsikan sistem fungsional dan non-fungsional. Penyusunan tiga hal sebelum masuk ke dalam bagian ini membuat Anda memiliki referensi untuk memastikan bahwa segala hal yang Anda lakukan telah memenuhi kebutuhan dasar dari pengguna software Anda. Hal tersebut juga memudahkan Anda dalam mengisi hal yang lebih detail kedepannya, seperti bagian spesifikasi fungsional dan non-fungsional ini.

Bagian ini merupakan deskripsi detail tentang kebutuhan sistem software Anda. Hal ini bisa dikatakan sebagai komponen paling penting dalam dokumen SRS Anda. Jelaskan kebutuhan sistem fungsional dengan cukup detail sehingga developer software Anda dapat mulai bekerja seperti yang Anda inginkan dan juga jangan lupakan sistem non-fungsional seperti performance software dan sekuritasnya.

Dalam bagian ini juga Anda dapat menambahkan use cases untuk menjelaskan tentang cara pengguna berinteraksi dengan sistem Anda. Di sinilah Anda dapat mendetailkan tujuan proyek dan mengukur indikator kemajuan proyek selama proses pengembangan software Anda berlangsung.

5. Menambahkan Detail Pelengkap

Terakhir dalam penyusunan draft dokumen SRS, Anda perlu menambahkan detail pelengkap sehingga pihak ketiga selaku pengembang perangkat lunak Anda dapat memulai dan menyelesaikan pekerjaan mereka dalam bentuk lampiran, daftar istilah, dan referensi yang juga Anda ketahui.

6. Mengajukan Persetujuan Terhadap Dokumen

Ketika Anda sudah menambahkan berbagai hal detail yang dibutuhkan, kini saatnya meminta persetujuan dari pihak-pihak yang dianggap berwenang (seperti atasan Anda atau jajaran manajerial) terhadap draf dokumen SRS yang telah Anda buat. Kadang dibutuhkan presentasi kepada orang-orang yang terlibat dalam proses development software nantinya untuk menjelaskan draf dokumen SRS ini. Tidak menutup kemungkinan akan ada permintaan perubahan atau revisi sehingga Anda harus memperbarui draf dokumen SRS Anda. Tetapi Anda jangan berkecil hati. Ini artinya pihak-pihak yang terlibat, baik dari pengembang software Anda dan para pemangku kepentingan di perusahaan Anda, membuat dokumen tersebut lebih tepat sehingga proyek development software yang direncanakan tidak akan keluar jalur.

Kesimpulan

Dokumen Software Requirement Specification (SRS) adalah bagian penting untuk mengerjakan proyek development software. Dokumen ini semacam roadmap yang memberikan arahan kepada semua pihak yang terlibat dalam proyek sehingga produk yang dihasilkan memenuhi kebutuhan penggunanya. Jika Anda tidak memiliki dokumen SRS yang lengkap sebelum memulai proyek, sulit untuk mengetahui waktu selesainya proyek dan bisa jadi terjadi pengalihan dengan membuat fitur yang tidak dibutuhkan selama proses pengembangan software Anda. Dokumen SRS memberikan Anda perkiraan proyek secara akurat dan menetapkan tugas dari setiap pihak yang terlibat secara efisien.

Demikian penjelasan mengenai penyusunan dokumen SRS untuk pengembangan software Anda. Badr Interactive sebagai salah satu Software House yang berpengalaman di bidang software development juga melayani kebutuhan Anda apabila ingin berkonsultasi mengenai penyusunan dokumen SRS atau jika ingin melihat contoh dokumen SRS. Kami juga siap berkolaborasi untuk mewujudkan software yang telah Anda rencanakan dalam dokumen SRS yang Anda buat demi meningkatkan layanan dan produk bisnis yang sedang Anda jalani.

Share the article

Grow Your Knowledge

About Software Development with Our Free Guidebook

Grow Your Knowledge

About Software Development with Our Guidebook

You dream it.

We build it!

We provide several bonuses FOR FREE to help you in making decisions to develop your own system/application.

  • Risk Free Development Trial 
  • Zero Requirement and Consultation Cost 
  • Free Website/Mobile Audit Performance

Our Services

Software Development • Quality Assurance • Big Data Solution • Infrastructure • IT Training

You might also like

UX Testing

Mengenal Manfaat & Metode Usability Testing UI/UX dalam Pengembangan Website & Aplikasi

UX Design

5 Elemen UX Design yang Bikin Produk Digital Lebih User-Friendly

Langkah-Langkah untuk Menerapkan Agile Development dalam Pengembangan Software

Silakan isi data di bawah sebelum mendownload file.

Silakan isi data di bawah sebelum mendownload file.

Silakan isi data di bawah sebelum mendownload file.

Signup for Free Software Development Guidebook: Input Email. Submit me.