Pengertian Software Requirement Specifications (SRS) - Lab Wisnu

Secara sederhana, Software Requirement Specifications (SRS) adalah dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Dokumen ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai software. Pembuatannya pun seharusnya mengikuti standar yang ada dan paling diakui oleh para praktisi rekayasa software di dunia. Oleh karena itu, standar yang akan dibahas di sini adalah standar dari IEEE.

IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Lengkap. Dengan standar itu, si penggguna dapat mencurahkan semua keinginannya terkait software tersebut dengan jelas dan akurat sehingga sang developer pun dapat memahami apa yang diinginkan pengguna dengan tepat. Bahkan, bagi perorangan, standar ini dapat membantunya dalam mengembangkan outline SRS yang baku khusus untuk perusahaannya, membantunya membuat dokumen SRS dengan format dan isi yang standar (minimal), serta membantunya mengembangkan rincian-rincian pendukung lainnya.

Definisi persyaratan

• Kondisi kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai tujuan
  
  
• Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen resmi lainnya yang dikenakan "Tujuan dari kegiatan persyaratan untuk menghasilkan Spesifikasi Persyaratan Software / software requirement spesification (SRS) yang menjelaskan apa perangkat lunak yang diusulkan harus melakukan tanpa menggambarkan bagaimana perangkat lunak akan melakukannya.
  
  

Software Requirement Specification yang baik

Tujuan dasar dari Software Requirement Specification (SRS) adalah untuk menjembatani kesenjangan komunikasi antara klien dan pengembang, sehingga mereka memiliki visi bersama tentang perangkat lunak yang akan dibangun.

Oleh karena itu, salah satu keuntungan utama dari SRS yang baik adalah :

1. SRS menetapkan dasar kesepatakan antara Pengguna dan Pengembang Jadi, melalui SRS, klien secara jelas menggambarkan apa yang diharapkan dari pengembang.
2. SRS menyediakan referensi untuk validasi produk akhir SRS membantu klien menentukan apakah perangkat lunak yang memenuhi persyaratan. Tanpa SRS yang tepat, tidak ada cara klien dapat menentukan apakah perangkat lunak yang disampaikan adalah apa yang diperintahkan, dan tidak ada cara pengembang dapat meyakinkan klien bahwa semua persyaratan telah dipenuhi.

Kebutuhan proses

Proses persyaratan adalah urutan kegiatan yang perlu dilakukan dalam fase persyaratan dan yang berujung pada menghasilkan dokumen berkualitas tinggi yang berisi SRS.

Proses persyaratan biasanya terdiri dari tiga tugas dasar yaitu :

1. Masalah atau analisis kebutuhan
2. Persyaratan spesifikasi
3. Validasi kebutuhan

Spesifikasi persyaratan

• Fokus spesifikasi persyaratan adalah pada penetapan persyaratan dalam dokumen. Isu - isu seperti representasi, bahasa spesifikasi, dan alat - alat yang ditujukan pada kegiatan ini.
  
  
• Mengatur dengan benar dan menjelaskan persyaratan adalah tujuan yang penting dari kegiatan ini.

Validasi persyaratan

Validasi Persyaratan berfokus untuk memastikan bahwa apa yang telah ditetapkan  dalam SRS adalah segala yang berkaitan dengan persyaratan perangkat lunak dan memastikan bahwa SRS berkualitas baik. Proses persyaratan berakhir dengan produksi SRS divalidasi.

Proses kebutuhan

Perangkat lunak harus memberikan bantuan dalam merepresentasikan dan mengakses file - file eksternal yang dibuat dengan alat bantu lain. Persyaratan Fungsional dan Non Fungsional, Persyaratan User, Persyaratan Sistem Dokumentasi, Persyaratan Perangkat Lunak RPL.

User harus diberi fasilitas untuk mendefinisikan jenis file eksternal. Setiap file eksternal bisa memiliki alat bantu relevan yang bisa diterapkan pada file tersebut. Setiap file eksternal bisa direpresentasikan sebagai ikon yang spesifik pada display user. Fasilitas harus disediakan untuk ikon yang merepresentasikan suatu jenis file eksternal yang akan didefinisikan oleh user. Ketika user memilih suatu ikon yang merepresentasikan file eksternal, efek pemilihan adalah penerapan alat bantu yang berhubungan dengan jenis file eksternal ke file yang direpresentasikan oleh ikon yang dipilih RPL.

Gambar ini menunjukkan bagaimana persyaratan user dapat diperluas menjadi beberapa persyaratan system. Persyaratan user harus ditulis untuk klien dan manajer kontraktor yang tidak memiliki pengetahuan teknis rinci mengenai system.o spesifikasi persyaratan sistemm harus ditunjukan bagi staf teknis senior dan manajer proyek. Spesifikasi ini akan dipakai dai klien dan kontraktor End-user system dapat membaca kedua dokumen ini. Yang terakhir, spesifikasi perancangan lunak merupakan dokumen yang berorientasi pada implementasi. Spesifikasi ini harus ditulis untuk perekayasa perangkat lunak yang akan mengembangkan system.

Persyaratan Fungsional

Pernyataan layanan tentang bagaimana sistem harus bereaksi terhadap input,  sistem harus berlaku pada situasi - situasi tertentu. Secara khusus menyatakan apa  yang tidak boleh  dilakukan sistem. Merupakan penjelasan tentang layanan yang perlu disediakan oleh system, bagaimana  system menerima dan mengolah masukan, dan bagaimana system mengatasi situasi - situasi tertentu. Selain itu kadang - kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh system. Functional Requirement menggambarkan system requirement secara detail seperti input, output dan  pengecualian yang berlaku

Persyaratan Non Fungsional

Pernyataan tentang batasan layanan dan fungsi yang diberikan sistem. Karena berkaitan dengan kebutuhan system secara keseluruhan, maka kegagalan memenuhi kebutuhan jenis ini berakibat pada system secara keseluruhan. Contoh kebutuhan jenis ini adalah kecepatan  akses,  keamanan data, besarnya kapasitas penyimpanan yang diperlukan, privasi masing - masing  profil / account, bahasa pemrograman yang digunakan, system operasi yang digunakan. 

Ada 3 jenis persyaratan non – fungsional :

1. Product req
   Berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang  dibutuhkan dan efisiensi system.
   
   
2. Organisasi req
   Berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan.
   
   
3. External req
   Berkaitan dengan masalah etika penggunaan, interoperabilitas dengan system lain, legalitas dan privasi.

Persyaratan Domain

Persyaratan yang datang dari domain aplikasi sistem dan merefleksikan karakteristik domain tersebut. User dapat mencari semua atau satu set awal database atau memilih subset darinya. Sistem akan menyediakan viewer yang sesuai bagi user untuk membaca dokumen pada penyimpanan (store) dokumen. Semua pemesanan diberi identifier yang unik (ORDER_ID) yang dapat di copy user ke area penyimpanan permanen untuk account tersebut.

Persyaratan Produk

persyaratan yang diambil dari spesifikasi produk, seperti persyaratan hardware  untuk mendukung kinerja. Persyaratan Organisasi yaitu persyaratan yang berasal dari kebijakan dan prosedur pada organisasi.

Persyaratan Eksternal

Persyaratan yang berasal dari faktor eksternal terhadap sistem dan proses pengembangannya.

Beberapa Macam Requirement

• User Requirement (Kebutuhan Pengguna)
  Pernyataan tentang layanan yang disediakan system dan tentang batasan - batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar / diagram yang dapat dimengerti dengan mudah.
  
• System Requirement (Kebutuhan Sistem)
  Sekumpulan layanan / kemampuan system dan batasan - batasan yang ditulis secara detail. System Requirement document sering disebut functional Specification (Spesifikasi Fungsional), menjelaskan dengan tepat dan detail. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
  
• Software Design Specification ( Spesifikasi Rancangan Perangkat Lunak)Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detail.

Kesimpulan

• Tujuan utama dari proses persyaratan adalah untuk menghasilkan spesifikasi kebutuhan perangkat lunak (SRS) yang menangkap secara akurat kebutuhan klien dan yang membentuk dasar dari pengembangan perangkat lunak dan validasi.
• Ada tiga aktivitas dasar dalam proses persyaratan yaitu analisis masalah, spesifikasi, dan validasi. Tujuan analisis adalah untuk memahami aspek - aspek yang berbeda dari masalah, konteksnya, dan bagaimana hal itu cocok dalam organisasi klien. Dalam spesifikasi persyaratan yang ditetapkan masalah mengerti atau tertulis, menghasilkan SRS. Persyaratan validasi dilakukan untuk memastikan bahwa persyaratan yang ditentukan pada SRS memang apa yang diinginkan.
  
• Kunci karakteristik yang diinginkan dari SRS adalah ketepatan, kelengkapan, konsistensi, unambiguousness, pemastian, dan peringkat untuk penting.
  
• SRS yang baik harus menentukan semua fungsi software perlu dukungan, persyaratan kinerja sistem, kendala desain yang ada, dan semua antarmuka eksternal.
  
• Menggunakan Kasus pendekatan populer untuk menentukan kebutuhan fungsional.
  
• Setiap use case menentukan interaksi sistem dengan aktor utama, yang memulai use case untuk mencapai beberapa tujuan.

SRS yang baik akan bermanfaat bagi customer, supplier, ataupun perorangan. Manfaat-manfaat tersebut antara lain:

1. Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang akan dibuat
2. Mengurangi beban dalam proses pengembangan software
3. Sebagai bahan perkiraan biaya dan rencana penjadwalan
4. Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya
5. Memfasilitasi transfer, semisal software tersebut ingin ditransfer ke pengguna atau mesin-mesin yang lain. Customer pun merasa mudah jika ingin mentransfer software ke bagian-bagian lain dalam organisasinya. Bahkan, jika terjadi pergantian personil developer, proyek dapat mudah ditransfer ke personil baru dengan memahami SRS ini.
6. Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara customer dan developer.

Ada beberapa istilah yang digunakan dan harus diketahui untuk memahami standar SRS yang dibuat IEEE ini. Istilah-istilah tersebut adalah:

• Kontrak: dokumen yang mengikat secara hukum dan disepakati oleh customer dan supplier, termasuk syarat-syarat teknologi dan organisasi, biaya, serta jadwal pengerjaan. Kontrak bisa mengandung sesuatu yang kurang formal tetapi bermanfaat, seperti komitmen atau harapan dari pihak yang terlibat.
• Customer (pelanggan) : Pihak yang membayar untuk produk dan biasanya yang menentukan persyaratan (requirements).
• Supplier (pemasok): Pihak yang membuat produk software untuk customer.
• Pengguna: Pihak yang mengoperasikan atau berinteraksi langsung dengan software. Pengguna dan customer biasanya bukan orang yang sama.

Untuk menyusun SRS, beberapa hal perlu dipertimbangkan, yaitu:

• Sifat SRS;
• Lingkungan SRS;
• Karakteristik dari SRS yang baik, yaitu:
  1. Correct (benar)
  2. Unambiguous (tidak ambigu, tapi jelas)
  3. Complete (lengkap)
  4. Consistent (konsisten)
  5. Ranked for importance and/or stability (prioritas penting dan atau stabilitas)
  6. Verifiable (dapat diverifikasi)
  7. Modifiable (bisa dimodifikasi)
  8. Traceable (bisa dilacak)

• Penyusunan SRS secara bersama-sama;
• Evolusi SRS ;
• Membuat prototipe, seperti model atau contoh;
• Mencantumkan desain sistem di SRS;
• Pencantuman persyaratan proyek di SRS. Untuk persyaratan proyek ada dokumen tersendiri

Pada akhirnya IEEE membuat template sebuah SRS, yang isinya antara lain:

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements
4. Appendixes
5. Index

Untuk specific requirements sendiri ada beberapa template yang dibuat oleh IEEE, salah satunya adalah:

3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 Mode 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n
3.2.2 Mode 2
.
.
.
3.2.m Mode m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.nFunctional requirement m.n
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

Sumber :sisteminforman.blogspot-com

cisini.wordpress-com

Related Posts